7 May
2018
7 May
'18
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