7 Nov
2017
7 Nov
'17
1:22 p.m.
On Tue, Nov 7, 2017 at 1:00 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
Hi devs,
We started to think about https://jira.xwiki.org/browse/XWIKI-14377
with Caty and she noticed that it might not be as simple as "all
extensions pages are protected" because there is extensions pages that
are almost always supposed to be modified: first example is
Main.WebHome which is modified 99% of the time but another good one is
Sandbox or Quicklinks panel.
Another example is Blog.BlogIntroduction that people might want to delete,
or even some categories like Blog.Personal, or any other apps that provide
demo content. User might want to delete even Help.Applications.Contributors
or Help.Applications.Movies
When we talk about edit it's more easy since people will have the History
to rollback to the initial version, but if the upgrade ignores the edited
page who can an admin also upgrade this page?
Also if someone will delete Help.Applications.Contributors and won't be
able to restore it from Recycle Bin, if this is considered "content" data,
will there still be a way to reinstall it?
So we need a way to tell that an app comes with:
- vital pages that shouldn't be modified if we want a smooth upgrade,
- content / demo pages that users are encouraged to edit and make their
own. These pages will be ignored and kept in the user version during an
upgrade, but in case someone did something to them, there is a way to
rollback to them or reinstall them (but this use case is very rare,
especially since the pages were not vital).
- user generated content that will be appended to any upgrade and kept as
backup in case the app is uninstalled.
So what do we do about it ?
I'm not fully sure yet but here are some ideas :
1) So what ? It's still extension pages and you might still have
conflicts during next upgrade. If you want standard pages to be
modified then generate them during install.
2) Only show the warning when a page is hidden and consider all non
hidden pages as OK to modify
3) Explicitly mark each standard page that is OK to be modified with
some xobject
3.a) EM XAR handler behave with these pages as it always did
3.b) EM XAR handler has a special support for these pages controlled
by one of the xobject fields (skip the document from any merge if
there is any customization, always overwrite any customization, etc.)
WDYT ?
1) might be too harsh, generating Main.WebHome might be doable (but
still a pain to maintain) but it's quite a pain to generate the whole
Sandbox space (and not even talking about maintaining it...)
2) we might still want to see some application home pages in the
search result and most of them should really not be modified
3.a) will still have the "what should I do" effect sometime for pages
that user is allowed to modify
3.b) has my preference right now, sounds like the nicest from user and
author point of view, can even be used for other use cases than edit
protection control
--
Thomas Mortagne