Problem/Motivation
In the parent issue it was discovered that there are two tests that are not in the action module that are installing an Action. Following plugins are node_assign_owner_action, node_unpublish_by_keyword_action and comment_unpublish_by_keyword_action which may need the Actions UI module for configuration.
catch pointed out that those plugins don't make sense without a UI, so we should also consider moving them to the Action UI module. That is what this issue is for.
There is also user_add_role_action, user_remove_role_action which need configuration but they are managed by user module hooks user_user_role_insert() and user_user_role_delete()
For background, these are all the Action plugins in a core module.
- comment_unpublish_by_keyword_action
- node_make_unsticky_action
- node_make_sticky_action
- node_unpublish_by_keyword_action
- node_unpromote_action
- node_assign_owner_action',
- node_promote_action
- user_cancel_user_action
- user_add_role_action
- user_remove_role_action
- user_block_user_action
- user_unblock_user_action
Followup from #3343369-17: [meta] Tasks to deprecate Actions UI module
Steps to reproduce
Review
Move remaining plugins
Proposed resolution
Move the following to the Action UI module.
node_unpublish_by_keyword_actioncomment_unpublish_by_keyword_actionnode_assign_owner_action
Remaining tasks
Review
Still need to look into the 3 plugins that have not been moved.
user_add_role_action, user_remove_role_action per @andypost in comment 26
this actions should stay in core as they are used by user_user_role_insert() and user_user_role_delete
node_assign_owner_action can be moved so proposed solution was updated.
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|
Issue fork drupal-3413949
Show commands
Start 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:
Comments
Comment #4
taraskorpachI've also moved the UnpublishByKeywordComment. It would be good if you could take a look at it. By the way, the tests aren't running because an old plugin is missing.
Comment #5
catchLooks like there's something to review here. The test coverage changes will conflict with #3369914: Move non-migrations tests to Actions module.
Comment #6
smustgrave commentedThink this is postponed until the tests move. Unless we temporarily fix tests here and then fully remove in #3369914: Move non-migrations tests to Actions module but that doesn't sound right.
Comment #7
quietone commentedSince a core committer set this to needs review stating that "there's something here to review". I am setting this back to needs review.
For myself, I see that the moving of the plugins can be removed. And also the remaining tasks identifies more plugins that need to me. The fact that a conflict will happen should not stop this work which we would like to complete in 10.3.
Comment #8
smustgrave commentedAlright I’ll tag and leave for someone else from the initiative to review. But appears there are test failure.
Comment #10
spokjeI don't want to mees up the MR created by @taraskorpach so I started a new one.
Comment #14
spokjeSorry for the noise, my approach turned out to be the same approach. Closed and hid my MR.
So the reason the MR fails lies in the migration subsystem, I think NR is a nice status to attract some attention from people with Big Brains who know about that stuff.
Comment #15
smustgrave commented#3369914: Move non-migrations tests to Actions module has been merged, didn't check to see if this MR is rebased fully but there should be no conflict now but there are currently test failures.
Comment #16
quietone commentedI often forget about the action migrations because they are in the system module. They were failing because the moved plugins were no longer found. To fix this the first step was to prevent the existing action migrations, d6_action and d7_action, from migrating these two plugins (See the use of the static_map plugin in the process pipeline). Then in the action module add a hook_migration_plugins_alter to alter the static map so these plugins will migrate. Tests have been added and changed accordingly for this.
And then all the migration Upgrade tests action entity counts are updated for 2 less Action plugins being migrated.
Comment #17
quietone commentedOn reflection, I am not sure why I listed those other plugins to be moved.
Comment #18
spokjeLooking at the IS:
Where the two mentioned action plugins are
node_unpublish_by_keyword_actionandcomment_unpublish_by_keyword_action.The other plugins as mentioned by @quietone in #17 are:
I think the question here is, do these three plugins make sense without a UI?
Comment #19
wim leersI think from the point of view of minimizing disruption, the answer is "yes".
Comment #20
smustgrave commentedSo if it's determined they need a UI what's next steps here?
Comment #21
wim leersI did not mean that — sorry for not being more clear.
I meant the plugins still make sense even without a UI — because the functionality will keep working even if a UI is only provided after installing a contrib module.
(Similar example for core: https://www.drupal.org/project/restui)
Comment #22
danielvezaJust did a review of a MR, had a couple of small nits and some questions around the deprecations
Comment #23
quietone commentedComment #24
smustgrave commentedSeems feedback has been addressed in the MR.
For the concern about the namespace it should remain the same once removed to contrib. I checked VBO https://git.drupalcode.org/project/views_bulk_operations/-/blob/4.2.x/sr... who's namespace is Drupal\views_bulk_operations\Plugin\Action;
Comment #25
mstrelan commentedIs there a follow up for the three other issues mentioned in the IS?
user_add_role_action,user_remove_role_action,node_assign_owner_actionComment #26
andypostre #25 this actions should stay in core as they are used by
user_user_role_insert()anduser_user_role_deleteBut
node_assign_owner_actionhas tests in action.module so probably should be done hereComment #27
andypostDeprecated
node_assign_owner_actionComment #28
andypostMoved forgotten config schema to action module
Few tests still fail after deprecation of
node_assign_owner_actionRemoved strict types declaration as tests started to fail https://git.drupalcode.org/issue/drupal-3413949/-/pipelines/108578
Comment #29
andypostMoved
node_assign_owner_actionComment #30
andypostChecked usage in contrib and the action has only few usages http://codcontrib.hank.vps-private.net/search?text=node_assign_owner_act...
So I updated IS and CR to include
node_assign_owner_actionComment #31
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #32
andypostrebased
Comment #33
andypostAlso fixed both plugins to use new render function #2511308: Rename RendererInterface::renderPlain() to ::renderInIsolation()
Comment #34
andypostIt's the last blocker for #3369912: Final steps to deprecate Actions UI (action) module
Comment #35
smustgrave commentedUpdated the issue summary to show 3 actions are moving and the other 2 are staying in core.
Move of the 3 seems fine
Marking now to get Actions deprecation finalized.
Comment #38
catchCommitted/pushed to 11.x and cherry-picked to 10.3.x, thanks!
I think for
user_add_role_action,user_remove_role_actionI think it's worth a follow-up to discuss. i.e. for me it's weird that user hooks call out to actions, user can directly use its own APIs in these cases. But that would be at least one issue to refactor user hooks to not depend on actions, then another to move them, so scope here seems fine.Committed/pushed to 11.x and cherry-picked to 10.3.x, thanks!
Comment #39
catchComment #42
catchReverted due to:
https://git.drupalcode.org/project/drupal/-/jobs/1047019
Comment #43
andypost11.x already has it
Comment #44
andypostIt was old ctools in modules
Comment #45
andypostFollow-up filed #3427413: Stop using action in user module in role entity hooks (also found few related issues)
Comment #46
spokjeThanks @andypost for the removal of just the
ExpectDeprecationTrait.Comment #49
catchAlso opened #3427549: [PP-1] Move configurable user actions to the actions module as a follow-up to the follow-up, we can always decide not to do that, but I think it's worth discussing in its own issue (and also not trying to do here because it's not as simple).
Committed/pushed to 11.x and cherry-picked to 10.3.x, thanks!
Comment #50
andypostThanks, looks everything fine now and CR can be published
Comment #51
andypostPlease close the MR and the remaining issue is #3369912: Final steps to deprecate Actions UI (action) module