Currently, the only way for allowing users to delete scheduled transitions, the administer scheduled transitions permission has to be given. This also gives access to the scheduled transitions settings form, which is not always the desired behavior.
Just as there are per entity type & bundle permissions for "view" and "add" operations, I think it would be logical to provide the same for "delete" operations.
| Comment | File | Size | Author |
|---|---|---|---|
| #19 | interdiff_18-19.txt | 907 bytes | falc0 |
| #19 | scheduled_transitions-delete_permissions-3082728-19.patch | 21.12 KB | falc0 |
| #18 | scheduled_transitions-delete_permissions-3082728-18.patch | 21.12 KB | mjmorley |
| #17 | scheduled_transitions-delete_permissions-3082728-17.patch | 21.12 KB | rp7 |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
rp7 commentedA first attempt at this, be gentle :-)
I had (possibly still have) a hard time grasping my head around access mirroring.
Comment #3
rp7 commentedComment #5
rp7 commentedFixing a few tests. Still WIP.
Comment #6
dpiAre you sure this is true?
I think if the user has access to delete the associated entity, they will also have access to delete the scheduled transition.
Understandably having permission to do both isnt always desired, perhaps this issue should be about implementing mirror operation functionality?
As far as the patch approach goes, take a look at ScheduledTransitionsRouteProvider.php and copy the _entity_access things from there, and override the
getDeleteFormRoutemethod. Changes to\Drupal\scheduled_transitions\ScheduledTransitionsAccessControlHandler::checkAccessare not necessary.You basically need to add an extra Delete section whereever the existing Add/View operation logic happens, there shouldnt be any Delete specific code (e.g new code in
ScheduledTransitionsAccessControlHandler::checkAccess)config/install/scheduled_transitions.settings.yml needs to be modified and an update path for existing sites is required. Mirror 'delete' to 'update' sounds logical.
Comment #7
rp7 commentedRe-rolled patch against latest dev.
@dpi You may very well be right. I'll have to investigate it further. I'm hopeful I can find some time soon.
Comment #8
dpiSimilar work is undertaken in #3119360: Reschedule transitions, which will be posted in the near future.
Comment #9
rp7 commentedHi @dpi
Correct.
Correct.
Re-rolled patch against 2.x & is now more in line with the solution in #3119360: Reschedule transitions. The upgrade path (update hook) is probably not complete yet.
Bare in mind that this functionality is also impacted by the issue mentioned in #3179616: Rescheduling not possible without "View all scheduled transitions" permission.
Comment #10
rp7 commentedComment #11
rp7 commentedNow without the same mistake for delete operations as in #3118123: Custom access rules impossible for scheduled transitions.
Comment #13
rp7 commentedThis fixes at least 1 failed assertion. Will need help with the other one (same a in [#3118123).
Comment #14
falc0 commentedUpdated to the latest version (2.2.1).Wrong file, correct one in next comment.
Comment #15
falc0 commentedComment #16
alfattal commented@falc0 Patch in #15 failed to apply.
Comment #17
rp7 commentedFixed patch in #15 so that it applies to 2.3.x
Comment #18
mjmorley commentedAdded a patch here to update the hook update number so it applies to 2.4.x
Comment #19
falc0 commentedHad an error:
Error: Call to undefined method Drupal\node\Entity\Node::isProcessed() in Drupal\scheduled_transitions\ScheduledTransitionsAccessControlHandler->checkAccess() (line 55 of /app/web/modules/contrib/scheduled_transitions/src/ScheduledTransitionsAccessControlHandler.php).Fixed it in the latest patch (see interdiff).