Hi there,

I installed Subgroups and Workflow + Workflow Access and OG User roles. This combination doesn't seem to work.

MemberTestSubgroup has only reading rights for his subgroup. A Wiki document has been made visible to both 'Testgroup' and testSubgroup' with its Workflow state set to only readable for group members.

However, MemberTestSubgroup has edit access to that Wiki Document.

My question: Am I doing something wrong or is there something wrong with the co-operation of the three modules?

I have attached a SQL dump of the test database so you can see it for yourself. User admin, password 123.

All the best,

JPH

PS. The attached site has another bug: when I give a child its parent as a child, which is possible, the site crashes with error 500. I have submitted also a bug for OG_Subgroups.See http://drupal.org/node/159040

CommentFileSizeAuthor
TEST 2007-07-13.sql_.txt677.6 KBjippie1948

Comments

somebodysysop’s picture

somebodysysop commented

Thanks for the info. Screenshots would be preferable to database dumps as I won't try to duplicate your database.

OG User Roles gives you the permissions of the role that has been assigned to you within a group. You only have those permissions while accessing content within the context of the group. If you are outside of a group context, then OG User Roles doesn't have any effect.

So, unless I'm missing something in your description, theoretically it is impossible for OG User Roles to give edit access to a node if a) the user's role(s) within the group doesn't allow it or b) the node is outside of a group context.

Now, what I need to know in order to try to trouble shoot is:

1. What site-wide role(s) if any, does the user have by default (non-OG User Roles) that would give him/her edit access to wiki?
2. What OG User Role(s) if any, have you assigned the user that would give him/her edit access to wiki?
3. Is wiki within a group context? According to your description, it belongs to two groups. So, if the user has wiki edit permissions from a role in either of the groups, he will be able to edit.

I don't have workflow access installed so I can't speak for how it restricts access within a group.

somebodysysop’s picture

somebodysysop commented

I think you should submit more info about your actual setup. What roles are involved in each group, which roles determine workflow permissions?

What role(s) within each group does testgroupmember have and what permissions are, in fact, allowed by said role(s).

Does workflow access specifically work with OG?

Now, I have installed workflow and workflow access. I don't know anything about this module. So, please tell me, step by step, how to duplicate your scenario so I can test it out and see what's going on at this end.

jippie1948’s picture

jippie1948 commented

re: #1 submitted by SomebodySysop

Screenshots would be preferable to database dumps as I won't try to duplicate your database.

It is actually very easy to reconstruct the database.
1. Download the SQL into your MySql database. In case you have already the same table prefixes, change them in my sql file first.
2. create a subdomain that points to your Drupal files directory
3. create a new directory with www.NEWSUBDOMAIN.YOURDOMAIN.COM and fill it with a settings.php adapted to your database server and to the table prefix you choose to use in step 1.
4. go in your browser to your subdomain and login admin 123.

Now, what I need to know in order to try to trouble shoot is:

1. Sitewide permissions MemberTestSubGroup has edit Wiki permissions
2. OG_User_Role level:
= MemberTestSubGroup is not member of the TestGroup
= MemberTestSubGroup is member of TestSubGroup with Group Visitor role with no site wide permissions at all
as the permissions are meant to be given by Workflow access.
3. In Workflow state 'Group-ReadOnly'
users with Group Visitor role are given Wiki read access only.

I have to stop now and go to my appointment. But could you let me know whether you still need the info in #2.

Thanks. I feel very excited about the prospect that the combination Workflow Access and OG_User_Roles might turn out to work, preferably together with SubGroups!

JP

somebodysysop’s picture

somebodysysop commented

It is actually very easy to reconstruct the database.

I'm willing to help all I can, but I'm not going to try and re-create your database. I need to re-create the environment, so I can know exactly what's going on.

1. Sitewide permissions MemberTestSubGroup has edit Wiki permissions

If MemberTestSubGroup has sitewide permissions (and you've not explained how this is done) to edit Wiki, then those permissions WILL APPLY in the group. OG User Roles does NOT override any sitewide permissions (i.e., permissions granted by roles returned by $user->roles function).

If I'm reading this correctly, then there is no issue with respect to OG User Roles because it respects sitewide roles by default. In fact, seems to me that if you take away OG User Roles, you will get the same results in this situation.

If I am not reading this correctly, then I suggest you walk me through re-creating your workflow environment, keeping in mind of course that I don't know anything about workflow or workflow access. When I can see the problem, I'll be in a better position to address it.

Thanks!

jippie1948’s picture

jippie1948 commented

Thanks for your quick response. It triggered lots of thinking and some testing.

Here are my findings:

1. I read your statement about permissions as follow: OG User Roles does NOT override any site-wide permissions granted by roles set on the user/roles administration page. I swiched off Workflow and plaid with the site-wide Wiki permissions. The results confirm this. Thanks for pointing that one out.

Perhaps it might be a suggestion to clarify in your README.TXT the relationship between the permissions set for user roles in the general admin section and the permissions set by OG User Roles.

2. In the Workflow Access README.TXT it says that Organic Groups can override the permission settings of Workflow Access. I tested that without OG_Users_Roles and that turned out to be true. DAMM, because I need Workflow.

3. When I switched OG_Users_Roles on without TAC/OG access control switched on, I got the same results.

4. Now the potentially good news: When I switched TAC/OG access control on, the Workflow Access settings seem to accept/co-operate with the roles as being set by OG_Users_Roles! If this could be really true!

I don' trust this finding yet fully, because I don't understand theoretically why this happens and there are so many permutations to test to catch the exemption.

So it would be great if you and other people could confirm this finding as well.

I am looking forward to hearing from you.

JP

somebodysysop’s picture

somebodysysop commented

4. Now the potentially good news: When I switched TAC/OG access control on, the Workflow Access settings seem to accept/co-operate with the roles as being set by OG_Users_Roles! If this could be really true!

I don' trust this finding yet fully, because I don't understand theoretically why this happens and there are so many permutations to test to catch the exemption.

You are smart not to fully trust this finding because I can't tell you exactly why it works myself. What I can tell you is that the whole TAC/OG access control is based on getting TAC and OG permissions to work together (see http://groups.drupal.org/node/3700). The TAC/OG environment is group-centric, meaning that it presumes that 99% of the data on your site belongs to one or more OG groups.

While I don't know why workflow access works in this environment, I am not surprised since the TAC/OG was designed for group data.

That said, I must point out again that OG User Roles itself is not designed to override sitewide permissions. And, it appears that workflow access is not designed to work with OG. That taken into consideration, it does not seem reasonable to expect OG User Roles to work with workflow access.

If your testing proves that OG User Roles will do what you want in this circumstance, all the better. But, buyer beware.

somebodysysop’s picture

somebodysysop commented
Assigned: Unassigned » somebodysysop
Status: Active » Closed (fixed)