Hi Ron,

I really hope I've just bungled something on my end here, and if so, I apologize for the spam.

I've installed Drupal from scratch twice to verify this. The issue occurs on my primary Drupal instance (5.1 + og_u_r 1.5) as well as the two test instances that I created (5.2 + og_u_r 2.0) just to verify this possible bug.

Steps to replicate:
- Create a role with upload permissions and node creation permissions
- Install the og_user_roles prereqs (views, og, og_forum) and og_user_roles
- Configure the role you created to be used by og_user_roles
- Assign this role in og_user_roles context to a user subscribed to a group
- Create a node in this group and try to attach a file to the node
- The upload will seem to happen, but no attachment will be shown or be uploaded.
- When I add this role to the user globally, then the user is able to attach files.

Behavior I was expecting:
- That I would be able to attach files as a user that has an og_user_role with upload permissions

What happened instead:
- I was unable to attach files to a node (page content type as well as a custom cck content type)

This isn't a terribly big deal as I can work around the issue by assigning everyone to a global role that has upload permissions, but it would be nice if it was fixed.

I'd be happy to do any further testing.

Regards, Geoff

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

gmayes’s picture

Whoops, this is very likely user error! My bad! In my madness of creating multiple drupal instances, I did not set the webroot to the subdirectories that were serving the pages (which is a very clear requirement of og_user_roles). I just set the webroot to one of the test instances and I am now able to attach files. I'll continue testing...

gmayes’s picture

And I'm back...

Sorry, I try to be so cautious about wasting your (the developer's) time that I second guess myself out of thinking there is really an issue (and I know that 90% of issues are user error).

I was only able to attach files just then because the "authenticated user" had upload permissions. When I removed those permissions so only the og_user_role with upload permissions was set for the user, this user could not attach files.

SomebodySysop’s picture

Assigned: Unassigned » SomebodySysop

I understand the problem, duplicated it, know exactly what's wrong. Just don't know how to fix it right now.

When you click on "attach" file, Drupal runs "user_access" to check permissions as usual -- however, at this point, there is no group context and arg(0) = "upload" and arg(1) = js. OG User Roles simply can't see you during this process.

So, got to think this one through for a minute. Have a couple of ideas. If anyone else has any ideas, would love to hear them.

SomebodySysop’s picture

Status: Active » Needs review
FileSize
5.42 KB

Attached is patch designed to resolve the problem. Try it and see if it works for you. Let me know your results. Thanks.

gmayes’s picture

Patch works perfect. Thank you very much!

og_user_roles keeps getting better and better by the day it seems...

gmayes’s picture

FileSize
105.88 KB

I've done some more testing and came across something interesting. og_user_role permissions for uploading and some moderating (checking/unchecking "In moderation queue" remains, but every other modr8 link disappears; see http://drupal.org/node/164092 ) come and go every time "save permissions" is clicked in "Access control".

To replicate:
- Browse to "Access control" for the first time
- Click "save permissions" (don't change uncheck/check anything and make sure upload permissions are checked for the og_user_role)
- If your user had upload/moderate permissions and they worked, they are now lost. If these permissions were not working but enabled, they should now work.
- I've noticed that to re-enable permissions, you have to, as admin, browse to another page and then come back to "Access control" and save permissions.

When uploading permissions don't work, a popup error message appears, which is attached. Even though this error message appears, and the file attachment is not displayed when editing the content type, once you click submit the attachment is there. This occurs in IE 6 and Firefox 2.0.0.5.

SomebodySysop’s picture

- I've noticed that to re-enable permissions, you have to, as admin, browse to another page and then come back to "Access control" and save permissions.

This sounds pretty convoluted. I can assure you that it has nothing to do with OG User Roles. If you examine the code, you'll see that all we do is simply add the group roles to the user object every time it is loaded. The only time group roles are not added is when we are either not in a group context, or OG User Roles doesn't know that we are in a group context.

The modification I just made will ALWAYS allow you to upload files on a node edit if you have the "upload file" permission and the node you are editing is a node in the group that you have this permission.

In the patch is new code to use the og_user_test table to see what's happening in the OG User Roles code at a particular URL. Directions for using it are here: http://drupal.org/node/164038

So, if something is blocking OG User Roles from adding the group roles to a user object, hopefully we will see it here.

SomebodySysop’s picture

Status: Needs review » Fixed

This patch is now commited in release 2.1. Tested it and it works. Can't account for BuddyList environment at this point, so we'll assume for the time being that OG User Roles and BuddyList are not compatible.

SomebodySysop’s picture

Status: Fixed » Closed (fixed)

Release 2.1 now available for download.

gmayes’s picture

Hi SomebodySysOp!

I sincerely apologize for disappearing for a couple weeks. No excuses!

Would you still like me to try out the og_user_test table for the issue seen in Comment #6, or does this sound like a potential issue with the core "Access Control" code?

SomebodySysop’s picture

It appears that the last update did not fix the problem. Right now, the behaviour is explained here: http://drupal.org/node/166557, and what to do about it explained here: http://drupal.org/node/166566

Keeping this issue open until it is resolved: http://drupal.org/node/165723

SomebodySysop’s picture