7 Nov
2017
7 Nov
'17
3:16 p.m.
On Tue, Nov 7, 2017 at 1:02 PM, Ecaterina Moraru (Valica)
<valicac(a)gmail.com> wrote:
Since 90% of the pages coming from extensions ares stuff nobody should
touch I really don't think this is a good idea.
On Tue, Nov 7, 2017 at 1:00 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>
wrote:
And there is that too which makes this option even more difficult to apply.
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.
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...)
Don't forget that some of these pages are localized.
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
Not sure how hard would be technically, but instead of an exception list, I
would like an inclusion list. We talked so much in the past about Application
Descriptor and we also have
some patterns put in place, like placing the code inside a Code space and
mark the technical pages hidden.
I believe all the content pages of an application should be editable by
user and should be ignored during an upgrade, but all the technical / code
pages should not be encouraged to edit and they will need to be upgraded on
new releases.
Instead of marking what pages should be ignored, we should mark what pages
we should upgrade and restrict from editing, thus defining the
application's structure and descriptor.
The only downside with this approach is that it's more work to do, since
there are fewer 'content' (some Homepages, some demo content) pages inside
our applications, than the technical pages.
Also if we were to go into the application description direction we might
want to move the pages in a nested structure, enforcing the rules we have
on application structure. But this might mean a lot of work and we need to
be convinced of the benefits.
Also this goes beyond editing and also we would want
to warn on other
operations, like move, delete. Marking what pages are ok to Edit, would not
provide us information if that page is ok to move and thus won't break the
application.
Actually 3.b support well all that since the whole point is to
indicate what kind of page it is (the page need to exist but can be
modified, the page can be deleted, the page should never be modified,
etc.). Default being "nobody should touch this page in any way" since
that's what we want for most pages.
Thomas also talked about a preference in the User Profile that would allow
editing and won't display the warning, intended for developers to ease
their work. This is one aspect to consider, the other is if we want special
permissions for some users, like administrators.
This is a different subject IMO.
Thanks,
Caty
>
> --
> Thomas Mortagne
>
--
Thomas Mortagne