Hello,
After reviewing the core, I noticed that when a transition is about to be executed the module needs to check whether the user is allowed to execute this transition. This happens in WorkflowTransition.php at execute() function.
How the module checks it:
First, it checks if the user is allowed to perform the transition through normal means (it checks whether a role that user may execute the transition).
Then, if (and only if) the user is allowed to execute the transition through normal means, it checks whether any module, which implements hook_workflow, vetoes the transition.
This means that for a user to be allowed to make a transition, he should be both allowed in workflow module & not vetoed in all modules that implements hook_workflow.
For my case unfortunately, this can't happen. I'm using this module alongside og_workflow module (which implements hook_workflow and considers "transition permitted" & "transition pre" operations).
What I need is:
Some users should be allowed because the core module says so (they have a role that allows them to execute this transition). These are like "global moderators".
But some other users, should only be allowed to execute the transition if they have a specific OG role in the OG the entity belongs (this is what OG Workflow does).
Problem is, that there isn't a way for me to allow the second category of users to make the transition (unless they also have a role that is allowed to execute the transition, which is logically incorrect for my case).
Well.. there are 2 ways I could think of without disrupting the current workflow:
1) There could be a setting which could control the procedure.
- "Strict" access check, could be as it is now: both check whether the user is allowed to execute the transition & check whether all modules do not veto it.
- "Loose" access check, which only checks if core or a module simply allows the user to execute the transition & if there is at least one permission, the transition should be executed.
This could also be a global or a per workflow setting, but I couldn't find a place to "store" it and a page to set it up.
2) The second way I could think of is to implement an access_alter hook function which would allow modules to "override" the result of the previous access checks.
Or maybe add both options somehow :)
I'm willing to implement the solution, but I would need your insight in these options & which road should be better to follow.
Comments
Comment #2
johnvIf this og role is not allowed to execute the transition, how is he able to hoose the next state?
Your setting could be in the Workflow settings in the workflow field. ( does workflow og support that new mode already)
Please check the equivalent code in version 7.x-1.2 and/or 2.4 . Perhaps i made a mistake and restructured the code wrongly.
Would your problem be solved if the hook was always executed?
The permitted and pre hooks have different meanings, and one is implemented much later then the other. One ( permitted, the newer one) is for checking IF the user may see the new stage, upon editing the state. The other ( pre, much older) is used to do something WHEN a state is changing. It also functions like 'permitted', but this is discouraged in newer versions, and is removed in D8. I can imagine workflow og already existed when only one hook was in place.
( i have no access to a pc atm, so cannot check my all of the above).
Comment #3
zekvyrin commentedI'm using og_workflow with the patch from #2264645: is og_workflow compatible with workflowfield as part of workflow 7.2? (which should be commited in dev version as well). So workflow field in entities is supported.
My setting:
User 1: has "Moderator" global role who is allowed to execute the transition (using normal access check).
User 2: doesn't have any global custom roles and is not allowed to execute the transition through normal workflow,
but has an OG Role which is allowed to execute it.
Result:
User 1: is allowed to execute the transition
(og_workflow doesn't vetoes the transition, because there is a code there which doesn't veto if user has normal access)
User 2: is not allowed to execute the transition as workflow module returns the old_sid before there is any chance for the other modules to be checked.
Desired result for me would be that both users should be allowed to execute the transition.
For the other questions you asked:
- In og_workflow both 'transition permitted' & 'transition pre' does the exact same thing actually, but I understand your reasoning what it should be doing.
- As far as I can tell by reading the code in 1.2 it does a similar check, so you didn't do anything wrong. It's just that I need a different logic (the "Loose" I described earlier).
No, not exactly, but it would be solved if there was a hook that would be allowed to "overwrite" previous permitted statuses (which could take into consideration both workflow's access & module's vetoes and decide what to do with them.
Or if there would be a way to change the method as I described earlier.
Comment #4
johnvITMT, there is a hook_workflow_permitted_state_transitions_alter() in version 8.x, that should enable your use case.