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