Steps to reproduce:

  1. Have a basic install of OG and OG Menu with some groups.
  2. Give authenticated users the "Create/Delete/Edit/View OG Menu instance entities" permissions
  3. Log in as a non group member user.
  4. Find the id of a og_menu instance for a group the user is not a member of.
  5. Navigate to admin/structure/ogmenu_instance/< og_menu id > as the non group member user.
  6. You'll be able to view/edit/etc the menu instance.

Note: If I remove those permissions from authenticated user, then even the group owner is unable to modify, or view, the og_menu instance. They get an Access Denied page.

I'm guessing this is because there are no per-group permission checks.

Are there any current plans on how to add per-group permission checks into og_menu?

Is this something that should wait until OG gets it's per-group roles and permissions ui into the D8 version?

I'd imagine the proper path to per-group permission checks in og_menu would be to add them to OG's permissions.

If we do without OG's permissions, I'd think it'd end up in the main permission screen as something like "Create/Delete/Edit/View OG Menu instances for joined group", "Create/Delete/Edit/View OG Menu instances for owned group", and "Create/Delete/Edit/View OG Menu instances for any group".

Comments

jerrac created an issue. See original summary.

joelpittet’s picture

joelpittet
he/him
Primary language English
Location Vancouver
commented
Status: Active » Closed (outdated)

Hi @jerrac, and apologies this sat unanswered for so long. You're right: it only supported site-wide permissions, so users either had access to every group's menus or none at all.

Closing this as a duplicate of #3616205: Restore group-scoped administer og menu permission as it addresses this using OG's permission system.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.