Problem/Motivation
If I create a role and have the Actions module enabled I can edit the role created by user_user_role_insert()
- but I can not save. This is because the ID has a dot in it.
Proposed resolution
There are currently three proposals:
- Allow actions to have dots in their config names (as is true of entity_view_mode, entity_form_mode, block, and config_test)
- Change user_user_role_insert to not create actions with dots
- Add a UI lock on actions, and lock those created via user_user_role_insert (similar to date_format).
#3 might be appropriate since these actions are created and deleted by the User module. In fact the user_user_role_delete is completely unnecessary because of configuration dependencies. So therefore it could be possible to remove that and just create an action with an ID that can be edited.
However this is related to a wider issue of should configuration entities be able to control the meaning of dots in their ID see #2100203: Make config entities use dots in machine names consistently
Remaining tasks
Agree approach
User interface changes
tbd
API changes
tbd
Data model changes
tbd
Why is this a possible RC target
The UI makes it look like such actions are editable but they are not. We have a form where the submit is impossible - regardless of what the user does.
Comment | File | Size | Author |
---|---|---|---|
#33 | interdiff-31-33.txt | 2.05 KB | jofitz |
#33 | 2605042-33.patch | 13.9 KB | jofitz |
#43 | 2605042-nr-bot.txt | 132 bytes | needs-review-queue-bot |
Comments
Comment #2
alexpottThis was discovered whilst investigating #2597608: User role action labels get double-escaped and out of sync with the corresponding user role label
Comment #3
alexpottHere's a failing test.
Comment #5
tim.plunkettAdjusted the IS to clarify the options. This is a patch for approach #1. Patch for #3 will follow, I just wanted to prove we have an easy out.
Comment #6
alexpottThe problem with proposal 1 is that then someone could feasibly create a clash with the action created by
user_user_role_insert()
Comment #7
tim.plunkett#6, I don't follow. The machine name FAPI #type still enforces uniqueness, even with dots.
Here's a patch for approach #3.
Interdiff is against #3, not #5
Comment #8
alexpottre #6 Someone could create the action for another role with the same ID as a role they will create in the future - madness yes - but also possible.
Comment #11
tim.plunkettWow, \Drupal\KernelTests\Config\DefaultConfigTest is really cool.
Adding false to all exported action files.
Does that need an update hook? The property defaults to FALSE, should work...
Comment #12
tim.plunkettI only checked for update, should I have included delete?
Comment #13
tim.plunkettComment #14
alexpottre #12 I think so - I don't think a user should be able to delete such actions through the UI either - that said there is no harm in allowing them to do this.
Comment #15
tim.plunkettSee also #1831928: Support a 'locked' property on ConfigEntities
Comment #16
andypostComment #17
kristiaanvandeneyndeSeems like a duplicate of #2553765: Actions created in user_user_role_insert contain a '.' and cannot be updated via the UI, the other issue being older than this one. Which one should be closed?
Comment #18
kristiaanvandeneyndeAlthough the patch in #11 does look really good.
Comment #19
alexpott@kristiaanvandeneynde I think we should choose the approach in this issue rather than the other issue so I suggest we close the other issue and give people who work it on commit credit on this issue.
Comment #20
kristiaanvandeneyndeYeah, funnily enough I came up with the same idea as summary item #3. So seeing as this issue already has code for that approach, it makes sense to close the other issue. I'll go ahead and close the other one.
Comment #21
alexpottWe need to add
heykarthikwithu, StryKaizer, kristiaanvandeneynde, damiankloip, Jeremy
to the commit credit when and if this gets in.Comment #22
xjmComment #23
alexpottDiscussed with @xjm and @catch - we agreed this was a major bug because it looks like you can make a change in the UI but in reality you just can't - and the error makes it look like the machine ID is wrong and you should change it.
Comment #24
lokapujyaFinish comment with a period.
An editor can get into this same state if they fail to use a unique label for the action. At this point, you cannot change the machine name, and need to hit the back button. Not the coolest UX, but that is a separate issue.
Comment #27
mohit_aghera CreditAttribution: mohit_aghera as a volunteer and at Axelerant for Red Hat commentedUpdating changes mentioned by @lokapujya
Applying patch on 8.3.x branch.
Comment #30
Chi CreditAttribution: Chi commentedThe patch is outdated.
Comment #31
jofitz CreditAttribution: jofitz at ComputerMinds commentedRe-rolled.
Comment #33
jofitz CreditAttribution: jofitz at ComputerMinds commentedAddressed test failures.
Comment #34
andypostNew methods needs CR, also "locked" discussed in #2289551: Clarify what 'locked' means for a config entity and whether it's okay for code to rely on a locked config entity existing
Comment #43
needs-review-queue-bot CreditAttribution: needs-review-queue-bot as a volunteer commentedThe Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #45
andypostLooks closely related #3150316: Configured actions created by User module cannot be edited
Actions locking probably can be moved to contrib, but not clear yet with views+user #3427413: Stop using action in user module in role entity hooks
Comment #46
andypost