feat(common-contacts): resolve share emails on org first - #4939
shepilov merged 13 commits into
Conversation
Sorry, something went wrong.
|
|
||
| // extractRecipientIDs extracts group and contact IDs from a JSON:API relationship. | ||
| func extractRecipientIDs(obj *jsonapi.ObjectMarshalling, relationshipName string) (groupIDs, contactIDs []string) { | ||
| func extractRecipients(inst *instance.Instance, obj *jsonapi.ObjectMarshalling, relationshipName string) (groupIDs, contactIDs, emails []string) { |
There was a problem hiding this comment.
This API should be changes, I don't know how yet, but there is should not be difference from the client side, do we add a "common" contact or group, or just personal one
Sorry, something went wrong.
There was a problem hiding this comment.
Emails now work the same whatever the context, the client just sends {"type": "io.cozy.contacts", "email": ...} and the stack figures out where the contact lives.
Sorry, something went wrong.
| id, ok := refMap["id"].(string) | ||
| if !ok { | ||
| // Without common contacts, a ref without id is ignored as before. | ||
| if email, _ := refMap["email"].(string); email != "" && inst.HasCommonContacts() { |
There was a problem hiding this comment.
An email ref is silently dropped when the context has no common_contacts: the client gets a 200 with a sharing that has fewer members than it asked for.
The lookup and the create work without the feed too, so either accept emails always or reject the request. This is also anton's point above: the client should not have to know.
Sorry, something went wrong.
There was a problem hiding this comment.
Dropped the gate as in the storage ADR, so emails are always accepted and common_contacts only decides who writes the contact afterwards.
Sorry, something went wrong.
| } | ||
| } | ||
| } | ||
| for _, rel := range []string{"recipients", "read_only_recipients"} { |
There was a problem hiding this comment.
The rewrite changes the member order: contacts first, then emails, then groups, where it used to follow the order of the relationship. Member indexes end up in the invitation URLs, so this is worth a check that nothing depends on it.
Sorry, something went wrong.
There was a problem hiding this comment.
No consumer of the order. The index is fixed in addMember and the invitation only goes through that member's credentials (Credentials[idx-1]). AddRecipients already did contacts then groups, so this aligns CreateSharing with it.
Sorry, something went wrong.
Master added a caller of extractRecipientIDs, which this branch replaced. Emails are ignored there, as on master.
…ntacts after the add The service is passed to AddGroupsAndContacts, AddEmail and DelegateAddContactsAndGroups instead of a package global. A contact is published only once the member is added, so one removed after a failed add never reaches Sabre. The publish decision moves to collectedRequest so its negative cases are tested synchronously.
The sharing methods no longer take the RabbitMQ service. A share-collected-contacts job publishes the created contacts and retries a failed publish. Contacts created by a request that fails later are published too, as they are kept.
… member The emails are resolved on the member's instance, like the contacts, and the contacts created for them are published.
Summary
Part of linagora/twake-workplace-private#1775.