Sharing mechanism |
An entity is called shareable
when the rule to access it are
defined in the
database Shares table.
Super-administrators or users with permission to manageAllGroups are allowed to manage all shared entities.
 Important |
|---|
The property CreatedBy doesn't have an impact on the shareable entities. |
There are however few exceptions:
The very first share on object is always accepted, we assume it's the share of the object that just succeed his creation.
The administrators of groups/users are consider as part of the groups. So, they gain the sharing as a normal member of the group.
The creator of share record (not the object but the record in the Shares table) is always able to modify the share.
Only creator or user that have a full control permission can remove the share record (not the object but the record in the Shares table).
This topic contains the following sections:
Any objectThe Shares table only store the rule to access the object.
The object itself is store elsewhere in the AskiaPortal database or in separate module database.
The Shares table accept any type of object identified by an arbitrary string in the property IShareObjectType.
| Caution |
|---|
The AskiaPortalCmn API doesn't verify the integrity of the data provided. It doesn't verify the existence or the non-existence of an shared object. It's the responsibility of the module to make sure to provide valid information and also to clean the table as soon as it can. |
Scoped by module and optionally by surveyThe flexibility provided by the property IShareObjectType allows modules to use the sharing mechanism provided by AskiaPortalCmn API.
To avoid clashes between IShareObjectType shared object are scoped by module ( IShareModuleGuid).
As a module, AskiaPortal also uses the sharing mechanism for some type of objects (ShareObjectType). Such as:
Survey
Email
UserProfile
Server
Application
The also API provide an optional possibility to scope the shared objects by survey (IShareSurveyId).
Computed access levelThe sharing mechanism provide 2 types of permissions:
- Access level
Indicates the level to access the object ( AccessLevel) from None to FullControl.
- Re-share permission
Indicates if the user, who access the object, is allowed to re-share the object.
In other words, if the user is allowed to create a new record in the Shares table for the specified object.
An object could be shared for the User, the Group, or Everybody.
The same object could be shared several times, so the rule of share is computed.
The API uses a cascade,
where the rule of share nearest the user will be applied.
Below the priority (higher to lower) to select the rule of share:
Rule apply on ContactTypeUser will be used as it is.
Rule apply on ContactTypeUser is useful to grant or restrict a specific user.
Rules apply on ContactTypeGroup are used when there is no rule apply ContactTypeUser.
Because the user can manage several groups, and because the group could have a tree structure (nested groups), the selection is a little bit complex.
The API will search the shares apply on the group closest to the user.
For example, if the groups hierarchy looks like that:
Parent A |- Group A |- User AIf the object is share in both Parent A and Group A, the rule on Group A will be picked in priority.
The API will select the highest permissions, if several shares are selected.
For example, if the groups hierarchy looks like that:
Parent A |- Group A Parent B |- Group B
If the user is member of the Group A and manage the Group B.
If the object is share with the Group A:
- AccessLevelReadOnly
- CanReshare== true
And with the Group B :
- AccessLevelEditOnly
- CanReshare== falseThe user will then be able to access the object with the highest permissions:
- AccessLevelEditOnly (from Group B)
- CanReshare== true (from Group A)
Rule apply on ContactTypeEverybody will be used as it is, when no rule are apply on ContactTypeGroup nor ContactTypeUser.
See Also