I very often encounter the need to create ‘hierarchical collections’ of entities, of which the structure (their relations to each other) can only be changed by the author but the content can be edited or commented on by editors. Examples:
Educational Content Management: Course structure by coordinator, content updates by teachers.
Software Development Documentation: Lead developer organizes documentation, developers edit content.
With field-level permissions, this would be straight-forward by restricting the relation editing permissions.
With entity permission inheritance and Access Templates, a Project with editable Milestones as fixed structure could maybe be accomplished with restricting the project database to the project manager, which includes the relationship to the milestones, but then the milestone entity could still change its relation to the Project?
I think the best you can do right now is to use auto-linking rules, and hide the field used for the link criteria (e.g. create a field to hold the Public Id of a related entity, and hide that field). But then you are stuck with having to manually set this field for every link you want to create, which is made even harder since it’s hidden.
I don’t think field level permissions is the correct solution to this. A relationship is actually two fields (one at each end) so it begs the question which field governs the permissions.
I think a more plausible solution is that the capabilities available in custom access templates get expanded so that the current ‘Edit’ capability (which encompasses the ability to link/unlink items) is split into a limited ‘Edit’ and a separate ‘Link/Unlink’ capability.
