Rename Action module to Actions UI in the UI and in comments

Hi Naveen , I have little confusion . The title says "Rename action module to action_ui in the UI and in comments" . Does that means on "admin/module" also, apart from comments.

Thanks Naveen for the clarification . As per the suggestion in '2083649' #41 . I have changed the description & comment in action.module file.

Changes like this should be AFAIK first communicated/discussed with the UX team.

For the time being, the Actions module includes some action plugins which are not related to actions UI. Shall we first move them to System module or somewhere else?

Actions module includes some action plugins which are not related to actions UI.

Besides this there are migrate templates in it.

Actions moved to core in #2815379: Move message, goto, and email action plugins to Drupal\Core\Action
Now rename can continue

The patch looks good to me. All that is changed are a couple of things.

What about #14?

@Chi: I the META issue #2083649: Rename action module to action_ui are sub-issues linked, including the stuff that you are asking about.

Reroll #21

Probably it could close related issue

@Chi - only migrations and tests left so filed separate issue #3067299: Move actions migrations and tests to system module

One more mention fixed

There is a problem with the following test: Drupal\Tests\system\Functional\Module\InstallUninstallTest.

My bad, fixed

The patch looks good to me. All that is changed are a couple of things.

Back to RTBC.

I think that module renames should have some sort of BC layer. I feel like there needs to be a core policy for how we plan to handle these types of changes.

Works for me!

@see:

But, here too should not be Actions UI?

But, here too should not be Actions UI?

That's a label for a list of actions not for the module. So "Actions" is Ok I think.

But the help page calls it the "Actions UI page". The help should match the page title. So either the help needs to be updated, or the page title needs to be updated. I would vote for leaving the page title as it is.

I have made changes as suggested in #43 and recreated patch.

Hi All,

I made all the changes here is the patch.

Thanks & Regards,
Gnanagowthaman sankar

Here is the patch.

PLEASE make an interdiff file when you add a new patch to an issue that has already had several patches. This lets us see what is different.

PLEASE also go back and actually read #43, which suggests NOT changing the routing and links. Naming the page "Action UI" does not make sense to me. We don't name the admin/structure/views page "Views UI". The module is called "Views UI" but the page is called "Views". The same thing should be done here.

Apologies @jhodgdon
am newbie for creating patch. Here after i will make interdiff.txt if many patches exist. Hereby I attached the interdiff and the patch.

I'm sorry for getting frustrated. It is really much better if one person makes a patch, sees the comments, makes another patch, etc. rather than having 10 people contributing patches and not really building on each others' work. This issue has seen many many patches that basically ignored what had gone before, and people coming into the issue and not apparently reading the issue comments.

Anyway. This patch still has many problems. I will be specific this time, looking at the latest patch in #48.

a) actions.module:

/**
  * @file
- * This is the Action UI module for executing stored actions.
+ * This is the Actions module for executing stored actions.
  */

This is wrong. The *module* is now called "Actions UI".

b) actions.module inside the hook_help:
Modules can also provide additional actions ui.
This is wrong. Modules can provide *actions*.

c) actions.module inside the hook_help:

Simple actions ui

This is wrong. They are simple actions.

d) also in hook_help

Advanced actions ui

This is wrong. They are advanced actions.

e) also in hook help twice:

Actions UI page

This is wrong. The page should be called Actions not Actions UI.

f) also in hook_help:

There are two types of actions ui

two types of actions

g)

+++ b/core/modules/action/action.links.menu.yml
@@ -1,5 +1,5 @@
 action.admin:
-  title: Actions
+  title: Actions UI

This is wrong. This is the link to the page, and should be called Actions not Actions UI.

@jhodgdon Am extremely sorry for making you frustrated. Here i had attached the changes as you mentioned and attached diff file. Please let me know for any changes.

The changes here look correct, except:

 Other modules can trigger these actions ui

in the hook_help. It should just be "actions" not "actions ui".

I am unsure about whether there are other places in core that need changes. I only reviewed the changes that were made in this patch, and verified that they are (mostly) OK.

Hi @jhodgdon,

I made the changes in the patch as you mentioned in the comment #51, And let me know whether any changes have to be made. Here by i am attaching the interdiff file and the patch file.

Thanks & Regards,
Gnanagowthaman Sankar

Thanks

When you post a patch, rather than manually adding tests, you should set the issue status to Needs Review (which will automatically launch the tests, and it also signals human reviewers that you have a patch that is ready to be reviewed). Thanks!

Anyway, this patch doesn't have any problems that I can see.

I'm removing the accessibility review tag -- I can't see why changing the name of a module is an accessibility issue.

Hi @jhodgdon, Am newbie to this patch work. As per your guidelines i will do that in future. And wont let the mistakes happen in future. sorry and thanks.

Thanks & Regards,
Gnanagowthaman sankar

