nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Strange role behavior?

System

I beleive we ran into this in 6.7.1 and it looks like it still exists in 7.3.2 as well:

I've been analyzing the workflow access to a workarea that we've secured to only work for a few users and processes.

We define an umbrella group Editor access at the top of a heirarcy of branches. Then we add a number of groups into that umbrella group so they supposedly have Editor access against all of the branches in the group.

We then set up workareas as group owned by a subset of the umbrella group. Even though everybody has Editor access to the branch, only the people in the 'shared by' workarea group can actually make updates.

Here's where the strange behavior occurs:
If I give a user/group Administrator access to a branch in this heirarchy, then they can perform a variety of functions against the branch and the workareas in the branch - this is as it should be.

Our workflow process that executes against this branch performs a number of tasks against a workarea in the branch that we really lock down so only the workflow (and Masters and Administrators) itself can actually modify the content in the workarea (we're using it as a pre-merge area). We've been having an issue where the workflow users can't successfully transition a certain task in that workarea as Editors - they need the Administration role to have the permissions to do so - but we don't want to give that Administrator access to the Editors.

BUT - if we assign those Editor users to an Adminstration role in a completely unrelated branch in TeamSite, they 'magically' seem to get the necessary permissions to transition the workflow task that they previously didn't have permissions for. They still can't perform any administrative tasks in the original branch that was having problems, but assigning them to an Adminstrator role -anywhere in TeamSite- is changing how they can interact with the workflow in the secured branch.

Is this expected behavior, or have we run into a strangeness/bug? It's a very subtle one.

Thanks!
Wally

Find more posts tagged with

Comments

Adam Stoller

Kind of difficult to say what's happening without being on the server - you may need to bump up the logging for various aspects of the system and track the events in the logs (server.log, events.log, iwtrace.log, ???) for both a successful and failing run in order to try to narrow down the details of the issue.

Good luck.

nipper

That does not sound like normal behavior. It shouldn't behave that way.

Now, do you have role/permission inheritance turned on ? And would one branch be a child of the other ? Try making someone an admin on the component guide and see if this still holds

You are not assigning them to a group with that role are you ?

Just had to ask the stupid questions first

Migrateduser

When we ran into this on 6.7.1, we were analyzing why some workflow step was working for one user but not another. Their membership in groups matched and, within the context of the branch that we were analyzing, their roles also matched.

It was when I started looking at their roles -outside- of the branch that was having issues that I found that the one user who was not having permissions problems was in an Admin role in a fully separate branching structure within the repository.

When I assigned one of the people having permissions problems to an Admin role (once again, in an unreleated area of the repository), the error was gone.

Migrateduser

Nipper -
Good questions. I said it was strange. Smiley Happy

I think I've found a quirk in the system that's persisted through several releases. It's pretty obscure and I was mostly wondering if anyone else had run into it.

The branches are not related via inheritance at all.
They are both branches within the same store but there's no assignment of roles at a common ancestor of both of the branches.

I may try moving the Admin assignment over to a branch in the iwadmin store (it's currently assigned to a branch in the default store) and see if the results are the same.

Cheers,
Wally

iw_child

Since Wally has since retired, I've been going through some of these old issues. This appears to be due to the override permissions in the admin role. See attached img.

Essentially it states "View and modify files in workareas where they are not a member of the group designated for sharing" allowing the user to have rw- access in workareas that the user is not implicitly defined to have access.