Not loading saved values in workbench_access_user_form

I don't understand the problem you describe. Please provide a bullet list of steps to replicate, including URL paths.

Thanks for nothing.

I did just run into a case where using the Editor form did not work properly if the user was already assigned by role access. I wonder if these are the same issue.

Here's a patch that seems to fix the real issue.

#5: 1959590-wa-user-save.patch queued for re-testing.

Fixed that test bug.

#9: 1959590-wa-user-save.patch queued for re-testing.

Wrong damn version.

#9: 1959590-wa-user-save.patch queued for re-testing.

I was having this issue in a production site today and noticed a very small change that can be done to improve the loading of the data or at least make this page more robust but on line number 357 of file workbench_access.admin.inc you might want to do this instead

$account = user_load($account->uid, TRUE);

This just ensures the data in user load is the freshest available data. Its not that much of a performance hit because the page is rarely accessed (at least on my site).

My team and I were able to track it down to a database cache issue which was cleared by flushing all caches. Hope that helps

But does the patch as written actually fix the problem?

Neither the Patch provided or comment #15 solved this issue for me which I am also having. I noticed that this goes beyond the form but effects any user_load of a user. The database stored sections appear perfect, they just aren't effecting user_load instances of that user's access which leads me to believe it's a caching issue.

I think I resolved the issue. Essentially the issue is with the workbench_access_user_load_data function which handles adding on the sections the user has permissions to. The function was running a diff between sections the user has access to (after loading that information from the database) and all sections that exist. That diff was then used to add sections to the user variable which would become sections the user DOESN'T have access to and then was then adding them to the current user variable.

So essentially they would end up looking like they have access to only the sections they don't actually have access to. Fix was seriously one line of code being changed. I am including the patch.

Please see this related issue: https://www.drupal.org/node/2546038

The recent 7.x-1.3 release creates a bug due to this patch. Thanks.

The patch here caused anyone who uses roles for the permissions to stop working. The patch here reverts this patch which fixes our issue of no workbench sections being available when creating new content. #2547039: Not applying access by user and role settings correctly

Duplicate

same same: this fix creates the bug #2546038: No options in the Workbench Access control field for me. Reverting it fix the bug.

I struggle to understand/reproduce the problem described in this issue, it seems that different problems have been described. Can someone provide a bullet list of steps to replicate.

But definitely the diagnostic written in comment-18 is wrong:

So essentially they would end up looking like they have access to only the sections they don't actually have access to.

Hence the patch may fix a bug but it creates another one. The patch reverse an if-condition which was right to me: it was adding to the user section a role-based section only if it wasn't already present because it has already been granted as a user-based section. So role-based section are ignored.

I found this bug after a massive breadcrumb trail of git commits and debugging, and am having the issue where if someone's assigned access via a role, it wasn't working, but worked fine if they were assigned as an editor.

Reverting the change under #18 fixed it for me.

Otherwise if you read through the code, it's saying:
1) load the accessible sections by user id
2) foreach section, save it to an array
3) load the accessible sections by users roles
4) foreach section, *if the user already has access to this based on their user id*, give them the same access again.

which just sounds wrong when you consider it through the common sense method!

Inverting the if makes much more sense.

Before this patch the code was saying:
...
4) foreach section, *if the user already has NOT access to this based on their user id*, give them the same access again.
And it was making more sense to me too.
@kholloway, can you describe what is the other problem that this patch is actually solving?