Another one:

When a user is in group context, he will see options for creating group content in the group details menu (rightly so) - but he will also see options for creating those content types in the regular "Create Content" menu. Clicking one of those links will obviously not work because the user doesn't have the privilege to create those content types out of group context (which is the case, once the links is clicked). The user is then, irritatingly, redirected to the regular node/add page where he can choose the content types that are actually available to him.

I am unsure how this should be dealt with. I can see two options:
- Alter the "Create Content" menu dynamically to not show those options in group context
- Alter the Menu callback of these links to let the user add that content type in group context

Seems to me option 1 would be more consistent from a usability point of view...

CommentFileSizeAuthor
#4 og_user_roles.module.5.x-2.4_1.patch21.07 KBsomebodysysop

Comments

somebodysysop’s picture

somebodysysop commented

The quick and easy solution to this is to edit the menu item "Create content" and uncheck "Expanded" checkbox. This will prevent the Main Menu links in question from appearing in the first place.

somebodysysop’s picture

somebodysysop commented
Assigned: Unassigned » somebodysysop

The way to fix this is to be able to know what the group context was for the page preceding /node/add/type.

I looked into the possibility of adding a fix that would automatically detect the group context from the referer, but there are too many url permutations to make that feasible.

Then I hit on the idea of using the OG tracker "og_last" to determine if the preceding page was a group page. I actually coded some stuff, but it doesn't work consistently -- "og_last" isn't always set or able to be used to determine if the last page is a group page.

So, unless you can come up with a better idea, I'm going to have to mark this as "won't fix" (what I actually mean is "can't fix", but that's not an option).

Rhino25782’s picture

Rhino25782 commented

Right.. I can see now why this wouldn't be a problem in many cases because the Create Content menu tree would be collapsed and when you expand it, you leave group context. Unfortunately, this isn't working for me as I am using DHTML_menu for dynamic menus. So it is ultimately the user's choice which menu trees are expanded and which are not.

Both your approaches to fixing the problem, as I understand it, would result in the menu links to still appear but carry on the group context to the next page. I still think the other option (altering the menu to make those content types disappear that user cannot create in site context) is much more consistent.

Do you think that second option is doable? I can't make any promises but if I find some extra time, I might dive into this and try to figure out a way? Just getting started in Drupal module coding, though.

somebodysysop’s picture

somebodysysop commented
Status: Active » Needs review
StatusFileSize
new og_user_roles.module.5.x-2.4_1.patch21.07 KB

Try the attached patch against release 2.3. See if it resolves the issue.

Rhino25782’s picture

Rhino25782 commented

Strangely enough, after some modification to the site/grants etc today, I unintentionally "fixed" the problem. In any case, the non-group context links in "Create Content" do not currently appear anymore. I applied your patch nonetheless and will keep an eye on it.

Thanks again.

somebodysysop’s picture

somebodysysop commented

after some modification to the site/grants etc today, I unintentionally "fixed" the problem.

Could you give a expound just a bit more for the sake of those who might want to try what you did?

Rhino25782’s picture

Rhino25782 commented

My best guess is that is has something to do with how I reconfigured user roles yesterday. In order to make the Peek module work in the way I intended it to work, I moved all permissions from the regular "authenticated user" to a new role called "approved user" and used og_user_roles to assign the role "approved user" to every new sign up. This was neccessary because the peek module automatically grants "authenticated user status" to peekers and I needed to have control over that.

Since after I did that - either conincidentally or consequently - the non-accessible "Create Content" links show up no more.

somebodysysop’s picture

somebodysysop commented
Status: Needs review » Fixed

Thank you for the follow up. May prove useful to someone else in the same boat.

somebodysysop’s picture

somebodysysop commented
Status: Fixed » Closed (fixed)

Modifications in version 5.x-2.4 which has just been released.

heacu’s picture

heacu commented

subscribing