Configuration semantics

The implications of a permission configuration in connection with a selected ID schema is not always trivial and is explained in more detail in Permissions in FirstSpirit (→Documentation FirstSpirit SiteArchitect):

Permission component example

The new permission component is capable of assigning permissions for different operations. The operations are basically orthogonal, i.e. there is no scenario “Operation A requires B” or “A leads to B”. Such functions are realised via project-specific validations/correction scripts which are called at appropriate periods.

The presentation of additional operations occurs as tabs (see “Read” and “Edit”).

Convenience methods

The decision not to support a “modifying inheritance” results in the following problem during project “maintenance”:

Permission definition changes: Permission definition changes do not influence the hierarchically subordinate part trees in the tree structure which start with a permission definition node (“Copy-on-Change” semantics of the permission definition point). These change classes must be used on each permission definition node in the subordinate part trees. To facilitate this task, it is possible to transfer the state of the subordinate node to a group node via a context menu each time the configuration is changed. After selecting the “Propagate permissions” context menu, a window opens which displays a list of all subordinate permission definition points. Select the respective nodes in this window and the state of the part tree on which the context menu has been opened is transferred to all subnodes after confirmation.