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

juliangb’s picture

Status: Active » Postponed (maintainer needs more info)

Please could you post some specific instructions for reproducing this issue from a fresh installation? This will help to confirm, debug and fix.

SiteMaster.ServeLime.com’s picture

Please refer to my related posting under TimeTrack for Rights config.

Francewhoa’s picture

@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.

SiteMaster.ServeLime.com’s picture

Yes, 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 :)

catorghans’s picture

I 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.

juliangb’s picture

Status: Postponed (maintainer needs more info) » Active

For everyone who has experienced this bug: What are your caching settings?

Those variables in $account are loaded on hook_init (if I remember correctly).

catorghans’s picture

I have
Caching mode: Normal
Page compression: Enabled

Everything else disabled.

I do have Organic Groups on my site as main other complex module.

catorghans’s picture

I have seen more often that you could not always trust the user array without a load_user. Don't know why.

juliangb’s picture

Is the OG access module enabled?

catorghans’s picture

yes

SiteMaster.ServeLime.com’s picture

I'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.

juliangb’s picture

It 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.

juliangb’s picture

@SiteMaster.Serv...

Do you have OG and og_access installed too? (So that we can narrow down any external influences).

SiteMaster.ServeLime.com’s picture

Nope. 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

juliangb’s picture

Probably 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.

juliangb’s picture

Status: Active » Postponed (maintainer needs more info)

I 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?

juliangb’s picture

Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

As #16.

Please reopen with more information if this is a problem.

catorghans’s picture

Version: 6.x-1.36 » 6.x-1.37

I 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.