On Thu, Apr 26, 2018 at 5:00 PM, Thomas Mortagne <thomas.morta...@xwiki.com> wrote: > On Thu, Apr 26, 2018 at 4:34 PM, Eduard Moraru <enygma2...@gmail.com> wrote: >> On Thu, Apr 26, 2018 at 3:35 PM, Thomas Mortagne <thomas.morta...@xwiki.com> >> wrote: >> >>> On Thu, Apr 26, 2018 at 1:45 PM, Eduard Moraru <enygma2...@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.). >>> >> >> 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. > > 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
Yes I meant "it's more common", too close :) > application home page and others not-supposed-to-be-edited entry point > pages :) > >> >> 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. >>> >>> > >>> > - 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 ? >> >> >> Right. >> >> >>> "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 :)). >>> >> >> 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.morta...@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.morta...@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) >>> >> > <vali...@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.morta...@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 >>> > > > > -- > Thomas Mortagne -- Thomas Mortagne
