23 Apr
2018
23 Apr
'18
12:27 p.m.
Hi devs,
When dealing with extension pages protection we ended up with a very
visible issue: EVERYONE customize the home page so it does not make
much sense to warn every user trying to edit it that it's dangerous
and might break the extensions.
Since it's not the only use case 10.3 introduce the concept of XAR
entry type which allow controlling a bit more edit/delete and upgrade
behavior. See
http://extensions.xwiki.org/xwiki/bin/view/Extension/XAR+Module+Specificati…
for more details.
On component side it's possible to decide the default type of a page
reference (that's where "Main.WebHome" type come from currently). It's
also possible to override the upgrade behavior for a specific type or
even a specific reference for more exotic use cases.
So it's now possible to control the type you want for a page at XAR
descriptor level. I already typed a few page, for example
"Main.WebHome" is now of type "home" which means "it's OK to
edit it
and you should only upgrade it if no customization have been made".
Cool home page is covered but we now entered a new era of endless
debates to decide of what type some page should be and what other
types to introduce :)
We are not going to discuss all these in this mail so everyone with a
doubt should start a discussion for a standard page (or a set of
standard page which are obviously very similar like color themes).
Currently, protected page produce a warning that you can force. The
plan in 10.4 is to keep the warning only for advanced completely
prevent basic user to modify protected pages by default and also allow
configuring all that (indicate in your profile that you don't want to
be bothered with that, override edit/delete right even for advanced
users, etc.). But before that we need to make sure basic users are
allowed to edit all the pages they are supposed to edit.
Happy tuning :)
--
Thomas Mortagne
23 Apr
23 Apr
12:39 p.m.
Dashboard.WebHome should be editable.
FlamingoThemes.* should be editable in order for users to set custom logos.
XWiki.DefaultSkin should be editable for the same logo reason.
Thanks,
Caty
On Mon, Apr 23, 2018 at 1:27 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
Hi devs,
When dealing with extension pages protection we ended up with a very
visible issue: EVERYONE customize the home page so it does not make
much sense to warn every user trying to edit it that it's dangerous
and might break the extensions.
Since it's not the only use case 10.3 introduce the concept of XAR
entry type which allow controlling a bit more edit/delete and upgrade
behavior. See http://extensions.xwiki.org/xwiki/bin/view/Extension/XAR+
Module+Specifications#Hpackage.xml
for more details.
On component side it's possible to decide the default type of a page
reference (that's where "Main.WebHome" type come from currently). It's
also possible to override the upgrade behavior for a specific type or
even a specific reference for more exotic use cases.
So it's now possible to control the type you want for a page at XAR
descriptor level. I already typed a few page, for example
"Main.WebHome" is now of type "home" which means "it's OK to
edit it
and you should only upgrade it if no customization have been made".
Cool home page is covered but we now entered a new era of endless
debates to decide of what type some page should be and what other
types to introduce :)
We are not going to discuss all these in this mail so everyone with a
doubt should start a discussion for a standard page (or a set of
standard page which are obviously very similar like color themes).
Currently, protected page produce a warning that you can force. The
plan in 10.4 is to keep the warning only for advanced completely
prevent basic user to modify protected pages by default and also allow
configuring all that (indicate in your profile that you don't want to
be bothered with that, override edit/delete right even for advanced
users, etc.). But before that we need to make sure basic users are
allowed to edit all the pages they are supposed to edit.
Happy tuning :)
--
Thomas Mortagne
1:40 p.m.
As I indicated it would be better if you could send other mail to
discuss those pages separately (there is already one for the the
themes) :)
On Mon, Apr 23, 2018 at 12:39 PM, Ecaterina Moraru (Valica)
<valicac(a)gmail.com> wrote:
Dashboard.WebHome should be editable.
FlamingoThemes.* should be editable in order for users to set custom logos.
XWiki.DefaultSkin should be editable for the same logo reason.
Thanks,
Caty
On Mon, Apr 23, 2018 at 1:27 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
> Hi devs,
>
> When dealing with extension pages protection we ended up with a very
> visible issue: EVERYONE customize the home page so it does not make
> much sense to warn every user trying to edit it that it's dangerous
> and might break the extensions.
>
> Since it's not the only use case 10.3 introduce the concept of XAR
> entry type which allow controlling a bit more edit/delete and upgrade
> behavior. See http://extensions.xwiki.org/xwiki/bin/view/Extension/XAR+
> Module+Specifications#Hpackage.xml
> for more details.
>
> On component side it's possible to decide the default type of a page
> reference (that's where "Main.WebHome" type come from currently).
It's
> also possible to override the upgrade behavior for a specific type or
> even a specific reference for more exotic use cases.
>
> So it's now possible to control the type you want for a page at XAR
> descriptor level. I already typed a few page, for example
> "Main.WebHome" is now of type "home" which means "it's
OK to edit it
> and you should only upgrade it if no customization have been made".
>
> Cool home page is covered but we now entered a new era of endless
> debates to decide of what type some page should be and what other
> types to introduce :)
>
> We are not going to discuss all these in this mail so everyone with a
> doubt should start a discussion for a standard page (or a set of
> standard page which are obviously very similar like color themes).
>
> Currently, protected page produce a warning that you can force. The
> plan in 10.4 is to keep the warning only for advanced completely
> prevent basic user to modify protected pages by default and also allow
> configuring all that (indicate in your profile that you don't want to
> be bothered with that, override edit/delete right even for advanced
> users, etc.). But before that we need to make sure basic users are
> allowed to edit all the pages they are supposed to edit.
>
> Happy tuning :)
>
> --
> Thomas Mortagne
>
--
Thomas Mortagne
25 Apr
25 Apr
6:49 p.m.
By the way this is not only about XWiki Standard. We also need to
think about entry type in contrib extensions you know.
On Mon, Apr 23, 2018 at 1:40 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
As I indicated it would be better if you could send
other mail to
discuss those pages separately (there is already one for the the
themes) :)
On Mon, Apr 23, 2018 at 12:39 PM, Ecaterina Moraru (Valica)
<valicac(a)gmail.com> wrote:
--
Thomas Mortagne
Dashboard.WebHome should be editable.
FlamingoThemes.* should be editable in order for users to set custom logos.
XWiki.DefaultSkin should be editable for the same logo reason.
Thanks,
Caty
On Mon, Apr 23, 2018 at 1:27 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
> Hi devs,
>
> When dealing with extension pages protection we ended up with a very
> visible issue: EVERYONE customize the home page so it does not make
> much sense to warn every user trying to edit it that it's dangerous
> and might break the extensions.
>
> Since it's not the only use case 10.3 introduce the concept of XAR
> entry type which allow controlling a bit more edit/delete and upgrade
> behavior. See http://extensions.xwiki.org/xwiki/bin/view/Extension/XAR+
> Module+Specifications#Hpackage.xml
> for more details.
>
> On component side it's possible to decide the default type of a page
> reference (that's where "Main.WebHome" type come from currently).
It's
> also possible to override the upgrade behavior for a specific type or
> even a specific reference for more exotic use cases.
>
> So it's now possible to control the type you want for a page at XAR
> descriptor level. I already typed a few page, for example
> "Main.WebHome" is now of type "home" which means "it's
OK to edit it
> and you should only upgrade it if no customization have been made".
>
> Cool home page is covered but we now entered a new era of endless
> debates to decide of what type some page should be and what other
> types to introduce :)
>
> We are not going to discuss all these in this mail so everyone with a
> doubt should start a discussion for a standard page (or a set of
> standard page which are obviously very similar like color themes).
>
> Currently, protected page produce a warning that you can force. The
> plan in 10.4 is to keep the warning only for advanced completely
> prevent basic user to modify protected pages by default and also allow
> configuring all that (indicate in your profile that you don't want to
> be bothered with that, override edit/delete right even for advanced
> users, etc.). But before that we need to make sure basic users are
> allowed to edit all the pages they are supposed to edit.
>
> Happy tuning :)
>
> --
> Thomas Mortagne
>
--
Thomas Mortagne 
26 Apr
26 Apr
1:45 p.m.
Hi, Thomas,
I'm having some difficulties understanding the available types and their
intent.
- default: used to force the default. Edit and delete are not allowed
and a 3-way merge is applied to the document during upgrades.
Shouldn't the default upgrade action be "keep new", specially if edit and
delete is restricted on the page? The assumption would be that it's a code
page and any unsaved modifications (e.g. as a fork extension) should be
overridden by the new version of the extension's code.
- configuration: a document containing configuration. Edit is allowed
and the document is never upraded.
Normally, configuration is among the only things you might actually want to
make a choice on, as someone running an upgrade. It does not make much
sense to never upgrade a configuration document, specifically when you have
just added a new feature. Thinking of package managers (i.e. apt's dpkg),
they allow specifying beforehand or even answering interactively on the
action to take (merge/new/old) for the configuration files of a package
being upgraded. Also, the general default for config files is "merge" and
not "keep old".
- home: a wiki home page. Edit is allowed and the document is upgraded
only if it's not been customized.
- demo: a document which purpose is to provide demo data. Edit and
delete are allowed and the document is upgraded only if it's not been
customized.
I don't really understand the distinction between "home" and
"demo". AFAICS
from the definition, "home" is not supposed to be deleted, but why would we
want to enforce such a restriction? If we are talking about wiki homepages,
we can already configure that in the wiki descriptor as "Main.WebHome" is
not really a fixed entrypoint/API. For application homepages, I fail to see
the need to edit them, so I believe they should use "demo" instead of
"home".
IMO, "Main.WebHome" should be set to "demo" since that is what it
really
is. We expect the admin to edit it with his needs.
AFAIU, "demo" makes sense and "configuration" is mostly something that
the
admin might choose, with a default of "merge".
Thanks,
Eduard
On Wed, Apr 25, 2018 at 7:49 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
By the way this is not only about XWiki Standard. We
also need to
think about entry type in contrib extensions you know.
On Mon, Apr 23, 2018 at 1:40 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
--
Thomas Mortagne
As I indicated it would be better if you could
send other mail to
discuss those pages separately (there is already one for the the
themes) :)
On Mon, Apr 23, 2018 at 12:39 PM, Ecaterina Moraru (Valica)
<valicac(a)gmail.com> wrote:
> Dashboard.WebHome should be editable.
> FlamingoThemes.* should be editable in order for users to set custom
logos.
> XWiki.DefaultSkin should be editable for the
same logo reason.
>
> Thanks,
> Caty
>
> On Mon, Apr 23, 2018 at 1:27 PM, Thomas Mortagne <
thomas.mortagne(a)xwiki.com>
> wrote:
>
>> Hi devs,
>>
>> When dealing with extension pages protection we ended up with a very
>> visible issue: EVERYONE customize the home page so it does not make
>> much sense to warn every user trying to edit it that it's dangerous
>> and might break the extensions.
>>
>> Since it's not the only use case 10.3 introduce the concept of XAR
>> entry type which allow controlling a bit more edit/delete and upgrade
>> behavior. See http://extensions.xwiki.org/
xwiki/bin/view/Extension/XAR+
>
Module+Specifications#Hpackage.xml
> for more details.
>
> On component side it's possible to decide the default type of a page
> reference (that's where "Main.WebHome" type come from currently).
It's
> also possible to override the upgrade behavior for a specific type or
> even a specific reference for more exotic use cases.
>
> So it's now possible to control the type you want for a page at XAR
> descriptor level. I already typed a few page, for example
> "Main.WebHome" is now of type "home" which means "it's
OK to edit it
> and you should only upgrade it if no customization have been made".
>
> Cool home page is covered but we now entered a new era of endless
> debates to decide of what type some page should be and what other
> types to introduce :)
>
> We are not going to discuss all these in this mail so everyone with a
> doubt should start a discussion for a standard page (or a set of
> standard page which are obviously very similar like color themes).
>
> Currently, protected page produce a warning that you can force. The
> plan in 10.4 is to keep the warning only for advanced completely
> prevent basic user to modify protected pages by default and also allow
> configuring all that (indicate in your profile that you don't want to
> be bothered with that, override edit/delete right even for advanced
> users, etc.). But before that we need to make sure basic users are
> allowed to edit all the pages they are supposed to edit.
>
> Happy tuning :)
>
> --
> Thomas Mortagne
>
--
Thomas Mortagne
2:35 p.m.
On Thu, Apr 26, 2018 at 1:45 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
Hi, Thomas,
I'm having some difficulties understanding the available types and their
intent.
- default: used to force the default. Edit and delete are not allowed
and a 3-way merge is applied to the document during upgrades.
Shouldn't the default upgrade action be "keep new", specially if edit and
delete is restricted on the page? The assumption would be that it's a code
page and any unsaved modifications (e.g. as a fork extension) should be
overridden by the new version of the extension's code.
On upgrade side I much prefer to have the default being what always
been the default and introduce new behavior in new types. Also think
this is what we want for the majority of pages, there is stuff that
you could add to a page without really thinking about it as a
customization, that you will want to keep and which are not dangerous
for merge (like comments, restrict access to some application, etc.).
Simply to keep merging as safe as possible you get a string warning
when going trough standard editing of those pages where you could have
an impact on what constitute the hearth of what this page is supposed
to do.
- configuration: a document containing configuration. Edit is allowed
and the document is never upraded.
Normally, configuration is among the only things you might actually want to
make a choice on, as someone running an upgrade. It does not make much
sense to never upgrade a configuration document, specifically when you have
just added a new feature. Thinking of package managers (i.e. apt's dpkg),
they allow specifying beforehand or even answering interactively on the
action to take (merge/new/old) for the configuration files of a package
being upgraded. Also, the general default for config files is "merge" and
not "keep old".
There is different ways of seeing this. First dpkg is not really an
accurate comparison IMO, I think you missed the fact that
"configuration" here is for configuration data only usually, the
assumptions is that the class and administration UI for example would
be in a different documents so you do get new properties during
upgrade. But the behavior supposedly stay the same after upgrade, i.e.
it's not modified by a change in the provided default configuration
(the idea being to allow the extension author to change default
configuration for new install without disturbing old ones). This is
exactly what happen with application that are using generated
configuration page right now, one of the ideas behind this type is
that you can use it instead of a (sometimes complex) configuration
generation logic.
But yes there is not only one kind of configuration and the point of
me listing the quick types I introduced in 10.3 is also to ask for new
ones to have a good coverage of various common use cases even if
extension can also come with their own type too.
- home: a wiki home page. Edit is allowed and the document is upgraded
only if it's not been customized.
- demo: a document which purpose is to provide demo data. Edit and
delete are allowed and the document is upgraded only if it's not been
customized.
I don't really understand the distinction between "home" and
"demo". AFAICS
from the definition, "home" is not supposed to be deleted, but why would we
want to enforce such a restriction? If we are talking about wiki homepages,
we can already configure that in the wiki descriptor as "Main.WebHome" is
not really a fixed entrypoint/API.
Yes in theory the wiki home page is configurable but I really doubt
this actually happen much and it's not very nice to delete the wiki
home page for various reasons. Now it was a quickly introduce type
because I had this use case in mind but we could decide to make it a
demo and rely on another system to check if the page is the configured
home page before warning about it.
For application homepages, I fail to see
the need to edit them, so I believe they should use "demo" instead of
"home".
Did you mean default ? "demo" does not make sense for application home
page since you don't want to edit them as you said. Most application
home pages will use default type for me.
And yes those are not the target of "home" type. I did not really had
any other use case in mind than Main.WebHome when I introduced it but
assume other pages could be in a similar situation :)
IMO, "Main.WebHome" should be set to "demo" since that is what it
really
is. We expect the admin to edit it with his needs.
I still prefer to protect the wiki home page against delete by default
but not strongly enough to not be OK with your proposal if other think
it's better like this.
AFAIU, "demo" makes sense and "configuration" is mostly something
that the
admin might choose, with a default of "merge".
Thanks,
Eduard
Any other type you can think of that would worth being introduced in
XWiki Standard ? IMO it can even be a type that have the same behavior
than another right now, the idea being that with the current
architecture a component can overwrite a specific type, introduce a
custom upgrade component for a specific type or that we could decide
to change the way we deal with some type of document in the future for
some reason (having the documents already using the right type in
extensions would help a lot when that time comes :)).
On Wed, Apr 25, 2018 at 7:49 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
> By the way this is not only about XWiki Standard. We also need to
> think about entry type in contrib extensions you know.
>
> On Mon, Apr 23, 2018 at 1:40 PM, Thomas Mortagne
> <thomas.mortagne(a)xwiki.com> wrote:
> > As I indicated it would be better if you could send other mail to
> > discuss those pages separately (there is already one for the the
> > themes) :)
> >
> > On Mon, Apr 23, 2018 at 12:39 PM, Ecaterina Moraru (Valica)
> > <valicac(a)gmail.com> wrote:
> >> Dashboard.WebHome should be editable.
> >> FlamingoThemes.* should be editable in order for users to set custom
> logos.
> >> XWiki.DefaultSkin should be editable for the same logo reason.
> >>
> >> Thanks,
> >> Caty
> >>
> >> On Mon, Apr 23, 2018 at 1:27 PM, Thomas Mortagne <
> thomas.mortagne(a)xwiki.com>
> >> wrote:
> >>
> >>> Hi devs,
> >>>
> >>> When dealing with extension pages protection we ended up with a very
> >>> visible issue: EVERYONE customize the home page so it does not make
> >>> much sense to warn every user trying to edit it that it's dangerous
> >>> and might break the extensions.
> >>>
> >>> Since it's not the only use case 10.3 introduce the concept of XAR
> >>> entry type which allow controlling a bit more edit/delete and upgrade
> >>> behavior. See http://extensions.xwiki.org/
> xwiki/bin/view/Extension/XAR+
> >>> Module+Specifications#Hpackage.xml
> >>> for more details.
> >>>
> >>> On component side it's possible to decide the default type of a
page
> >>> reference (that's where "Main.WebHome" type come from
currently). It's
> >>> also possible to override the upgrade behavior for a specific type or
> >>> even a specific reference for more exotic use cases.
> >>>
> >>> So it's now possible to control the type you want for a page at XAR
> >>> descriptor level. I already typed a few page, for example
> >>> "Main.WebHome" is now of type "home" which means
"it's OK to edit it
> >>> and you should only upgrade it if no customization have been
made".
> >>>
> >>> Cool home page is covered but we now entered a new era of endless
> >>> debates to decide of what type some page should be and what other
> >>> types to introduce :)
> >>>
> >>> We are not going to discuss all these in this mail so everyone with a
> >>> doubt should start a discussion for a standard page (or a set of
> >>> standard page which are obviously very similar like color themes).
> >>>
> >>> Currently, protected page produce a warning that you can force. The
> >>> plan in 10.4 is to keep the warning only for advanced completely
> >>> prevent basic user to modify protected pages by default and also allow
> >>> configuring all that (indicate in your profile that you don't want
to
> >>> be bothered with that, override edit/delete right even for advanced
> >>> users, etc.). But before that we need to make sure basic users are
> >>> allowed to edit all the pages they are supposed to edit.
> >>>
> >>> Happy tuning :)
> >>>
> >>> --
> >>> Thomas Mortagne
> >>>
> >
> >
> >
> > --
> > Thomas Mortagne
>
>
>
> --
> Thomas Mortagne
>
--
Thomas Mortagne
4:34 p.m.
On Thu, Apr 26, 2018 at 3:35 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
On Thu, Apr 26, 2018 at 1:45 PM, Eduard Moraru
<enygma2002(a)gmail.com>
wrote:
I do get where you are coming from. However, if you consider that "default"
restricts editing, you should normally not end up with unwanted stuff like
comments on a code page.
Regarding rights, that's a more realistic problem we have in the current
model. Until we come up with a solution that does not store rights as
objects inside the page, we don't have much choice.
However, this opens up another question: How does this (setting rights on a
code page that has "default" type) work with the lack of edit rights on the
page (i.e. you would not be able to set the rights in the first place,
because the page can't be edited)? Or maybe when you say "not allowed to
edit/delete", you simply refer to the small "warning" curtain in the UI
that only discourages the user to do the operation, but he can force it
anyway?
Hi, Thomas,
I'm having some difficulties understanding the available types and their
intent.
- default: used to force the default. Edit and delete are not allowed
and a 3-way merge is applied to the document during upgrades.
Shouldn't the default upgrade action be "keep new", specially if edit and
delete is restricted on the page? The assumption would be that it's a
code
page and any unsaved modifications (e.g. as a
fork extension) should be
overridden by the new version of the extension's code.
On upgrade side I much prefer to have the default being what always
been the default and introduce new behavior in new types. Also think
this is what we want for the majority of pages, there is stuff that
you could add to a page without really thinking about it as a
customization, that you will want to keep and which are not dangerous
for merge (like comments, restrict access to some application, etc.).
Simply to keep merging as safe as possible you get a
string warning
when going trough standard editing of those pages where you could have
an impact on what constitute the hearth of what this page is supposed
to do.
Right.
- configuration: a document containing configuration. Edit is allowed
and the document is never upraded.
Normally, configuration is among the only things you might actually want
to
make a choice on, as someone running an upgrade.
It does not make much
sense to never upgrade a configuration document, specifically when you
have
just added a new feature. Thinking of package
managers (i.e. apt's dpkg),
they allow specifying beforehand or even answering interactively on the
action to take (merge/new/old) for the configuration files of a package
being upgraded. Also, the general default for config files is "merge" and
not "keep old".
There is different ways of seeing this. First dpkg is not really an
accurate comparison IMO, I think you missed the fact that
"configuration" here is for configuration data only usually, the
assumptions is that the class and administration UI for example would
be in a different documents so you do get new properties during
upgrade. But the behavior supposedly stay the same after upgrade, i.e.
it's not modified by a change in the provided default configuration
(the idea being to allow the extension author to change default
configuration for new install without disturbing old ones). This is
exactly what happen with application that are using generated
configuration page right now, one of the ideas behind this type is
that you can use it instead of a (sometimes complex) configuration
generation logic.
But yes there is not only one kind of configuration and the point of
me listing the quick types I introduced in 10.3 is also to ask for new
ones to have a good coverage of various common use cases even if
extension can also come with their own type too.
- home: a wiki home page. Edit is allowed and the document is upgraded
only if it's not been customized.
- demo: a document which purpose is to provide demo data. Edit and
delete are allowed and the document is upgraded only if it's not been
customized.
I don't really understand the distinction between "home" and
"demo".
AFAICS
from the definition, "home" is not
supposed to be deleted, but why would
we
want to enforce such a restriction? If we are
talking about wiki
homepages,
we can already configure that in the wiki
descriptor as "Main.WebHome" is
not really a fixed entrypoint/API.
Yes in theory the wiki home page is configurable but I really doubt
this actually happen much and it's not very nice to delete the wiki
home page for various reasons. Now it was a quickly introduce type
because I had this use case in mind but we could decide to make it a
demo and rely on another system to check if the page is the configured
home page before warning about it.
For application homepages, I fail to see
the need to edit them, so I believe they should use "demo" instead of
"home".
Did you mean default ? "demo" does not make sense for application
home
page since you don't want to edit them as you said. Most application
home pages will use default type for me.
And yes those are not the target of "home" type. I did not really had
any other use case in mind than Main.WebHome when I introduced it but
assume other pages could be in a similar situation :)
Nothing else to add. For me, the 3 types - default (code), configuration
and demo - should be enough for a good start.
Thanks,
Eduard
IMO, "Main.WebHome" should be set to "demo" since that is what it
really
is. We expect the admin to edit it with his needs.
I still prefer to protect the wiki home page against delete by default
but not strongly enough to not be OK with your proposal if other think
it's better like this.
AFAIU, "demo" makes sense and "configuration" is mostly something
that
the
admin might choose, with a default of
"merge".
Thanks,
Eduard
Any other type you can think of that would worth being introduced in
XWiki Standard ? IMO it can even be a type that have the same behavior
than another right now, the idea being that with the current
architecture a component can overwrite a specific type, introduce a
custom upgrade component for a specific type or that we could decide
to change the way we deal with some type of document in the future for
some reason (having the documents already using the right type in
extensions would help a lot when that time comes :)).
On Wed, Apr 25, 2018 at 7:49 PM, Thomas Mortagne <
thomas.mortagne(a)xwiki.com>
wrote:
> By the way this is not only about XWiki Standard. We also need to
> think about entry type in contrib extensions you know.
>
> On Mon, Apr 23, 2018 at 1:40 PM, Thomas Mortagne
> <thomas.mortagne(a)xwiki.com> wrote:
> > As I indicated it would be better if you could send other mail to
> > discuss those pages separately (there is already one for the the
> > themes) :)
> >
> > On Mon, Apr 23, 2018 at 12:39 PM, Ecaterina Moraru (Valica)
> > <valicac(a)gmail.com> wrote:
> >> Dashboard.WebHome should be editable.
> >> FlamingoThemes.* should be editable in order for users to set custom
> logos.
> >> XWiki.DefaultSkin should be editable for the same logo reason.
> >>
> >> Thanks,
> >> Caty
> >>
> >> On Mon, Apr 23, 2018 at 1:27 PM, Thomas Mortagne <
> thomas.mortagne(a)xwiki.com>
> >> wrote:
> >>
> >>> Hi devs,
> >>>
> >>> When dealing with extension pages protection we ended up with a very
> >>> visible issue: EVERYONE customize the home page so it does not make
> >>> much sense to warn every user trying to edit it that it's dangerous
> >>> and might break the extensions.
> >>>
> >>> Since it's not the only use case 10.3 introduce the concept of XAR
> >>> entry type which allow controlling a bit more edit/delete and
upgrade
> >>> behavior. See
http://extensions.xwiki.org/
> xwiki/bin/view/Extension/XAR+
> >>> Module+Specifications#Hpackage.xml
> >>> for more details.
> >>>
> >>> On component side it's possible to decide the default type of a
page
> >>> reference (that's where "Main.WebHome" type come from
currently).
It's
> >>> also possible to override the
upgrade behavior for a specific type
or
> >>> even a specific reference for
more exotic use cases.
> >>>
> >>> So it's now possible to control the type you want for a page at XAR
> >>> descriptor level. I already typed a few page, for example
> >>> "Main.WebHome" is now of type "home" which means
"it's OK to edit it
> >>> and you should only upgrade it if no customization have been
made".
> >>>
> >>> Cool home page is covered but we now entered a new era of endless
> >>> debates to decide of what type some page should be and what other
> >>> types to introduce :)
> >>>
> >>> We are not going to discuss all these in this mail so everyone with
a
> >>> doubt should start a discussion
for a standard page (or a set of
> >>> standard page which are obviously very similar like color themes).
> >>>
> >>> Currently, protected page produce a warning that you can force. The
> >>> plan in 10.4 is to keep the warning only for advanced completely
> >>> prevent basic user to modify protected pages by default and also
allow
> >>> configuring all that (indicate
in your profile that you don't want
to
> >>> be bothered with that, override
edit/delete right even for advanced
> >>> users, etc.). But before that we need to make sure basic users are
> >>> allowed to edit all the pages they are supposed to edit.
> >>>
> >>> Happy tuning :)
> >>>
> >>> --
> >>> Thomas Mortagne
> >>>
> >
> >
> >
> > --
> > Thomas Mortagne
>
>
>
> --
> Thomas Mortagne
>
--
Thomas Mortagne
5 p.m.
On Thu, Apr 26, 2018 at 4:34 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
--
Thomas Mortagne
On Thu, Apr 26, 2018 at 3:35 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>
wrote:
Commenting is not an edit related action from the UI point of view and
does not require edit right so you don't get any kind of protection
(except if you disable comments in your page of course).
Also it's more comment than you think to get comments on some
application home page and others not-supposed-to-be-edited entry point
pages :)
On Thu, Apr 26, 2018 at 1:45 PM, Eduard Moraru
<enygma2002(a)gmail.com>
wrote:
I do get where you are coming from. However, if you consider that "default"
restricts editing, you should normally not end up with unwanted stuff like
comments on a code page. Hi, Thomas,
I'm having some difficulties understanding the available types and their
intent.
- default: used to force the default. Edit and delete are not allowed
and a 3-way merge is applied to the document during upgrades.
Shouldn't the default upgrade action be "keep new", specially if edit and
delete is restricted on the page? The assumption would be that it's a
code
page and any unsaved modifications (e.g. as a
fork extension) should be
overridden by the new version of the extension's code.
On upgrade side I much prefer to have the default being what always
been the default and introduce new behavior in new types. Also think
this is what we want for the majority of pages, there is stuff that
you could add to a page without really thinking about it as a
customization, that you will want to keep and which are not dangerous
for merge (like comments, restrict access to some application, etc.).
Regarding rights, that's a more realistic problem we have in the current
model. Until we come up with a solution that does not store rights as
objects inside the page, we don't have much choice.
However, this opens up another question: How does this (setting rights on a
code page that has "default" type) work with the lack of edit rights on the
page (i.e. you would not be able to set the rights in the first place,
because the page can't be edited)?
Keep in mind that for spaces the right setup is associated to admin
right/action and I don't plan to affect that right now.
Or maybe when you say "not allowed to
edit/delete", you simply refer to the small "warning" curtain in the UI
that only discourages the user to do the operation, but he can force it
anyway?
I'm referring to what the type indicates.
On actual behavior side the current plan (target 10.4) is to have the following:
* basic user: edit/delete rights are directly affected by the type setting
* advanced user: warning
Plus some configuration to change that (right level behavior for
everyone, warning for everyone, etc.) except for superadmin which can
always force it (with a warning by default).
Simply to keep merging as safe as possible you
get a string warning
when going trough standard editing of those pages where you could have
an impact on what constitute the hearth of what this page is supposed
to do.
Right.
- configuration: a document containing configuration. Edit is allowed
and the document is never upraded.
Normally, configuration is among the only things you might actually want
to
make a choice on, as someone running an upgrade.
It does not make much
sense to never upgrade a configuration document, specifically when you
have
just added a new feature. Thinking of package
managers (i.e. apt's dpkg),
they allow specifying beforehand or even answering interactively on the
action to take (merge/new/old) for the configuration files of a package
being upgraded. Also, the general default for config files is "merge" and
not "keep old".
There is different ways of seeing this. First dpkg is not really an
accurate comparison IMO, I think you missed the fact that
"configuration" here is for configuration data only usually, the
assumptions is that the class and administration UI for example would
be in a different documents so you do get new properties during
upgrade. But the behavior supposedly stay the same after upgrade, i.e.
it's not modified by a change in the provided default configuration
(the idea being to allow the extension author to change default
configuration for new install without disturbing old ones). This is
exactly what happen with application that are using generated
configuration page right now, one of the ideas behind this type is
that you can use it instead of a (sometimes complex) configuration
generation logic.
But yes there is not only one kind of configuration and the point of
me listing the quick types I introduced in 10.3 is also to ask for new
ones to have a good coverage of various common use cases even if
extension can also come with their own type too.
- home: a wiki home page. Edit is allowed and the document is upgraded
only if it's not been customized.
- demo: a document which purpose is to provide demo data. Edit and
delete are allowed and the document is upgraded only if it's not been
customized.
I don't really understand the distinction between "home" and
"demo".
AFAICS
from the definition, "home" is not
supposed to be deleted, but why would
we
want to enforce such a restriction? If we are
talking about wiki
homepages,
we can already configure that in the wiki
descriptor as "Main.WebHome" is
not really a fixed entrypoint/API.
Yes in theory the wiki home page is configurable but I really doubt
this actually happen much and it's not very nice to delete the wiki
home page for various reasons. Now it was a quickly introduce type
because I had this use case in mind but we could decide to make it a
demo and rely on another system to check if the page is the configured
home page before warning about it.
For application homepages, I fail to see
the need to edit them, so I believe they should use "demo" instead of
"home".
Did you mean default ? "demo" does not make sense for
application home
page since you don't want to edit them as you said. Most application
home pages will use default type for me.
And yes those are not the target of "home" type. I did not really had
any other use case in mind than Main.WebHome when I introduced it but
assume other pages could be in a similar situation :)
Nothing else to add. For me, the 3 types - default (code), configuration
and demo - should be enough for a good start.
Thanks,
Eduard
>
> >
> >
> > On Wed, Apr 25, 2018 at 7:49 PM, Thomas Mortagne <
> thomas.mortagne(a)xwiki.com>
> > wrote:
> >
> >> By the way this is not only about XWiki Standard. We also need to
> >> think about entry type in contrib extensions you know.
> >>
> >> On Mon, Apr 23, 2018 at 1:40 PM, Thomas Mortagne
> >> <thomas.mortagne(a)xwiki.com> wrote:
> >> > As I indicated it would be better if you could send other mail to
> >> > discuss those pages separately (there is already one for the the
> >> > themes) :)
> >> >
> >> > On Mon, Apr 23, 2018 at 12:39 PM, Ecaterina Moraru (Valica)
> >> > <valicac(a)gmail.com> wrote:
> >> >> Dashboard.WebHome should be editable.
> >> >> FlamingoThemes.* should be editable in order for users to set
custom
> >> logos.
> >> >> XWiki.DefaultSkin should be editable for the same logo reason.
> >> >>
> >> >> Thanks,
> >> >> Caty
> >> >>
> >> >> On Mon, Apr 23, 2018 at 1:27 PM, Thomas Mortagne <
> >> thomas.mortagne(a)xwiki.com>
> >> >> wrote:
> >> >>
> >> >>> Hi devs,
> >> >>>
> >> >>> When dealing with extension pages protection we ended up with a
very
> >> >>> visible issue: EVERYONE customize the home page so it does not
make
> >> >>> much sense to warn every user trying to edit it that it's
dangerous
> >> >>> and might break the extensions.
> >> >>>
> >> >>> Since it's not the only use case 10.3 introduce the concept
of XAR
> >> >>> entry type which allow controlling a bit more edit/delete and
> upgrade
> >> >>> behavior. See http://extensions.xwiki.org/
> >> xwiki/bin/view/Extension/XAR+
> >> >>> Module+Specifications#Hpackage.xml
> >> >>> for more details.
> >> >>>
> >> >>> On component side it's possible to decide the default type
of a page
> >> >>> reference (that's where "Main.WebHome" type come
from currently).
> It's
> >> >>> also possible to override the upgrade behavior for a specific
type
> or
> >> >>> even a specific reference for more exotic use cases.
> >> >>>
> >> >>> So it's now possible to control the type you want for a
page at XAR
> >> >>> descriptor level. I already typed a few page, for example
> >> >>> "Main.WebHome" is now of type "home" which
means "it's OK to edit it
> >> >>> and you should only upgrade it if no customization have been
made".
> >> >>>
> >> >>> Cool home page is covered but we now entered a new era of
endless
> >> >>> debates to decide of what type some page should be and what
other
> >> >>> types to introduce :)
> >> >>>
> >> >>> We are not going to discuss all these in this mail so everyone
with
> a
> >> >>> doubt should start a discussion for a standard page (or a set
of
> >> >>> standard page which are obviously very similar like color
themes).
> >> >>>
> >> >>> Currently, protected page produce a warning that you can force.
The
> >> >>> plan in 10.4 is to keep the warning only for advanced
completely
> >> >>> prevent basic user to modify protected pages by default and
also
> allow
> >> >>> configuring all that (indicate in your profile that you
don't want
> to
> >> >>> be bothered with that, override edit/delete right even for
advanced
> >> >>> users, etc.). But before that we need to make sure basic users
are
> >> >>> allowed to edit all the pages they are supposed to edit.
> >> >>>
> >> >>> Happy tuning :)
> >> >>>
> >> >>> --
> >> >>> Thomas Mortagne
> >> >>>
> >> >
> >> >
> >> >
> >> > --
> >> > Thomas Mortagne
> >>
> >>
> >>
> >> --
> >> Thomas Mortagne
> >>
>
>
>
> --
> Thomas Mortagne
>
IMO, "Main.WebHome" should be set to "demo" since that is what it
really
is. We expect the admin to edit it with his needs.
I still prefer to protect the wiki home page against delete by default
but not strongly enough to not be OK with your proposal if other think
it's better like this.
AFAIU, "demo" makes sense and "configuration" is mostly something
that
the
admin might choose, with a default of
"merge".
Thanks,
Eduard
Any other type you can think of that would worth being introduced in
XWiki Standard ? IMO it can even be a type that have the same behavior
than another right now, the idea being that with the current
architecture a component can overwrite a specific type, introduce a
custom upgrade component for a specific type or that we could decide
to change the way we deal with some type of document in the future for
some reason (having the documents already using the right type in
extensions would help a lot when that time comes :)).
5:01 p.m.
On Thu, Apr 26, 2018 at 5:00 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
On Thu, Apr 26, 2018 at 4:34 PM, Eduard Moraru
<enygma2002(a)gmail.com> wrote:
Yes I meant "it's more common", too close :)
On Thu, Apr 26, 2018 at 3:35 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>
wrote:
Commenting is not an edit related action from the UI point of view and
does not require edit right so you don't get any kind of protection
(except if you disable comments in your page of course).
Also it's more comment than you think to get comments on some On Thu, Apr 26, 2018 at 1:45 PM, Eduard Moraru
<enygma2002(a)gmail.com>
wrote:
I do get where you are coming from. However, if you consider that "default"
restricts editing, you should normally not end up with unwanted stuff like
comments on a code page. Hi, Thomas,
I'm having some difficulties understanding the available types and their
intent.
- default: used to force the default. Edit and delete are not allowed
and a 3-way merge is applied to the document during upgrades.
Shouldn't the default upgrade action be "keep new", specially if edit and
delete is restricted on the page? The assumption would be that it's a
code
page and any unsaved modifications (e.g. as a
fork extension) should be
overridden by the new version of the extension's code.
On upgrade side I much prefer to have the default being what always
been the default and introduce new behavior in new types. Also think
this is what we want for the majority of pages, there is stuff that
you could add to a page without really thinking about it as a
customization, that you will want to keep and which are not dangerous
for merge (like comments, restrict access to some application, etc.).
application home page and others
not-supposed-to-be-edited entry point
pages :)
--
Thomas Mortagne
--
Thomas Mortagne
Regarding rights, that's a more realistic problem we have in the current
model. Until we come up with a solution that does not store rights as
objects inside the page, we don't have much choice.
However, this opens up another question: How does this (setting rights on a
code page that has "default" type) work with the lack of edit rights on the
page (i.e. you would not be able to set the rights in the first place,
because the page can't be edited)?
Keep in mind that for spaces the right setup is associated to admin
right/action and I don't plan to affect that right now.
Or maybe when you say "not allowed to
edit/delete", you simply refer to the small "warning" curtain in the UI
that only discourages the user to do the operation, but he can force it
anyway?
I'm referring to what the type indicates.
On actual behavior side the current plan (target 10.4) is to have the following:
* basic user: edit/delete rights are directly affected by the type setting
* advanced user: warning
Plus some configuration to change that (right level behavior for
everyone, warning for everyone, etc.) except for superadmin which can
always force it (with a warning by default).
Simply to keep merging as safe as possible you
get a string warning
when going trough standard editing of those pages where you could have
an impact on what constitute the hearth of what this page is supposed
to do.
Right.
- configuration: a document containing configuration. Edit is allowed
and the document is never upraded.
Normally, configuration is among the only things you might actually want
to
make a choice on, as someone running an upgrade.
It does not make much
sense to never upgrade a configuration document, specifically when you
have
just added a new feature. Thinking of package
managers (i.e. apt's dpkg),
they allow specifying beforehand or even answering interactively on the
action to take (merge/new/old) for the configuration files of a package
being upgraded. Also, the general default for config files is "merge" and
not "keep old".
There is different ways of seeing this. First dpkg is not really an
accurate comparison IMO, I think you missed the fact that
"configuration" here is for configuration data only usually, the
assumptions is that the class and administration UI for example would
be in a different documents so you do get new properties during
upgrade. But the behavior supposedly stay the same after upgrade, i.e.
it's not modified by a change in the provided default configuration
(the idea being to allow the extension author to change default
configuration for new install without disturbing old ones). This is
exactly what happen with application that are using generated
configuration page right now, one of the ideas behind this type is
that you can use it instead of a (sometimes complex) configuration
generation logic.
But yes there is not only one kind of configuration and the point of
me listing the quick types I introduced in 10.3 is also to ask for new
ones to have a good coverage of various common use cases even if
extension can also come with their own type too.
- home: a wiki home page. Edit is allowed and the document is upgraded
only if it's not been customized.
- demo: a document which purpose is to provide demo data. Edit and
delete are allowed and the document is upgraded only if it's not been
customized.
I don't really understand the distinction between "home" and
"demo".
AFAICS
from the definition, "home" is not
supposed to be deleted, but why would
we
want to enforce such a restriction? If we are
talking about wiki
homepages,
we can already configure that in the wiki
descriptor as "Main.WebHome" is
not really a fixed entrypoint/API.
Yes in theory the wiki home page is configurable but I really doubt
this actually happen much and it's not very nice to delete the wiki
home page for various reasons. Now it was a quickly introduce type
because I had this use case in mind but we could decide to make it a
demo and rely on another system to check if the page is the configured
home page before warning about it.
For application homepages, I fail to see
the need to edit them, so I believe they should use "demo" instead of
"home".
Did you mean default ? "demo" does not make sense for
application home
page since you don't want to edit them as you said. Most application
home pages will use default type for me.
And yes those are not the target of "home" type. I did not really had
any other use case in mind than Main.WebHome when I introduced it but
assume other pages could be in a similar situation :)
Nothing else to add. For me, the 3 types - default (code), configuration
and demo - should be enough for a good start.
Thanks,
Eduard
>
> >
> >
> > On Wed, Apr 25, 2018 at 7:49 PM, Thomas Mortagne <
> thomas.mortagne(a)xwiki.com>
> > wrote:
> >
> >> By the way this is not only about XWiki Standard. We also need to
> >> think about entry type in contrib extensions you know.
> >>
> >> On Mon, Apr 23, 2018 at 1:40 PM, Thomas Mortagne
> >> <thomas.mortagne(a)xwiki.com> wrote:
> >> > As I indicated it would be better if you could send other mail to
> >> > discuss those pages separately (there is already one for the the
> >> > themes) :)
> >> >
> >> > On Mon, Apr 23, 2018 at 12:39 PM, Ecaterina Moraru (Valica)
> >> > <valicac(a)gmail.com> wrote:
> >> >> Dashboard.WebHome should be editable.
> >> >> FlamingoThemes.* should be editable in order for users to set
custom
> >> logos.
> >> >> XWiki.DefaultSkin should be editable for the same logo reason.
> >> >>
> >> >> Thanks,
> >> >> Caty
> >> >>
> >> >> On Mon, Apr 23, 2018 at 1:27 PM, Thomas Mortagne <
> >> thomas.mortagne(a)xwiki.com>
> >> >> wrote:
> >> >>
> >> >>> Hi devs,
> >> >>>
> >> >>> When dealing with extension pages protection we ended up with a
very
> >> >>> visible issue: EVERYONE customize the home page so it does not
make
> >> >>> much sense to warn every user trying to edit it that it's
dangerous
> >> >>> and might break the extensions.
> >> >>>
> >> >>> Since it's not the only use case 10.3 introduce the concept
of XAR
> >> >>> entry type which allow controlling a bit more edit/delete and
> upgrade
> >> >>> behavior. See http://extensions.xwiki.org/
> >> xwiki/bin/view/Extension/XAR+
> >> >>> Module+Specifications#Hpackage.xml
> >> >>> for more details.
> >> >>>
> >> >>> On component side it's possible to decide the default type
of a page
> >> >>> reference (that's where "Main.WebHome" type come
from currently).
> It's
> >> >>> also possible to override the upgrade behavior for a specific
type
> or
> >> >>> even a specific reference for more exotic use cases.
> >> >>>
> >> >>> So it's now possible to control the type you want for a
page at XAR
> >> >>> descriptor level. I already typed a few page, for example
> >> >>> "Main.WebHome" is now of type "home" which
means "it's OK to edit it
> >> >>> and you should only upgrade it if no customization have been
made".
> >> >>>
> >> >>> Cool home page is covered but we now entered a new era of
endless
> >> >>> debates to decide of what type some page should be and what
other
> >> >>> types to introduce :)
> >> >>>
> >> >>> We are not going to discuss all these in this mail so everyone
with
> a
> >> >>> doubt should start a discussion for a standard page (or a set
of
> >> >>> standard page which are obviously very similar like color
themes).
> >> >>>
> >> >>> Currently, protected page produce a warning that you can force.
The
> >> >>> plan in 10.4 is to keep the warning only for advanced
completely
> >> >>> prevent basic user to modify protected pages by default and
also
> allow
> >> >>> configuring all that (indicate in your profile that you
don't want
> to
> >> >>> be bothered with that, override edit/delete right even for
advanced
> >> >>> users, etc.). But before that we need to make sure basic users
are
> >> >>> allowed to edit all the pages they are supposed to edit.
> >> >>>
> >> >>> Happy tuning :)
> >> >>>
> >> >>> --
> >> >>> Thomas Mortagne
> >> >>>
> >> >
> >> >
> >> >
> >> > --
> >> > Thomas Mortagne
> >>
> >>
> >>
> >> --
> >> Thomas Mortagne
> >>
>
>
>
> --
> Thomas Mortagne
>
IMO, "Main.WebHome" should be set to "demo" since that is what it
really
is. We expect the admin to edit it with his needs.
I still prefer to protect the wiki home page against delete by default
but not strongly enough to not be OK with your proposal if other think
it's better like this.
AFAIU, "demo" makes sense and "configuration" is mostly something
that
the
admin might choose, with a default of
"merge".
Thanks,
Eduard
Any other type you can think of that would worth being introduced in
XWiki Standard ? IMO it can even be a type that have the same behavior
than another right now, the idea being that with the current
architecture a component can overwrite a specific type, introduce a
custom upgrade component for a specific type or that we could decide
to change the way we deal with some type of document in the future for
some reason (having the documents already using the right type in
extensions would help a lot when that time comes :)).
30 Apr
30 Apr
10 a.m.
Hi Thomas,
On 23 Apr 2018, at 12:27, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Hi devs,
When dealing with extension pages protection we ended up with a very
visible issue: EVERYONE customize the home page so it does not make
much sense to warn every user trying to edit it that it's dangerous
and might break the extensions.
Since it's not the only use case 10.3 introduce the concept of XAR
entry type which allow controlling a bit more edit/delete and upgrade
behavior. See
http://extensions.xwiki.org/xwiki/bin/view/Extension/XAR+Module+Specificati…
for more details.
On component side it's possible to decide the default type of a page
reference (that's where "Main.WebHome" type come from currently). It's
also possible to override the upgrade behavior for a specific type or
even a specific reference for more exotic use cases.
So it's now possible to control the type you want for a page at XAR
descriptor level. I already typed a few page, for example
"Main.WebHome" is now of type "home" which means "it's OK to
edit it
and you should only upgrade it if no customization have been made".
Cool home page is covered but we now entered a new era of endless
debates to decide of what type some page should be and what other
types to introduce :)
Could you list all pages for which you’ve put “demo”, “home” and “configuration"
types so far?
Also in the doc you say " • default: used to force the default. Edit and delete are
not allowed and a 3-way merge is applied to the document during upgrades.”
AFAIU this is the default when no type is specified, right? Did you mean to say “Edit and
delete are allowed”?
Thanks
-Vincent
We are not going to discuss all these in this mail so everyone with a
doubt should start a discussion for a standard page (or a set of
standard page which are obviously very similar like color themes).
Currently, protected page produce a warning that you can force. The
plan in 10.4 is to keep the warning only for advanced completely
prevent basic user to modify protected pages by default and also allow
configuring all that (indicate in your profile that you don't want to
be bothered with that, override edit/delete right even for advanced
users, etc.). But before that we need to make sure basic users are
allowed to edit all the pages they are supposed to edit.
Happy tuning :)
--
Thomas Mortagne
11:14 a.m.
On Mon, Apr 30, 2018 at 10:00 AM, Vincent Massol <vincent(a)massol.net> wrote:
Hi Thomas,
The current status is (hope I don't forget anything):
* demo
(https://github.com/xwiki/xwiki-platform/search?utf8=%E2%9C%93&q=%22%3Ct…)
** Sandbox visible sub pages
** Color themes
** XWiki.DefaultSkin
** soon Main.WebHome it seems :)
** [jetty+hsqldb+flavor] Admin user
* configuration
(https://github.com/xwiki/xwiki-platform/search?utf8=%E2%9C%93&q=%22%3Ct…)
** XWiki.XWikiPreferences (default type provided by a component)
** [jetty+hsqldb+flavor] XWikiAdminGroup and XWikiAllGroup
* home
(https://github.com/xwiki/xwiki-platform/search?utf8=%E2%9C%93&q=%22%3Ct…)
** Sandbox.WebHome since it's the hardcoded entry point of the sandbox
application so not too nice to delete it
* to discuss AFAIK:
** Dashboard.WebHome home page, either "demo" or something a bit more
restrictive like "home" since it's the entry point of dashboard
application so not very nice to delete it
** and of course Contrib extensions will need to take care of that too
On 23 Apr 2018, at 12:27, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Hi devs,
When dealing with extension pages protection we ended up with a very
visible issue: EVERYONE customize the home page so it does not make
much sense to warn every user trying to edit it that it's dangerous
and might break the extensions.
Since it's not the only use case 10.3 introduce the concept of XAR
entry type which allow controlling a bit more edit/delete and upgrade
behavior. See
http://extensions.xwiki.org/xwiki/bin/view/Extension/XAR+Module+Specificati…
for more details.
On component side it's possible to decide the default type of a page
reference (that's where "Main.WebHome" type come from currently). It's
also possible to override the upgrade behavior for a specific type or
even a specific reference for more exotic use cases.
So it's now possible to control the type you want for a page at XAR
descriptor level. I already typed a few page, for example
"Main.WebHome" is now of type "home" which means "it's OK to
edit it
and you should only upgrade it if no customization have been made".
Cool home page is covered but we now entered a new era of endless
debates to decide of what type some page should be and what other
types to introduce :)
Could you list all pages for which you’ve put “demo”, “home” and “configuration"
types so far?
Also in the doc you say " • default: used to force the default. Edit and
delete are not allowed and a 3-way merge is applied to the document during upgrades.”
AFAIU this is the default when no type is specified, right? Did you mean to say “Edit and
delete are allowed”?
It's not about making that page behave as a non-extension page, it's
only here to force the default extension page behavior.
It's possible trough components to indicate a type for a given local
reference when no explicit type a been set. So this value allow to
bypass this when you want to make extra sure your page will have the
default behavior (for example some flavor in which you are not
supposed to touch the Main.WebHome since Main.WebHome is current
getting its type as "the default type for Main.WebHome reference in
general").
Thanks
-Vincent
--
Thomas Mortagne
We are not going to discuss all these in this mail so everyone with a
doubt should start a discussion for a standard page (or a set of
standard page which are obviously very similar like color themes).
Currently, protected page produce a warning that you can force. The
plan in 10.4 is to keep the warning only for advanced completely
prevent basic user to modify protected pages by default and also allow
configuring all that (indicate in your profile that you don't want to
be bothered with that, override edit/delete right even for advanced
users, etc.). But before that we need to make sure basic users are
allowed to edit all the pages they are supposed to edit.
Happy tuning :)
--
Thomas Mortagne
7 May
7 May
4:29 p.m.
Since I hit more and more the need to allow to customize an entry
point without deleting it (or it will break a hardcoded menu/link) I
just introduce the following type:
* "customizable": same thing as "home" and for the same reasons but
more generic. I guess we could simply get rid of "home" type since the
main use case seems to tend to "demo" (see dedicated mails thread)
I tough about "editable" but I find it too wide.
On Mon, Apr 30, 2018 at 11:14 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
On Mon, Apr 30, 2018 at 10:00 AM, Vincent Massol
<vincent(a)massol.net> wrote:
--
Thomas Mortagne
Hi Thomas,
The current status is (hope I don't forget anything):
* demo
(https://github.com/xwiki/xwiki-platform/search?utf8=%E2%9C%93&q=%22%3Ct…)
** Sandbox visible sub pages
** Color themes
** XWiki.DefaultSkin
** soon Main.WebHome it seems :)
** [jetty+hsqldb+flavor] Admin user
* configuration
(https://github.com/xwiki/xwiki-platform/search?utf8=%E2%9C%93&q=%22%3Ct…)
** XWiki.XWikiPreferences (default type provided by a component)
** [jetty+hsqldb+flavor] XWikiAdminGroup and XWikiAllGroup
* home
(https://github.com/xwiki/xwiki-platform/search?utf8=%E2%9C%93&q=%22%3Ct…)
** Sandbox.WebHome since it's the hardcoded entry point of the sandbox
application so not too nice to delete it
* to discuss AFAIK:
** Dashboard.WebHome home page, either "demo" or something a bit more
restrictive like "home" since it's the entry point of dashboard
application so not very nice to delete it
** and of course Contrib extensions will need to take care of that too
On 23 Apr 2018, at 12:27, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Hi devs,
When dealing with extension pages protection we ended up with a very
visible issue: EVERYONE customize the home page so it does not make
much sense to warn every user trying to edit it that it's dangerous
and might break the extensions.
Since it's not the only use case 10.3 introduce the concept of XAR
entry type which allow controlling a bit more edit/delete and upgrade
behavior. See
http://extensions.xwiki.org/xwiki/bin/view/Extension/XAR+Module+Specificati…
for more details.
On component side it's possible to decide the default type of a page
reference (that's where "Main.WebHome" type come from currently). It's
also possible to override the upgrade behavior for a specific type or
even a specific reference for more exotic use cases.
So it's now possible to control the type you want for a page at XAR
descriptor level. I already typed a few page, for example
"Main.WebHome" is now of type "home" which means "it's OK to
edit it
and you should only upgrade it if no customization have been made".
Cool home page is covered but we now entered a new era of endless
debates to decide of what type some page should be and what other
types to introduce :)
Could you list all pages for which you’ve put “demo”, “home” and “configuration"
types so far?
Also in the doc you say " • default: used to force the default. Edit and
delete are not allowed and a 3-way merge is applied to the document during upgrades.”
AFAIU this is the default when no type is specified, right? Did you mean to say “Edit and
delete are allowed”?
It's not about making that page behave as a non-extension page, it's
only here to force the default extension page behavior.
It's possible trough components to indicate a type for a given local
reference when no explicit type a been set. So this value allow to
bypass this when you want to make extra sure your page will have the
default behavior (for example some flavor in which you are not
supposed to touch the Main.WebHome since Main.WebHome is current
getting its type as "the default type for Main.WebHome reference in
general").
Thanks
-Vincent
--
Thomas Mortagne
We are not going to discuss all these in this mail so everyone with a
doubt should start a discussion for a standard page (or a set of
standard page which are obviously very similar like color themes).
Currently, protected page produce a warning that you can force. The
plan in 10.4 is to keep the warning only for advanced completely
prevent basic user to modify protected pages by default and also allow
configuring all that (indicate in your profile that you don't want to
be bothered with that, override edit/delete right even for advanced
users, etc.). But before that we need to make sure basic users are
allowed to edit all the pages they are supposed to edit.
Happy tuning :)
--
Thomas Mortagne
5:54 p.m.
Just started a wiki page to list pages with specific type (decided or
still discussed)
http://design.xwiki.org/xwiki/bin/view/Proposal/XARentriestypes
On Mon, May 7, 2018 at 4:29 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Since I hit more and more the need to allow to
customize an entry
point without deleting it (or it will break a hardcoded menu/link) I
just introduce the following type:
* "customizable": same thing as "home" and for the same reasons but
more generic. I guess we could simply get rid of "home" type since the
main use case seems to tend to "demo" (see dedicated mails thread)
I tough about "editable" but I find it too wide.
On Mon, Apr 30, 2018 at 11:14 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
--
Thomas Mortagne
On Mon, Apr 30, 2018 at 10:00 AM, Vincent Massol
<vincent(a)massol.net> wrote:
--
Thomas Mortagne Hi Thomas,
The current status is (hope I don't forget anything):
* demo
(https://github.com/xwiki/xwiki-platform/search?utf8=%E2%9C%93&q=%22%3Ct…)
** Sandbox visible sub pages
** Color themes
** XWiki.DefaultSkin
** soon Main.WebHome it seems :)
** [jetty+hsqldb+flavor] Admin user
* configuration
(https://github.com/xwiki/xwiki-platform/search?utf8=%E2%9C%93&q=%22%3Ct…)
** XWiki.XWikiPreferences (default type provided by a component)
** [jetty+hsqldb+flavor] XWikiAdminGroup and XWikiAllGroup
* home
(https://github.com/xwiki/xwiki-platform/search?utf8=%E2%9C%93&q=%22%3Ct…)
** Sandbox.WebHome since it's the hardcoded entry point of the sandbox
application so not too nice to delete it
* to discuss AFAIK:
** Dashboard.WebHome home page, either "demo" or something a bit more
restrictive like "home" since it's the entry point of dashboard
application so not very nice to delete it
** and of course Contrib extensions will need to take care of that too
On 23 Apr 2018, at 12:27, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Hi devs,
When dealing with extension pages protection we ended up with a very
visible issue: EVERYONE customize the home page so it does not make
much sense to warn every user trying to edit it that it's dangerous
and might break the extensions.
Since it's not the only use case 10.3 introduce the concept of XAR
entry type which allow controlling a bit more edit/delete and upgrade
behavior. See
http://extensions.xwiki.org/xwiki/bin/view/Extension/XAR+Module+Specificati…
for more details.
On component side it's possible to decide the default type of a page
reference (that's where "Main.WebHome" type come from currently). It's
also possible to override the upgrade behavior for a specific type or
even a specific reference for more exotic use cases.
So it's now possible to control the type you want for a page at XAR
descriptor level. I already typed a few page, for example
"Main.WebHome" is now of type "home" which means "it's OK to
edit it
and you should only upgrade it if no customization have been made".
Cool home page is covered but we now entered a new era of endless
debates to decide of what type some page should be and what other
types to introduce :)
Could you list all pages for which you’ve put “demo”, “home” and “configuration"
types so far?
Also in the doc you say " • default: used to force the default. Edit and
delete are not allowed and a 3-way merge is applied to the document during upgrades.”
AFAIU this is the default when no type is specified, right? Did you mean to say “Edit and
delete are allowed”?
It's not about making that page behave as a non-extension page, it's
only here to force the default extension page behavior.
It's possible trough components to indicate a type for a given local
reference when no explicit type a been set. So this value allow to
bypass this when you want to make extra sure your page will have the
default behavior (for example some flavor in which you are not
supposed to touch the Main.WebHome since Main.WebHome is current
getting its type as "the default type for Main.WebHome reference in
general").
Thanks
-Vincent
--
Thomas Mortagne
We are not going to discuss all these in this mail so everyone with a
doubt should start a discussion for a standard page (or a set of
standard page which are obviously very similar like color themes).
Currently, protected page produce a warning that you can force. The
plan in 10.4 is to keep the warning only for advanced completely
prevent basic user to modify protected pages by default and also allow
configuring all that (indicate in your profile that you don't want to
be bothered with that, override edit/delete right even for advanced
users, etc.). But before that we need to make sure basic users are
allowed to edit all the pages they are supposed to edit.
Happy tuning :)
--
Thomas Mortagne
2316
days inactive
2330
days old
12 comments
4 participants
participants (4)
-
Ecaterina Moraru (Valica) -
Eduard Moraru -
Thomas Mortagne -
Vincent Massol