Discourage extension pages changes
Last modified by Vincent Massol on 2024/02/26 17:57
- [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
- How to type extension pages
- Proposals
Purpose
- Warn users/admins that:
- Modifying an extension page might have bad impact on the extension behavior
- Modifying an extension might make more much more difficult to upgrade it
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
Protected pages
Examples: Code, Technical pages (A)
- Should not be editable by users
- Decide if developers need a preference in order to edit
Indirectly modified pages
Examples: XWikiPreferences, badly designed application not generating configuration page
- Should be protected from direct edit and only modifiable trough UI by default
Directly modified pages
Examples: Demo content, flavor home page
- Content pages should be editable by normal users
- Demo content should be packaged separate and allow deletion
- Content pages could be autogenerated, but a huge pain to maintain without even talking about dealing with translations
- Move is forbidden in all cases.
- Edition is allowed in C.
- Deletion is allowed in C
.
- A user can be put in "developer mode" to disable all protections (when actually writing applications which is something that happen in the wiki too). Probably keep a warning on the side.
How to type extension pages
XObject based markers
An xobject indicating how an extension page is supposed to be protected/merged:
- forbidden to directly modify it, 3 ways merge during upgrades
- forbidden to directly modify it, don't touch it during upgrade if there is any change
- forbidden to directly modify it, don't touch it during upgrade (change or not)
- any direct modification is allowed, don't touch it during upgrades if there is any change
- any direct modification is allowed, don't touch it during upgrades (change or not)
- direct edit allowed but delete is forbidden
- ...
Default being: forbidden to directly modify it, 3 ways merge during upgrade. That's the most common use case by far which allow configuring only a few pages.
Descriptor based markers
Same as previous but indicated in the descriptor to not pollute the pages.
Rights
Use rights to forbid edit on some pages but it does not covers non advanced admin use case or what do do during upgrade.
Proposals
Proposal 1: Protect changes
- For forbidden direct edit pages: No edit button at all
- Not forbidden direct edit pages: No complains
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.3: Cookie
- In order to facilitate for developers the option selected, remember it in a cookie
Proposal 1.2: XWikiDevGroup group
- Create a default group called XWiki.XWikiDevGroup
- Administrators could add users interested in developing / modifying applications in that particular group
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
- The problem is that the users could still edit the pages by following Index / AWM livetable actions or directly from the URL
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
- Proposal 2.2.1
- On "Cancel" go the user in View mode
- Proposal 2.2.2
- On "Cancel" show the editor in read-only mode
Before
Proposal 2.3: Warning step before edit
- Similar to what we do when forcing Edit mode, we could display a warning before entering edit mode
After
Proposal 3: Mix of protect and Discourage
- basic user: no edit button
- advanced user: highly discouraged
- developers: non blocker warning
