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) <[email protected] > wrote: > > > On Tue, Nov 7, 2017 at 1:00 PM, Thomas Mortagne <[email protected] > > 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 >> > >
