Discourage extension pages changes

Last modified by Ecaterina Moraru (Valica) on 2018/11/29 13:24




  • 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


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


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 help.
  • 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.


Use rights to forbid edit on some pages but it does not covers non advanced admin use case or what do do during upgrade.


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



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


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


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


Proposal 3: Mix of protect and Discourage

  • basic user: no edit button
  • advanced user: highly discouraged
  • developers: non blocker warning



Get Connected