Extension documents edit protection and Main.WebHome

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Extension documents edit protection and Main.WebHome

Thomas Mortagne
Administrator
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...)

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
Reply | Threaded
Open this post in threaded view
|

Re: Extension documents edit protection and Main.WebHome

Ecaterina Moraru (Valica)
On Tue, Nov 7, 2017 at 1:00 PM, Thomas Mortagne <[hidden email]>
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.
>
> 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.

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.

Thanks,
Caty


>
> --
> Thomas Mortagne
>
Reply | Threaded
Open this post in threaded view
|

Re: Extension documents edit protection and Main.WebHome

Ecaterina Moraru (Valica)
In reply to this post by Thomas Mortagne
On Tue, Nov 7, 2017 at 1:00 PM, Thomas Mortagne <[hidden email]>
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
>
Reply | Threaded
Open this post in threaded view
|

Re: Extension documents edit protection and Main.WebHome

Ecaterina Moraru (Valica)
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) <[hidden email]
> wrote:

>
>
> On Tue, Nov 7, 2017 at 1:00 PM, Thomas Mortagne <[hidden email]
> > 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
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Extension documents edit protection and Main.WebHome

Thomas Mortagne
Administrator
In reply to this post by Ecaterina Moraru (Valica)
On Tue, Nov 7, 2017 at 1:02 PM, Ecaterina Moraru (Valica)
<[hidden email]> wrote:

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

And there is that too which makes this option even more difficult to apply.

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

Since 90% of the pages coming from extensions ares stuff nobody should
touch I really don't think this is a good idea.

> 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
Reply | Threaded
Open this post in threaded view
|

Re: Extension documents edit protection and Main.WebHome

Eduard Moraru
Hi,

One option I was discussion with Caty that would cover the need to not have
code pages modified, while also allowing devs (including us) to work and
experiment is that we only add a warning/banner in edit mode on pages
belonging to an extension, informing the user that their changes *will be
discarded when upgrading* and what he could do instead, to keep them.

So, when upgrading to a new version, we would have the following directions
to decide on:

1) We could show the list of modified extensions with options for each
extensions (not each document) to:
a) discard changes
b) backup changes
c) merge changes (I would personally not be in favor of keeping this, since
it will be too tempting for everyone to abuse it and we would be back at
the current state when upgrades take a very long time and are hard to do)

2) We could simply discard any modifications done on the extensions and
upgrade to the newest version (i.e. never do the 3-way merge)


The main idea is that you are free to do changes and experiment, but if you
want your work to be used in production or to survive an upgrade, you need
to do one of the following things:

A) Contribute your changes so that they are included in the next version of
the application.

B) Publish your changes as a fork of the application. Optionally, it could
be a light fork which only contains the modified pages and has a fixed
version dependency on the standard application. It will be your job to keep
your fork up to date, otherwise you will be stuck using an older version of
the application. If the application is part of the Standard Flavor and
because of the fixed dependency version, it will mean you will not be able
to upgrade XWiki either until you update your fork first. If you don't use
a fixed version dependency, you risk upgrading the standard application to
a version that is no longer compatible with your changes.

Thanks,
Eduard

On Tue, Nov 7, 2017 at 4:16 PM, Thomas Mortagne <[hidden email]>
wrote:

> On Tue, Nov 7, 2017 at 1:02 PM, Ecaterina Moraru (Valica)
> <[hidden email]> wrote:
> > On Tue, Nov 7, 2017 at 1:00 PM, Thomas Mortagne <
> [hidden email]>
> > 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.
> >>
> >> 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.
>
> And there is that too which makes this option even more difficult to apply.
>
> >
> >
> >>
> >> 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.
>
> Since 90% of the pages coming from extensions ares stuff nobody should
> touch I really don't think this is a good idea.
>
> > 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Extension documents edit protection and Main.WebHome

Eduard Moraru
The second topic of interest was the extension pages that are designed to
be modified, like the demo AWM apps or intro blog post, homepage, etc.

1) IMO, all these pages should be separated from the code pages of an
extension and moved to a "-content" extension. At this point, we could
introduce a flag on a XAR extension that its pages are modifiable and all
the above described limitations will not be enforced and, on upgrade, the
user would be free to choose what happens to the changes (i.e. discard,
backup or even merge).

2) The second option would be to explicitly mark (in the extension
descriptor ?) modifiable pages inside a XAR extension, so to continue
mixing code pages with content pages, but I would prefer we would not
continue to do it. I guess this would be towards proposal 3) from Thomas,
but I think I would prefer it to be done from an extension level, and not
page level (since that would imply editing the page and might collide with
previous decisions).

Thanks,
Eduard

On Tue, Nov 7, 2017 at 4:43 PM, Eduard Moraru <[hidden email]> wrote:

