The storm system allows you create a task whose organization and project are not compatible.
- created two organizations, org1, org2
- created four projects, org1-proj1, org1-proj2, org2-proj1, org2-proj2
- created eight tasks, org1-proj1-task1, org1-proj2-task1, org2-proj1-task1, org2-proj2-task1, org1-proj1-task2, org1-proj2-task2, org2-proj1-task2, org2-proj2-task2
- created the user (person) called "partial2", which has the permissions you can see in the attached images.
- assigned the user partial2 as belonging to org1
- assigned the user partial2 to the project org2-proj2
- now log in as partial2
- having org2-proj2 assigned to it, partial2 can now navigate to that project even though he is not part of that organization.
- Once there, click the "plus" icon next to tasks.
- Now the only organization allowed is org1, and the only project allowed is org2-proj2. Filling out the form works, and the task is created.
We now find ourselves with a task whose internal logic (i.e. a task's project must necessarily belong to said task's organization) is not respected.
Cheers and thanks for your module,
Albert.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | Picture 15.png | 36.5 KB | alberto56 |
| Picture 5.png | 13.27 KB | alberto56 | |
| Picture 4.png | 23.12 KB | alberto56 | |
| Picture 3.png | 37.65 KB | alberto56 | |
| Picture 2.png | 24.65 KB | alberto56 |
Comments
Comment #1
Magnity commentedI presume this test was carried out where org2-proj2 was the only project that user partial2 could see?
What happens if there is more than one project available? (Some matching org2). Does org2-proj2 still appear?
This seems to be a bug - but I'm not exactly sure what is causing it at the moment.
Comment #2
alberto56 commentedActually, user partial2 was defined as belonging to org1, so that user had access the projects org1-proj1 as per that user's permissions.
On top of that, partial2 was assigned to the project org2-proj2 (which is a project of the organization org2, to which user partial2 does not belong), so partial2 in effect had access to all projects except org2-proj1 because he is not assigned to the project and not part of the project's organization.
Comment #3
Magnity commentedOK, so in the dropdowns when you create the task, partial 2 can only select org1 as the organization, but can select any one of org1-proj1, org1-proj2, or org2-proj2 as the project?
Which other modules are running?
Comment #4
alberto56 commentedI am Drupal 6.14 with modules dhtml_menu, admin_menu, and storm. For testing purposes, I did not do anything else on this site. The only nodes that exist are those in the description of this issue. You should be able to reproduce the bug using the steps above on a clean install.
Thanks for taking the time to look at this!
Comment #5
alberto56 commentedHi,
I visited the site on which I first tested this and could not reproduce it, so I started with a fresh install, and no other modules. (I had masquerade on my first site as well).
Here are more detailed step-by-step instructions to reproduce the bug:
- install drupal 6.14
- install storm 6.x-1.26
- enable modules storm, storm project, storm task, storm organization, storm person
- node/add/stormorganization = org1 (this is node/1)
- node/add/stormorganization = org2 (this is node/2)
- create 4 projects = org1-proj1, org1-proj2 (assigned to org1); org2-proj1 and org2-proj2 (assigned to org2).
- create 8 tasks following the same pattern (see above)
- new role (admin/user/roles) called worker
- edit permissions for this role and provide the permissions in the images http://drupal.org/files/issues/Picture%202_268.png, http://drupal.org/files/issues/Picture%203_164.png and http://drupal.org/files/issues/Picture%204_111.png.
- new user (admin/user/user/create) called partial2 having the roles worker and authenticated user.
- node/add/stormperson: name, partial2; organization: org1; user: partial2.
- go to the edit page for org2-proj2 (probably node/6/edit)
- Assigned to: select partial2 and save
- log out
- log in as partial2
- go to node/6
- click the little + sign next to tasks
- at this point the menu for organization contains *only one item*, org1; the menu for project contains *only one item as well*, org2-proj2.
- give the task a title and click save
- you now find yourself with a storm/tasks page as in the included image.
Hope this helps.
Albert.
Comment #6
Magnity commentedok- i think i know why this is happening now. will try a fix later on.
Comment #7
tchurch commentedsubscribing
Comment #8
Magnity commentedI've committed a change that I think will fix this. It is currently in the D6 -dev only.
Please feedback as to whether this solves the issue, and if so i'll look to see if it will need deploying to other areas of Storm (and D7).
Comment #9
alberto56 commentedHi,
thanks for the update. Now, when I click on the little + sign (4th step from last in comment #5), I can't create a task at all. Rather, I remain on the same page and get the following error in red:
warning: Missing argument 2 for stormorganization_access(), called in sites/all/modules/storm/stormtask/stormtask.module on line 364 and defined in /sites/all/modules/storm/stormorganization/stormorganization.module on line 36.
Cheers,
A.
Comment #10
Magnity commentedOK - committed a slightly amended version.
The desired behaviour is that it will give an error message, but one to say something like "you can't add a task for this project as you don't have permissions for the organization".
Then there is a bigger issue coming at #585104: Hierarchical permissions which will tackle the hierarchical permissions which may mean that the user will be able to see the organization names even if they can't view the full node.
Comment #11
Magnity commentedWondering whether this solves the issue?
Comment #12
alberto56 commentedHi Magnity, this solves the issue for me, but I agree that this issue really is a small part of #585104: Hierarchical permissions and discussion should continue there. I set the status here to "fixed".
Comment #13
Magnity commentedGreat.
Needs applying to D7 branch and other areas of Storm that rely on this type of relationship.
Comment #14
Magnity commentedHave applied existing change to D7 branch.
Still needs applying to other areas of Storm.
Comment #15
Magnity commentedFixed with the post-midnight caveat that it will probably need redoing when awake...
[Applied to both branches]
The change means that on all Storm nodes that involve dependencies on other Storm nodes, an access check is carried out on the nodes being referenced. If these fail, instead of an inconsistent node being created, an error returns the user to the previous page. This returning an error to the user is not ideal, but means that no 'bad content' will be created before we sort out #585104: Hierarchical permissions (for which i would like more thoughts).
It also checks for the case whereby one of the dependencies is missing, and bypasses the access check for that case.