Discourage extension pages changes

Version 17.10 by Ecaterina Moraru (Valica) on 2017/11/09 18:14

 
 Requirements
 Active
 
 

Description

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
before_edit_advanced.png

After

Proposal 2.0.1: Lock

after_edit_advanced_1.png

after_edit_advanced_1_expanded.png

Proposal 2.0.2: Warning Color icon

after_edit_advanced_2.png

after_edit_advanced_2_expanded.png
after_edit_actions_2_expanded.png

Proposal 2.0.3: Warning Color icon + text

after_edit_advanced_3.png

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
before_AllDocs_view.png

Modal 1

  • Similar to what was used on the Delete step
    modal_P1.png

Modal 2

  • According to Bootstrap modal structure
    modal_P2.png

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
before_AllDocs_edit.png

Proposal 2.3:

Before
.png


 

Tags:
    

Get Connected