Katy Jockelson → created an issue.
I can confirm that this is still an issue in 8.x-2.0-beta7 and that the workaround in #4 - adding any old things for no results (which will never show) resolves this.
@sime I would be very interested to see if you can recreate this issue on your site.
Katy Jockelson → created an issue.
After getting the latest dev version (8.x-1.x-dev) I'm still fieldsets on the node view (which are configured to show on form display) showing up above the Workflow Buttosn within the form markup on the page.
Katy Jockelson → created an issue.
I'm having a similar issue - not using hook form alter but using multiple form modes on a content type. When you are using a version of the form, which does not have the fields which are marked as 'ROP', I would not expect the validation to run on those fields, but it is. Any ideas how to avoid this?
Katy Jockelson → created an issue.
More testing reveals that this is definitely a clash between paragraphs and workflow moderation.
I thought it could be an issue with Entity Reference Revisions, but a node ref field added that same way validates fine with workflow moderation in place.
Katy Jockelson → created an issue.
This can be closed - as far as I know, this is not a real issue. It was a red herring.
Katy Jockelson → created an issue.
Is this work in the latest version of the module?
If I set the paragraph ref field on a node to be 'ROP' and also the fields inside the paragraph, then I see visual indicators for all, but no validation is happening on the fields inside the paragraph.
I think I found it: Insert content entity - leaving this here for future wonderers
I know this is closed, but my issue is relevant to this so just jumping in.
I am new to ECA and trying to figure out a rule which grants a user role based on certain field values on the user.
The users come in via a sync from Salesforce. I need to grant the role based on a users being created for the first time or existing users being updated, not just existing users being updated which is what this thread seems to suggest is necessary.
Is there really no way to grant a role to newly saved users?
Thanks
For anyone finding this in the future, the issue was unrelated to the Salesforce module of the Queue UI module. It was an errant Rule I had set up to do something on user account creation that was causing these errors.
For anyone finding this in the future, the issue was unrelated to the Salesforce module of the Queue UI module. It was an errant Rule I had set up to do something on user account creation that was causing these errors.
Katy Jockelson → created an issue.
Katy Jockelson → created an issue.
Ok I figured this out.
A) My structure is that I have a 'parent' node with the term access field on, and then a bunch of 'child' nodes which also have the term access field on, in entity ref fields on the parent. If I leave any of the child nodes term ref fields blank, access to even the parent is left wide oprn to any roles that have the 'edit all nodes of type X' in Drupal perms - just a heads up for anyone looking at this in the future.
B) Perhaps more relevantly to anyone looking at this thread in the future, adding the relationship to the user as in comments #11 and #12 was a red herring - do not do this! This relationship is a tie to the node author which we do not want to limit by. I got rid of that relationship and added the filter Content: Workbench access [access scheme name] and then left all the settings untouched. That is working well now. Hope this helps someone in the future.
Thank you very much
To follow up with something that works for me here.
larowlan suggested:
So the issue here is workbench_access_entity_create_access returns false for a user with no sections.
One approach could be to have a generic section, and auto-add that to a user in a hook_user_insert.
At least they'd have one section then.
A neater solution, that worked with my setup, was to create a generic section and then use the 'Roles' feature to say all users with role X are automatically added to that. That mitigated the need to write code to auto-assign each user to the generic section.
On the front-end. "Enter the terms you wish to search for". See screenshot.
Katy Jockelson → created an issue.
This was working great after our call (thank you again) and identifying the clash with views_unpublished and turning on ‘disable query rewriting’, but after I added a generic access section in order to add all users (so they were granted a basic ‘add node’ permission - see
https://www.drupal.org/project/workbench_access/issues/3350021#comment-1...
💬
Allow users to add nodes
Closed: works as designed
), now the ‘My content’ view we were working on before shows all the nodes that are tagged with any access term, as long as the logged in user is in the generic access section. If I remove the user from the generic access section, they ‘My content’ view goes back to only showing the nodes that the user should have access to.
Any ideas why this could be happening?
Thank you @larowlan
We discussed edit access at length - and thank you again for that.
The use-case I explained goes out the window if users can't create nodes that they then, as the author, get automatically assigned to the same section as the node.
Is there any way to separate edit/add access? Or an alternative solution anyone can think of?
Katy Jockelson → created an issue.
To add to what larowlan says above, by adding a relationship of 'user' in the view, I could the add User: Workbench Section: Access Scheme Name with the 'user' relationship.
We also realised that the module view_unpublished was messing with my perms, so we fixed that by unchecking, in the view, Advanced > Query Settings > Disable SQL rewriting and I now see what I expect to in that 'My content' view. This is a solution that works as long as you don't need the view to check any other access control modules.
If I add an action of 'Block user' it wants a value for USER (Specifies the user that should be blocked) - what am I supposed to put here for a rule that targets a user where a custom field is changed? So it's not a a specific user, or a current user, it's just the user that the value got changed on.
Another option would be to create conditions X OR Y OR Z
But I am not seeing any option to add OR functionality for conditions - is this missing!?
Katy Jockelson → created an issue.
I have tested it very cleanly with 2 users, authoring 2 separate nodes.
I add them to the section associated with the node and they have access, and the node prints in the View.
I add them to the section associated with the other's node, and they have access, but the node does not get added to the View.
As an admin I see all nodes listed in the View.
I would love to get this working if you can help at all.
Ah I see. OK got it. I'll get back to you.
@larowlan - great news! Do you need me to to anything to open this as a feature request? What do you think the timeline is on getting this into the codebase?
Thank you. I had a side-slack with agentrickard and came to the same conclusion.
I have someone who can help write the code to automatically assign the author to the section - and I'll be sure to report back.
Thanks larowlan.
I was very excited to see your reply and just tested this out.
Unfortunately that view seems to only print the nodes that have been authored by the logged in user, not nodes in sections that they have been added to. Is that the expected behaviour?
I unistalled, cleaned everything out, reinstalled and reconfigured and now I see a field User: Workbench Section: Access Scheme Name available in Views. But all it does is print the name of the Access Scheme - can you drill down and get the actual sections/terms that a user is linked to?
Ultimately I am looking for a way to show a user a link to all the nodes that they have edit access to.
Thanks.
I was very hopeful when you said this, but alas, I have edit any and edit own on all the relevant nodes types for that user role.
Am I right in thinking that this module takes away, not grants?
It seems to me that you have to set the perms to 'edit any' (and 'edit own') and then as soon as the CT has the 'access term' attached, it denies everyone who is not assigned to the section.
Is that right? What is the default behaviour for the author? Any other ideas?
Thanks @larowlan. But is what I am reporting the expected behaviour? Like, shouldn't a node author always have permission to edit that node?
Katy Jockelson → created an issue.
Katy Jockelson → created an issue.
Katy Jockelson → created an issue.