Hide Quick Edit on published content [#2894874]

Problem/Motivation

Quick Edit and Workbench Moderation don't play well together because Quick Edit doesn't understand Workbench Moderation's versioning model. Unfortunately, Quick Edit still shows up on published content (which is effectively a locked workflow state), even when forward revisions of that content exist.

Proposed resolution

When viewing published content at its canonical route (e.g., /node/32), disable Quick Edit entirely.

Remaining tasks

Create a pull request and merge it.

User interface changes

Quick Edit will not show up on published content.

Comments

Comment #1

14 July 2017 at 13:48

phenaproxima created an issue. See original summary.

Comment #2

phenaproxima

he/him

English

Massachusetts

CreditAttribution: phenaproxima at Acquia commented 14 July 2017 at 13:48

Status:

Active

» Needs review

Pull request created: https://github.com/acquia/lightning/pull/404

Comment #3

14 July 2017 at 15:16

balsama committed aa44ca2 on 8.x-2.x authored by phenaproxima

Issue #2894874 by phenaproxima: Hide Quick Edit on published content

Comment #4

balsama

he/him

English

boston

CreditAttribution: balsama at Acquia commented 14 July 2017 at 15:16

Status:

Needs review

» Fixed

Thanks!

Comment #5

28 July 2017 at 15:19

Status:

Fixed

» Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

Comment #6

phenaproxima

he/him

English

Massachusetts

CreditAttribution: phenaproxima at Acquia commented 28 July 2017 at 15:57

Status:

Closed (fixed)

» Active

In the wake of other work I've done recently, I think we need to re-open this and think more about it.

Wim Leers explained to me that Quick Edit respects entity access. In other words...if you can access the Edit tab for a node, you can quick edit it. That is how Quick Edit was written. That is how it wants to work. Trying to cripple Quick Edit, while maintaining edit access in other ways, is a recipe for pain and suffering that gets exponentially messier when you introduce the concept of forward revisions, largely because Quick Edit has no concept of them.

I think we need to backtrack, re-evaluate our approach, and work with Quick Edit, not against it. If you can access an entity's edit form, you should be able to quick edit it too. Likewise, if you can't access the edit form, you shouldn't be able to quick edit. It should be completely consistent. What this means is that we'll be able to stop maintaining torturous, brittle UI-level tomfoolery in favor of very solid and clear cases where we can say confidently whether something should be editable or not.