[MGNLUI-2939] Reconfigure availability of de/activation actions in Pages app Created: 26/May/14  Updated: 15/Oct/14  Resolved: 11/Jul/14

Status: Closed
Project: Magnolia UI
Component/s: pages app
Affects Version/s: 5.0
Fix Version/s: 5.2.7, 5.3.1

Type: Improvement Priority: Neutral
Reporter: Zdenek Skodik Assignee: Peili Liang
Resolution: Fixed Votes: 0
Labels: quickwin, support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MGNLUI-3053 Reconfigure availability of de/activa... Closed
relates to MGNLUI-3036 Availability of duplicate action does... Closed
causality
is causing MGNLDEMO-361 Eric can edit & publish while Peter i... Closed
relation
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:
Epic Link: publishActionsAvailability

 Description   

Since any de/activation request actually attempts to write to involved node/s, to update its metadata, the actions should be implicitly allowed only for users having write permissions to them. Since MGNLUI-2510 it's trivial to restore this former 4.5 like behaviour. Thes to any actions resulting in write events.



 Comments   
Comment by Mikaël Geljić [ 10/Jul/14 ]

Quoting Evzen on MGNLUI-3053

Action "activateRecursive" should be affected too, but isn't right now.
When you log in as user peter and go to pages, you still can active "Publish incl. subpage"s on pages with subpages (i think it shouldn't be able).

This is because workflow module (EE) reconfigures "activateRecursive", "activateDeletion" and "deactivate" actions to extend "activate" (see InstallWorkflowForPagesTask).
So it's not the case in CE, i.e. we have to set writePermissionRequired individually on all of these de/activation actions.

Generated at Mon Feb 12 09:01:38 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.