No worries! I was just posting instructions so you would know for other patches in the future. Anyway I think I should mark this RTBC actually, although it still needs to be reviewed by the product managers to see if it is a change we actually want to make.

Thank you so much @jhodgdon for your help. Ok sure.

Unrelated test fail #3103492: Random fail in WidgetUploadTest

As #3022401: Remove useless config action.settings.recursion_limit landed this issue and #3067299: Move actions migrations and tests to system module are 2 remaining blockers for final rename

Has this had a UX review? I remember @webchick having concern with this pattern of naming and having separate modules UI modules when we did the last batch of these.

Here's what we have in core right now for modules with this name pattern:

modules/menu_ui/menu_ui.info.yml:name: Menu UI
modules/migrate_drupal_ui/migrate_drupal_ui.info.yml:name: 'Migrate Drupal UI'
modules/views_ui/views_ui.info.yml:name: 'Views UI'
modules/field_ui/field_ui.info.yml:name: 'Field UI'

In all those cases the UI name reflects the machine name. Changing the machine name for the module is not in scope for Drupal 9; however, is the goal here just to point out that Actions is a user interface only and that the actual actions APIs are core subsystems? That might be OK, but we should have UX review at least (or product feedback).

Updated summary a bit

Would need to happen in 9.1 now, still needs product manager sign-off.

Patch for 9.1.x

Looks like it's "Actions UI" (plural actions).

Let's try this.

We reviewed this on today's usability meeting: #3137865: Drupal Usability Meeting 2020-06-09

The list of existing X UI modules in #61 is helpful. Most of my pushback on issues like this has been around the seeming arbitrariness of why we sometimes do and sometimes don't split the modules from their UI, and carefully balancing when we choose to increase the "mental load" of site builders by forcing them to turn on two things for the one feature they're trying to get.

However, for the most part (Menu UI feels like kind of a weird outlier...), the existing "de-facto" standard in core seems to be that we do a "X vs. X UI" split when:

• We're talking about a generic architectural building block exposed by core which has utility outside the module itself (Fields, Views), esp. when going in and "tweaking" those settings after the fact might break your site. In this case, the extra cognitive load infers a benefit of increased security.
• Core is providing an initial stab at a very minimal UI, but it's understood and encouraged that contrib might build more expansive options (Drupal Migrate UI). This allows you to uninstall the module to get it out of the way when a more fully-featured UI is available. Again, extra cognitive load infers a benefit (lack of duplication in UI).

It seems like Actions falls under both of those criteria. It's a generic architectural concept, exposed by other modules. And the Actions UI is very simple; Rules is the go-to example of a "beefed up" UI in contrib for the same concept (though sadly not the same actual architectural piece, AFAIK).

We discussed this as a team, and folks were +1 for the patch, and did not see a particular need to hold it up on #3067299: Move actions migrations and tests to system module, though it would be cleaner that way. We also found a fun bug in user module's actions naming which someone will post here. ;)

Created this child issue for the bug we saw:
#3150316: Configured actions created by User module cannot be edited

I grepped all instances of "Actions" in core (capitalized and not), and skimmed them for any other things that appear to be the UI label of the module. This is extra fun because we also have a kind of menu link called "actions", form actions (submit/cancel buttons), etc. among all the other various meanings. ;)

In action.routing.yml, there is:

entity.action.collection:
  path: '/admin/config/system/actions'
  defaults:
    _title: 'Actions'
    _entity_list: 'action'
  requirements:
    _permission: 'administer actions'

...but that is a page for administering actions, so it wouldn't make sense to have "UI" on the link.

Similarly in action.links.menu.yml:

action.admin:
  title: Actions
  description: 'Create tasks that the system can execute.'
  route_name: entity.action.collection
  parent: system.admin_config_system

That seems fine too.

There are also a few comments like:
// Create a user with permission to view the actions administration pages.
...but arguably that's correct as well, since they are both the Actions UI administration pages, and the pages on which actions are administered.

Everything else that I saw appeared to be clearly referring to "actions" as in the entities themselves, or was unrelated to this module.

I took care of updating https://www.drupal.org/docs/8/core/modules/action/overview, so crediting myself for that.

However, as I was about to commit this, I re-read the following in light of my grep:

