Discourage extension pages changes
Version 17.10 by Ecaterina Moraru (Valica) on 2017/11/09 18:14
- [xwiki-devs] Extension documents edit protection and Main.WebHome (Nov 7, 2017) http://markmail.org/thread/bsh3jowuwqaucuz7
Description
- Purpose
- Requirements
- Ideas: Warning location
- Alternatives
- Extension Structure
- Proposals
Purpose
- Warn users when modifying pages that have application logic since their changes might break functionality (Target: users)
- Limiting changes on default applications will assure a simpler upgrade (Target: developers)
Requirements
UC: Edit modes: we might want to block/warn on some modes (wiki, objects) while permitting the other modes (Inline, WYSIWYG)
UC: Some edits might be programmatic, is there a way to forbid / warn on those?
UC: Warn the user that he is editing a special page from the start. Don't let the user find out it in a second step or at upgrade
UC: If changes have been made to extension pages, be able to revert to the initial state (by History or EM)
UC: At upgrade, if extension pages have changes, be able to backup them in a separate location, while replacing them with the new extension version
UC: Find a solution that can be applied in a consistent manner over edit, move, delete actions
UC: Extensions should keep separate technical/code pages, from content/demo pages and from configurations.
UC: Developers should be able to still edit the extension pages in a easy way
UC: Provide a report in EM about the extensions that have modified pages, before running the upgrade
UC: If there are configurations that need to be added by users, rewrite the extension so that these changes don't impact the upgrade
Ideas: Warning location
- Notification - missable
- Banner (with UIX)
- permanent
- dismissible
- Editor
- Notification widget, like Save messages
- Read-only textarea
- Save reject
- Warning above save button
- Warning above title
- Panel with a warning macro
- Modal
- Warning macro on action template (edit, move)
- Step before, like lock mechanism
- Step after, like delete extension
Alternatives
Block changes
- No matter the user type (user, admin or developer), don't allow editing of extension pages
- If someone wants to extend the application it should fork it or use it as a dependency
Protect changes
- Disallow edits for users / admins, but allow to developers
- Consider developers as advanced users and consider they know what they are doing
Discourage changes
- Warn all editors about the consequences, but don't disallow edits
Extension Structure
Code / Technical pages (A)
- Should not be editable by users
- Decide if developers need a preference in order to edit
Configurations (B)
- Should be editable by admins (or by users if app allows it)
- we should enforce that configurations (WebPreferences, ConfigurableClass, ?customize=true) should be available in the Administration. The only exception is for apps that allow users to create individual configurations (My Dashboard, My Menu, My User Directory, etc.)
- configurations should not be auto-generated since the default values are used to compare and reset to
Content / Demo pages (C)
- Content pages should be editable by normal users
- Demo content should be packaged separate and allow deletion
- Content pages could be autogenerated, but some pages have translations
- Move is not allowed in any case
- Edition is allowed in B. and C.
- Deletion is allowed in C. (maybe in B. as a way to reset)
Proposals
Proposal 1: Protect changes
- Don't allow edit, move and delete actions if the page comes from an extension
- The target for these actions are users and admins. We need to find a solution for developers.
- Make sure Configuration pages are accessible in Administration and that Code pages are separate from Content pages
- We could implement this as a convention, or using Rights added on the extension's pages
- other ideas?
Proposal 1.1: User Preferences
- Introduce an User Profile preference that can be set and allow extension page editing. Default it should be false. Developers should activate this preference.
Proposal 1.2: XWikiDevGroup
- Create a default group called XWiki.XWikiDevGroup
- Make sure all extensions allow edit and delete rights only for this group for their technical pages
- Administrators could add users interested in developing / modifying applications in that particular group
- Ideally, developers would extend the applications in a manner that won't affect the upgrades
- Test and add the rights for all default and recommended extensions
Proposal 1.3
- Plug into the rights system (implement the corresponding component, similar to what we did with the AuthorizationSettler on the licensing-licensor) to deny edit and delete on extension pages at the platform level
Proposal 2: Discourage changes
- Warn all editors about the consequences, but don't disallow edits
- If we pick Proposal 1 and protect changes for users and admins, than this proposal would apply only for the Developer persona
Proposal 2.0: Mark Edit button differently
- On extension pages where actions are discouraged, mark the actions in a special manner allowing the users to know in advanced they will get a warning without the need to perform a click
- We should be careful when marking the actions differently in order to be recognisable but not drawing too much attention on them and transforming the action in an invitation instead of a warning
Before
After
Proposal 2.0.1: Lock
Proposal 2.0.2: Warning Color icon
Proposal 2.0.3: Warning Color icon + text
Proposal 2.1: Modal on Edit button
- When the user is pressing the "Edit" button display a modal warning the user about the type of page he want to edit
Before
Modal 1
- Similar to what was used on the Delete step
Modal 2
- According to Bootstrap modal structure
Proposal 2.2: Modal when entering Edit mode
- Display a modal when entering the Edit mode. If the user is pressing "Cancel" he will still be able to view the syntax version, hidden status, syntax code, but the editor and save buttons will be disabled
Before
Proposal 2.3:
Before