Re: [xwiki-devs] Extension documents edit protection and Main.WebHome

Another problem are the default AWM apps, where we encouraged users to add their own class properties. This mechanism won't encourage this behavior anymore. On Tue, Nov 7, 2017 at 2:22 PM, Ecaterina Moraru (Valica) <valicac(a)gmail.com > > > On Tue, Nov 7, 2017 at 1:00 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com > > >> 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 >> > >