26 Apr
2018
26 Apr
'18
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