Hierarchical permissions
deggertsen - September 22, 2009 - 23:18
| Project: | Storm |
| Version: | 6.x-1.x-dev |
| Component: | Storm Notes |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
This problem may exist in more places but I was just noticing that if you have somebody assigned to a project and they try to create a note for the project it will not allow them to unless they have the permission "Storm organization: view all" checked or they must belong to the organization and have "Storm organization: view belonged" checked. I assume that even if they are unable to see an organization's details but are assigned to a project for that organization they should still be able to create notes for that project. I hope that makes sense.
#1
I think this is an artefact of the degree of separation between the permissions in each Storm module - there is no overlap which says if you can view the organization if you can view a project of that organization.
Also, currently the access restrictions mean that if you cannot view a particular node, you cannot select its name at all. I think this is where the issue lies - there needs to be a distinction between seeing the name of a node, and being able to view its contents.
Thoughts welcome. Its something that seems to catch a lot of users at the moment across various issues.
#2
Agreed. I would like it if you could see the name of the node so that you can create nodes for that organization, project, etc. But not see the node contents unless you have permissions. Of course if would be better if you could only see the name of the organization if you are assigned to or have permissions to view nodes pertaining to that organization. I think we're on the same page here...
#3
More than that though, I wonder if there is a way to restructure the permissions so that by overlapping the permissions for organizations, projects, tasks, tickets etc down the hierarchy, the overall number is reduced leaving a simpler and more intuitive interface.
I'm sure a few more people will have thoughts or ideas for this.
#4
Changing title / status to be better placed for the discussion that needs to happen.
#5
My thoughts/expectations are:
1) A person is either assigned individually or as a team member to a project
1a) This person should then be able to see (!) the organization (title in listing and node)
1b) Whether that person can view/edit/delete/create new tasks/tickets/notes/etc. should be permission controlled on project level
2) A person is assigned to tasks or tickets (individually only), not yet implemented
2a) In this case the person should see all parental nodes (organization, project, task)
2b) Whether that person can view/edit/delete/create subtasks, tickets, notes or timetrackings should again be permission controlled on the task respectively ticket level
All other permissions could then be omitted.
Well, to be honest this is simplifying the scenario a bit but I would regard this as a core starting point, where all other details were designed around that framework.
#6
The problem with the parental nodes access is that there could be private data about an organization, that you may not want someone on the project level seeing...
#7
Yes, I thought of that many times before, not only for parents but also for children, i.e. notes for a project. That leads to the proposal of incorporating a "Private" flag to Storm nodes.