Use client groups for local role sharing

[ramonski]

Description of the issue/feature this PR addresses

This PR changes how users that are linked to a client contact get the local Owner role in the following way:

• Explicit client groups are created for each existing and for every new created client
• The group has the local Owner role assigned on their client
• Every client group has the gloabl Client role assigned
• Each linked user is automatically added to the group and removed from the group if unlinked

Current behavior before PR

• The Owner role is looked up dynamically for each user that is linked to a client contact
• When the user is linked to a client, the user has no access to previous created contents unless the whole content structure below the linked client is reindexed (which might take ages)

Desired behavior after PR is merged

• The Owner is granted by group membership of the client group
• Each linked user will get immediate access to all previous created contents w/o the need to reindex the whole content structure
• A new "Manage Access" page allows to assign further roles to the client contacts, e.g. Analyst, Sampler or any other custom role.

--
I confirm I have tested this PR thoroughly and coded it according to PEP8
and Plone's Python styleguide standards.

[xispa]

Exciting as usual! Left some comments

[xispa]

I suggest to do not rely on getClientID, but getId only:

setattr(self, self.GROUP_KEY, '{}-group'.format(self.getId())

Reasoning is that the (internal) id of the client object will never change, while the value of ClientID can be changed anytime, as long as it remains unique. Thus, ClientID of two different clients could be shifted in future. This could cause confusion and inconsistencies as well. Since the group id is not "visible", but it's name only, it does not need to be human-friendly.

On another note, why to store the group_id as an attribute. Why to not simply do

return self.getClientID() or self.getId()

[ramonski]

The ClientID as the Group ID was chosen because it makes more sense to the people and allows to search for the client ID in the groups panel. The getId fallback was mainly because of the tests, where we do not provide the ClientID on sample creation.
Said that, the stored attribute handles exactly that use case where the Client ID changed afterwards.

I agree that the getId would be better, but having the people in mind who are using it, I decided to go with the ClientID.

[xispa]

Rely on the existing property self.group_id:

portal_groups.removeGroup(self.group_id)

[ramonski]

Thanks! Fixed in 5e0bb01.
I also remove the attribute there.

[xispa]

Is this necessary? Why to not return False directly if there is no group?

[ramonski]

Basically I want to ensure a group if it was either deleted, or not created due to the registry setting. Remember, the group has the global Client role and the local Owner role on the current client object.

[xispa]

I've done a quick search (extensions included) and ClientAwareLocalRoles is not used anywhere else. I suggest to remove (instead of comment) this adapter declaration, as well as the adapter itself (senaite.core.adapters.localroles.ClientAwareLocalRoles)

[ramonski]

Removed in d953958