+++ b/core/modules/action/action.module
@@ -18,13 +18,13 @@ function action_help($route_name, RouteMatchInterface $route_match) {
-      $output .= '<dd>' . t('<em>Simple actions</em> do not require configuration and are listed automatically as available on the <a href=":actions">Actions page</a>.', [':actions' => Url::fromRoute('entity.action.collection')->toString()]) . '</dd>';
+      $output .= '<dd>' . t('<em>Simple actions</em> do not require configuration and are listed automatically as available on the <a href=":actions">Actions UI page</a>.', [':actions' => Url::fromRoute('entity.action.collection')->toString()]) . '</dd>';
...
-      $output .= '<dd>' . t('<em>Advanced actions</em> are user-created and have to be configured individually. Create an advanced action on the <a href=":actions">Actions page</a> by selecting an action type from the drop-down list. Then configure your action, for example by specifying the recipient of an automated email message.', [':actions' => Url::fromRoute('entity.action.collection')->toString()]) . '</dd>';
+      $output .= '<dd>' . t('<em>Advanced actions</em> are user-created and have to be configured individually. Create an advanced action on the <a href=":actions">Actions UI page</a> by selecting an action type from the drop-down list. Then configure your action, for example by specifying the recipient of an automated email message.', [':actions' => Url::fromRoute('entity.action.collection')->toString()]) . '</dd>';

I'm not convinced these changes are actually correct. The linked pages are the action administrations pages. (See what I said above about the link and route labels.) Either we should also change the official names of those pages, or (my preference, we should back out these two changes to the help documentation. If we want to disambiguate it, we could call it the "Action administration" page or something. Or just remove these changes from the patch. Thanks!

This issue is very close but has now stalled for a few years. Lets get this moving forward :).

I've checked the patch, it still applies to 10.1.x, I've done a grep of actions, like @xjm said it's very hard with how common the word is. It did uncover that changes need to be made in the help topics module, so I've made the changes there as well.

Re: #73, I like "Actions administration page" so I've made that change as well.

Fixing that failing test

First test fail was a random fail. Tests passing on second run. Ready to review

Patch #81 is applied successfully on drupal 10.1.x and working fine, Rename the Action module to Action UI.
Refer to screenshot
Thank you

Moving too RTBC as changes shows correctly

Thanks for getting this issue started again.

I found some missed strings in Help Topics with the patch applied:

[ayrton:maintainer | Mon 12:43:22] $ grep -rEi "actions module" *| grep -v "vendor" | grep -v "node_modules"
core/modules/help_topics/help_topics/views.overview.html.twig:<p>{% trans %}Views using a table display format can include a bulk operations form, which allows users with sufficient permission to select one or more items from the view and apply an administrative action to them. The bulk actions available are specific to the base data type of the view; for example, a view of content items could support bulk publishing and unpublishing actions. If you have the core Actions module installed, see the related topic "Configuring actions" for more about actions.{% endtrans %}</p>
core/modules/help_topics/help_topics/views_ui.bulk_operations.html.twig:<p>{% trans %}Add one or more existing actions as bulk operations to an existing table-style view. If you have the core Actions module installed, see the related topic "Configuring actions" for more information about actions.{% endtrans %}</p>

Fixing attribution.

Creating a patch based on Daniel's one, adding the Help Topics strings according to the XJM suggestions

Hey @sergiogsanchez, could you please post an interdiff between the previous patch and your new one? It would be helpful for reviewers to be able to ensure only the relevant changes have been made.

There is a guide to interdiffs here if needed https://www.drupal.org/docs/develop/git/using-git-to-contribute-to-drupa...

Hi @DanielVeza, thanks for the heads up; attaching the interdiff from 81 to 89.

Thanks for that. Setting back to RTBC

It looked like there was no change record for this issue, so I created one:
https://www.drupal.org/node/3331881

I verified that the online help is updated with the correct name:
https://www.drupal.org/docs/8/core/modules/action

I considered whether the URL aliases should be renamed to actions_ui. However, I checked and confirmed other core modules have URL aliases based on their machine names, not the user-facing labels. I did add redirects from the user-facing label variant in case anyone tries to type it in.

I reviewed with git diff --color-words and confirmed that this is:

• Mostly just adding "UI" after "Actions" when it refers to the module name.
• Clarifying the name of the "Actions administration page"
• In one spot, changing "Action" to "Actions UI".

I also carefully grepped the codebase for other uses of "Actions" or "Action" as a capitalized word, with

grep -rE "\bActions\b" * --color

From that grep, we still need to fix the following places:

core/MAINTAINERS.txt:Actions
core/modules/action/tests/src/Functional/ActionUninstallTest.php: * Tests that uninstalling Actions does not remove other modules' actions.

I believe the labels in the following file are correct as-is, since they refer to the collection of actions and not the module itself:

core/modules/action/action.links.menu.yml:  title: Actions
core/modules/action/action.routing.yml:    _title: 'Actions'

Then with:

grep -rE "\bAction\b" * --color

There's this one:

core/modules/action/action.post_update.php: * Post update functions for Action module.

Sorry for not catching these three the first time!

Good catch! Updated those references. There were 2x in ActionUninstallTest.php, updated them both.

Hi, I checked the code standards on 2811663-95.patch; all the suggested strings were updated correctly according to previous comments. I tested the patch, and it works as expected on the Drupal extend page and help pages; I checked the maintainers file, test files; and comments updated.

Noting in the IS that that has product manager and a usability review.

unrelated failure

Whilst we aim to remove this module from core by D11, I think its useful to have the rename now.

Committed to 10.1.x, published change record

Thank you! Linked meta