> Hi,
>
> One option I was discussion with Caty that would cover the need to not
> have code pages modified, while also allowing devs (including us) to work
> and experiment is that we only add a warning/banner in edit mode on pages
> belonging to an extension, informing the user that their changes *will be
> discarded when upgrading* and what he could do instead, to keep them.
>
> So, when upgrading to a new version, we would have the following
> directions to decide on:
>
> 1) We could show the list of modified extensions with options for each
> extensions (not each document) to:
> a) discard changes
> b) backup changes
> c) merge changes (I would personally not be in favor of keeping this,
> since it will be too tempting for everyone to abuse it and we would be back
> at the current state when upgrades take a very long time and are hard to do)
>
> 2) We could simply discard any modifications done on the extensions and
> upgrade to the newest version (i.e. never do the 3-way merge)
>
>
> The main idea is that you are free to do changes and experiment, but if
> you want your work to be used in production or to survive an upgrade, you
> need to do one of the following things:
>
> A) Contribute your changes so that they are included in the next version
> of the application.
>
> B) Publish your changes as a fork of the application. Optionally, it could
> be a light fork which only contains the modified pages and has a fixed
> version dependency on the standard application. It will be your job to keep
> your fork up to date, otherwise you will be stuck using an older version of
> the application. If the application is part of the Standard Flavor and
> because of the fixed dependency version, it will mean you will not be able
> to upgrade XWiki either until you update your fork first. If you don't use
> a fixed version dependency, you risk upgrading the standard application to
> a version that is no longer compatible with your changes.
>
> Thanks,
> Eduard
>
> On Tue, Nov 7, 2017 at 4:16 PM, Thomas Mortagne <[hidden email]
> > wrote:
>
>> On Tue, Nov 7, 2017 at 1:02 PM, Ecaterina Moraru (Valica)
>> <[hidden email]> wrote:
>> > On Tue, Nov 7, 2017 at 1:00 PM, Thomas Mortagne <
>> [hidden email]>
>> > 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.
>> >>
>> >> 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.
>>
>> And there is that too which makes this option even more difficult to
>> apply.
>>
>> >
>> >
>> >>
>> >> 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.
>>
>> Since 90% of the pages coming from extensions ares stuff nobody should
>> touch I really don't think this is a good idea.
>>
>> > 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
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Extension documents edit protection and Main.WebHome

Ecaterina Moraru (Valica)
And then there are pages that you want users to EDIT in inline mode, but
not in wiki, example: User Profile, Dashboard.

UserDirectory is also problematic, but it's using view mode to allow
customizations.


On Tue, Nov 7, 2017 at 4:58 PM, Eduard Moraru <[hidden email]> wrote:

> The second topic of interest was the extension pages that are designed to
> be modified, like the demo AWM apps or intro blog post, homepage, etc.
>
> 1) IMO, all these pages should be separated from the code pages of an
> extension and moved to a "-content" extension. At this point, we could
> introduce a flag on a XAR extension that its pages are modifiable and all
> the above described limitations will not be enforced and, on upgrade, the
> user would be free to choose what happens to the changes (i.e. discard,
> backup or even merge).
>
> 2) The second option would be to explicitly mark (in the extension
> descriptor ?) modifiable pages inside a XAR extension, so to continue
> mixing code pages with content pages, but I would prefer we would not
> continue to do it. I guess this would be towards proposal 3) from Thomas,
> but I think I would prefer it to be done from an extension level, and not
> page level (since that would imply editing the page and might collide with
> previous decisions).
>
> Thanks,
> Eduard
>
> On Tue, Nov 7, 2017 at 4:43 PM, Eduard Moraru <[hidden email]>
> wrote:
>
> > Hi,
> >
> > One option I was discussion with Caty that would cover the need to not
> > have code pages modified, while also allowing devs (including us) to work
> > and experiment is that we only add a warning/banner in edit mode on pages
> > belonging to an extension, informing the user that their changes *will be
> > discarded when upgrading* and what he could do instead, to keep them.
> >
> > So, when upgrading to a new version, we would have the following
> > directions to decide on:
> >
> > 1) We could show the list of modified extensions with options for each
> > extensions (not each document) to:
> > a) discard changes
> > b) backup changes
> > c) merge changes (I would personally not be in favor of keeping this,
> > since it will be too tempting for everyone to abuse it and we would be
> back
> > at the current state when upgrades take a very long time and are hard to
> do)
> >
> > 2) We could simply discard any modifications done on the extensions and
> > upgrade to the newest version (i.e. never do the 3-way merge)
> >
> >
> > The main idea is that you are free to do changes and experiment, but if
> > you want your work to be used in production or to survive an upgrade, you
> > need to do one of the following things:
> >
> > A) Contribute your changes so that they are included in the next version
> > of the application.
> >
> > B) Publish your changes as a fork of the application. Optionally, it
> could
> > be a light fork which only contains the modified pages and has a fixed
> > version dependency on the standard application. It will be your job to
> keep
> > your fork up to date, otherwise you will be stuck using an older version
> of
> > the application. If the application is part of the Standard Flavor and
> > because of the fixed dependency version, it will mean you will not be
> able
> > to upgrade XWiki either until you update your fork first. If you don't
> use
> > a fixed version dependency, you risk upgrading the standard application
> to
> > a version that is no longer compatible with your changes.
> >
> > Thanks,
> > Eduard
> >
> > On Tue, Nov 7, 2017 at 4:16 PM, Thomas Mortagne <
> [hidden email]
> > > wrote:
> >
> >> On Tue, Nov 7, 2017 at 1:02 PM, Ecaterina Moraru (Valica)
> >> <[hidden email]> wrote:
> >> > On Tue, Nov 7, 2017 at 1:00 PM, Thomas Mortagne <
> >> [hidden email]>
> >> > 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.
> >> >>
> >> >> 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.
> >>
> >> And there is that too which makes this option even more difficult to
> >> apply.
> >>
> >> >
> >> >
> >> >>
> >> >> 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.
> >>
> >> Since 90% of the pages coming from extensions ares stuff nobody should
> >> touch I really don't think this is a good idea.
> >>
> >> > 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
> >>
> >
> >
>