This issue does not have consensus.

By default, config entity list controllers show enable and disable operations. These are usually implemented as one-click action links.

The problem with this is (and see #1834002: Configuration delete operations are all over the place) that links perform GET requests, and those are not supposed to cause side-effects. Instead, we should remove these, and probably add a checkbox to entity edit forms with which we can control whether an entity is enabled.

Comments

tim.plunkett’s picture

Issue tags: +VDC

Tagging. No opinions formed yet.

andypost’s picture

Issue tags: -VDC

OTOH we could find a way to use enable/disable
For example a contact forms could be disabled...
Anyway better to hide this links on entities that does not use status

Originally it was introduced in #1826602: Allow all configuration entities to be enabled/disabled
And here's a change notice

andypost’s picture

Issue tags: +VDC
xjm’s picture

Title: Remove enable/disable entity operations » Remove enable/disable entity operations from dropbuttons

Retitling for what I think the issue is actually about.

Jury's still out in my head as well. :)

Xano’s picture

Title: Remove enable/disable entity operations from dropbuttons » Remove enable/disable entity operations

Drupal\Core\Entity\EntityListControllerInterface::getOperations() says it Provides an array of information to build a list of operation links. The actual problem is that we are using links for tasks that should never be performed using links, whether those links are displayed as dropbuttons or not. Operation links should be used for navigation, and not for actions. See @ircmaxell's comment in #1834002: Configuration delete operations are all over the place for a better explanation.

OTOH we could find a way to use enable/disable
For example a contact forms could be disabled...

My idea was to allow entities that have statuses to be enabled/disabled using a checkbox in the edit form. I think this possibility should be available regardless of whether we remove these operation links, but that's a more personal opinion.

tim.plunkett’s picture

Issue tags: +Usability

Tagging.

xjm’s picture

Yeah, I'm still not sold on this. IMO, operations one might perform on an entity include things like: Edit, Delete, Enable, Disable. I don't think some purism about what's links vs. buttons is reason for us to make it more work to perform these common operations, and I especially don't think it makes any sense whatsoever to change it at the controller level because the word "link" is used in documentation when in practice these are rendered in a dropbutton.

Bojhan’s picture

I don't get what usability impact this has.

Xano’s picture

I especially don't think it makes any sense whatsoever to change it at the controller level because of a word used in documentation when in practice these are rendered in a dropbutton.

The word used in documentation says that those operations are intended to be used as links, which use HTTP GET. If we want to follow the HTTP spec (which I think we should), we can't perform certain operations using GET, such as enable/disable/delete, because those operations have consequences and should be performed using a different HTTP method. We actually do only display operations as links. The reason I quoted the docs, was to illustrate that we purposefully decided to use links incorrectly.

Besides, this issue is about HTML buttons (which can be used to perform non-GET requests), not HTML lists with links (which can only perform GET requests) that we style to look like buttons.

xjm’s picture

I don't get what usability impact this has.

The usability impact is that the options to enable or disable or a view are no longer available to quickly select from the dropbutton at (e.g.) admin/structure/views, and you have to dig around in the Views UI to find an option to enable or disable the view. The more I think about it, the more I'm -1. If we need to have a confirm form so be it, but those operations should be available on that page.

yoroy’s picture

Xano: try and use as simple and specific as possible wording in your issue title. Also, it helps to state the problem first instead of a solution.

I think we are supposed to help content creators, builders, devs in roughly that order. Putting a specification in front of that listing doesn't seem useful to me.

What is the problem with GET, how big is that (potential) problem and how does that measure up against the usability trade-off?

Xano’s picture

See @ircmaxell's comment in #1834002: Configuration delete operations are all over the place for a better technical explanation about why using GET for actions is a problem.

I think we are supposed to help content creators, builders, devs in roughly that order. Putting a specification in front of that listing doesn't seem useful to me.

I agree that the dropbuttons are extremely useful, but the specific technical implementation of one-click actions violates the HTTP specifications. This means that the implementation is buggy (and requires additional workarounds, such as CSRF tokens), but not the feature itself.

xjm’s picture

Issue summary: View changes

Updated issue summary.

Xano’s picture

Issue summary: View changes
Status: Active » Closed (won't fix)

With CSRF protection built into our routing system, I don't think this is really an issue anymore.