Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Following rights not honored properly:
- Storm project: edit if project manager
- Storm project: edit of user organization
If the user's role has "Storm project: edit if project manager" and "Storm project: edit of user organization" rights, they still can't view/edit the Project (or assign Time to a Task - logged as separate issue).
They can however View/Edit if I assign the "Storm project: view all" rights.
It thus seems the listed rights are not honored properly.
Comments
Comment #1
juliangb CreditAttribution: juliangb commentedPlease could you post some specific instructions for reproducing this issue from a fresh installation? This will help to confirm, debug and fix.
Comment #2
SiteMaster.ServeLime.com CreditAttribution: SiteMaster.ServeLime.com commentedPlease refer to my related posting under TimeTrack for Rights config.
Comment #3
Francewhoa@SiteMaster.ServeLime: Thanks for your comment. I'm assuming you're referring to #1113970: Timestracking "View Own" + "Edit Own" rights not enough
If you want a faster response time then add a link (URL) to your other issue. Module maintainer appreciate that.
Comment #4
SiteMaster.ServeLime.com CreditAttribution: SiteMaster.ServeLime.com commentedYes, that's the Issue.
Thanks for reminding us all - we should be adding the links where issues relate.
And a BIG THANK YOU for the awesome work you're doing :)
Comment #5
catorghans CreditAttribution: catorghans commentedI have the same problem.
I looked into it and found a bug in
function stormproject_access()
$account did not have any of the storm values,
no $account->stormorganization_nid or $account->stormperson_nid;
When I added
$account = user_load($account->uid);
to the function before: if (is_numeric($node)) {
It works.
It seems that in some cases you cannot trust $account to have that information.
Comment #6
juliangb CreditAttribution: juliangb commentedFor everyone who has experienced this bug: What are your caching settings?
Those variables in $account are loaded on hook_init (if I remember correctly).
Comment #7
catorghans CreditAttribution: catorghans commentedI have
Caching mode: Normal
Page compression: Enabled
Everything else disabled.
I do have Organic Groups on my site as main other complex module.
Comment #8
catorghans CreditAttribution: catorghans commentedI have seen more often that you could not always trust the user array without a load_user. Don't know why.
Comment #9
juliangb CreditAttribution: juliangb commentedIs the OG access module enabled?
Comment #10
catorghans CreditAttribution: catorghans commentedyes
Comment #11
SiteMaster.ServeLime.com CreditAttribution: SiteMaster.ServeLime.com commentedI've also got Caching = Normal
Seems there are now a number of similar bugs - I've seen a new one added.
Suggest starting simple: Ensure the different View rights work properly for Org, then for Project, Task
Focus on View Own Org, then Assigned Project, Assigned Tasks,...
All of these seems to be "broken" somehow.
Comment #12
juliangb CreditAttribution: juliangb commentedIt would be odd if this had suddenly totally "broken"... but the hierarchical approach is logical.
Would anyone be prepared to write tests for these? (Tests are actually quite easy - copy an existing one for inspiration if needed). I will get to this when I have time, but it sounds like several people are waiting on this.
Comment #13
juliangb CreditAttribution: juliangb commented@SiteMaster.Serv...
Do you have OG and og_access installed too? (So that we can narrow down any external influences).
Comment #14
SiteMaster.ServeLime.com CreditAttribution: SiteMaster.ServeLime.com commentedNope. It's a clean install.
CCK, Views, other basic stuff. no other Access Control modules.
CKEditor, Better Formats, etc.
If it' supposed to be working, let me know. I'll disable everything except CCK, Views to then test.
Expect this issue might indicate the cause (Org not assigned properly):
Timestracking "View Own" + "Edit Own" rights not enough | drupal.org - http://drupal.org/node/1113970
Refer Posts #5, #6
Comment #15
juliangb CreditAttribution: juliangb commentedProbably ok with those modules.
Would you be able to test this (#1113970-6: Timestracking "View Own" + "Edit Own" rights not enough) though? Might solve it perhaps.
I'm planning to spend some time on this over the next few days.
Comment #16
juliangb CreditAttribution: juliangb commentedI couldn't reproduce the issue over at #1113970: Timestracking "View Own" + "Edit Own" rights not enough.
Is there any more information on this that will help me reproduce and figure out if there is a problem here?
Comment #17
juliangb CreditAttribution: juliangb commentedAs #16.
Please reopen with more information if this is a problem.
Comment #18
catorghans CreditAttribution: catorghans commentedI still had this problem after upgrading to 1.37..
I still have OG & og_access...
The solution is to set the weight of all storm modules to -1.