og transition ui is visible but silently fails for those not allowed to make transition

That's weird because this is a function that has been available for quite some time. However, the solution might be simple: Maybe it's not OG Workflow, but Workflow itself denying the transitions? Make sure to allow the transitions globally. They can then be restricted on a per group basis.

Yes, otherwise Workflow just blocks the transitions. With OG Workflow you can only limit, not expand permissions.

Hi there.

I've got the same problem. Have changed the global permissions and even fresh install. Nothing worked. I am using dev version. The admin can change the states but any other use not. Even on the workflow tab the states are not listed(change the workflow state).
When I don't choose the group audience then everything works fine. Seems like some permission issue(not sure where).

Thanks for any response

If this should be opened as a new issue please let me know; I'm using 2.0, and no one, not even admin, can do any scheduled transitions. Workflow transitions work, and immediate workflow transitions work for both OG and non OG; it's only scheduled OG workflow transitions that don't. I get "You are not allowed to make this transition." each time I run Cron, and the scheduled transition doesn't occur or get removed from the workflow tab.

Note - as this issue isn't on the dev version, I'm opening it as a new support request.

stefank, somehow this slipped through my fingers, sorry. Did you manage to solve you issue or do you still need help?

i'll tack on my 2 observations/bugs here as i think they may be related.

1. (i think close to what heather is describing):
- Joe (op2) is an "operator" in my group: http://screencast.com/t/mk7eBPFCjBp
- operators have og/workflow set to allow change from current => working: http://screencast.com/t/FjNHS1H6b5
- Joe has access to Workflow tab but there are no states he can change the node to: http://screencast.com/t/E8RiaVrjCFu

2. maybe related??
- Philip is a member of the group: http://screencast.com/t/IDYy8nme
- og member role has no rights to change states via og/workflow: http://screencast.com/t/izQGvtbrLYJ
- however he does get both radio option for both these states on the node: http://screencast.com/t/X2exXEjaGZs
- BUT: making the state change select silently fails.

also of interest:
- Philip is in the global role genivar which has std workflow right to change these states: http://screencast.com/t/cWrqonA9eO
- you can also see that even though Philip has access to a non-functional Workflow tab he has no edit right to the node (Edit tab is missing) - even though genivar role has "edit any" perms set; since the site has og " Strict node access permissions" set; this global edit role is ignored (which is why no edit tab) - so possibly something in this that is messing up workflow.

Ok, let's got one by one. You are using the latest dev (2013-May-29), right?

Does Joe have global permission to make the transition?

Organic groups 7.x-2.0+1-dev (2013-Feb-19) - hmm, thats a bit old
OG Workflow 7.x-2.0+28-dev (2013-May-29)
Workflow 7.x-1.1+31-dev (2013-May-29)

globally Joe has no role (other than auth) and auth has no perms to do any workflow transitions

That's the problem as mentioned in #3: Workflow can only limit permissions. I guess we will need to implement adding permissions (basically not caring about what workflow thinks) in the future. However, this requires quite a change in workflow itself and will thus take some time. If you want, you can open a new feature request for that.

Concerning the second case: does the respective content item also belong to another group or just one?

still on the first case:

ok, didn't realize this limited main workflow settings (perhaps this should get added to project page?). i had assumed that this was like std drupal access module which is a grant system - as long as something grants access you are good.

so i now set global workflow to allow authenticated to switch between working/current and the radios now appear for Joe and he can make the changes. YAY!!

the other side of this test case then would now be what a std group member (but in no role besides member in the group) can see/do. testing this i see they also see the workflow tab, see the radio buttons for both working and current but when making a state change the submission silently fails - this now becomes very similar to my test case #2.

re: #12 (and my test case #2) - NO, all content can belong to only 1 group.

so the issue remaining i think can be summarized as:

people with global access to state changes see the ui to make the change; but if they do not also have the og workflow access to make the change; the change silently fails

revisiting this with latest -dev rel and i see this is still busted.

just to be clear as to how i think this is supposed to work:

- global workflow allows auth to transition from state1 to state2
- og_workflow does not allow non-member (of og) to make any transitions

the issue:
- the ui to make transition is still visible to a non-member despite the og_worflow setting but it silently fails to do the transition

although this could be considered as working since the transition is not allowed; i would think a pretty serious ui bug that it leads the user to think they can perform the transition

i'll hijack this case and change title to match this (and mark as a bug)

Hi guys,

this was due to an API change in workflow. Please try with the latest release and confirm it's working.

Hi there,

I updated the Workflow module from 7.x.1.2 to 7.x-2.0-beta9.
The problem disappeared.

I hesitated to do te update because on the main OG-Workflow page is stated that "The latest 7.x-2.x-dev works only with workflow 7.x-1.1-beta3 and 7.x-1.x-dev". Perhaps this info needs to be updated.

Thanks,

Jippie

That's funny, because og_workflow does not work with workflow 7.x-2.0-beta9. That's maybe why the problem disappears.

Well, the original problem seems resolved. Right now the module is in a transitional state and things are broken because the workflow module changed a lot internally. So most likely things will be sorted out after the transition. Closing this for now.