Re: [xwiki-devs] [Proposal] So which protection to we want by default for extensions pages
Hello On Thu, May 3, 2018 at 3:30 PM, Thomas Mortagne wrote: > On Thu, May 3, 2018 at 3:09 PM, Ecaterina Moraru (Valica) > wrote: > > On Thu, May 3, 2018 at 2:56 PM, Thomas Mortagne < > thomas.morta...@xwiki.com> > > wrote: > > > >> By "users" and "devs" you mean "basic" and advanced, right ? > >> > > > > It would be ideal if we could just say it's just basic or advanced. I > meant > > more from a purpose point of view. > > "Devs" can be defined as advanced users or advanced admins, but the main > > differentiator is their clear intention to modify and create apps. > > Sure but there is no standard way to indicate that someone is a "dev" > in XWiki so I will need more details :) > Imo, the dev persona always has admin rights. If they're described as "want to modify and create apps", both of these imply having admin rights: installing apps so that they can modify them requires admin rights, while creating a new app requires admin rights as well (I might be wrong on this one, though). Also, "developing" on a wiki often means "doing what you can from configuration and code the rest", so I guess we can safely assume that they will be admins. As a default setting I'm actually hesitating between 2b and 0, with the possibility to restrain it further in the direction of 2a. I think it could do the job. Thanks, Anca > > IMO the closest we have right now is "advanced" so that' what I listed. > > > > > > > > >> > >> On Thu, May 3, 2018 at 12:11 PM, Ecaterina Moraru (Valica) > >> wrote: > >> > How I see this problem for extension technical pages: > >> > - users -> EDIT right forced false. They don't see the "Edit" button, > so > >> > they are not tempted to edit. > >> > - devs -> WARN. They should be able to modify the pages, but on their > own > >> > expense. > >> > - admins -> WARN. They should be able to control everything, but be > aware > >> > of the risks. > >> > > >> > From what I see the above goes into 1b or 3. The only difference is > if we > >> > should force or not the developers to be admins and also be advanced > >> users, > >> > which in practice it usually happens. > >> > > >> > Simpler visualization of the proposal, where -ED=(EDIT right to DENY) > and > >> > W=(Warning): > >> > > >> > | Users | Admins | > >> > |Basic|Advanced|Basic|Advanced| > >> > 0 | W | W| W | W| > >> > 1a| -ED | W| -ED || > >> > 1b| -ED | W| W | W| > >> > 2a| -ED | -ED | -ED | -ED | > >> > 2b| -ED | -ED | W | W| > >> > 3 | -ED | -ED | -ED | W| > >> > > >> > Thanks, > >> > Caty > >> > > >> > > >> > > >> > On Wed, May 2, 2018 at 8:02 PM, Thomas Mortagne < > >> thomas.morta...@xwiki.com> > >> > wrote: > >> > > >> >> Right I actually forgot to list one possibility in the first mail: > >> >> > >> >> 0) Warning for everyone (so what we have in 10.3) > >> >> > >> >> On Wed, May 2, 2018 at 6:56 PM, Vincent Massol > >> wrote: > >> >> > Hi Thomas, > >> >> > > >> >> >> On 30 Apr 2018, at 14:29, Thomas Mortagne < > thomas.morta...@xwiki.com > >> > > >> >> wrote: > >> >> >> > >> >> >> Hi xwikiers, > >> >> >> > >> >> >> In 10.3 we introduced a warning to discourage users from editing > >> >> >> extension pages (unless the extension indicate it's OK to edit > it). > >> >> >> > >> >> >> This was a first version to have something in 10.3 but the initial > >> >> >> (vague) plan (for 10.4 this time) base on previous discussions > was: > >> >> >> > >> >> >> * EDIT right forced false for basic users > >> >> >> * still a warning for advanced users > >> >> >> * various options to change that (EDIT right forced false for > >> >> >> everyone, warning for everyone, etc.) > >> >> > > >> >> > Note: I haven’t read what’s below yet (looks complex ;)). > >> >> > > >> >> > From a functional POV the minimal needs IMO are: > >> >> > > >> >> > * The warning you’ve already implemented is good as the default > >> >> > * We also need to take the hosting use case, where some company > >> provide > >> >> xwiki hosting and they want to prevent users (including admins, for > >> >> superadmin it’s ok) from editing extension pages so that they can > >> perform > >> >> xwiki upgrades automatically with no conflicts. > >> >> > > >> >> > Ofc if we can support Advanced user vs Simple user use cases (i.e. > >> >> forbid simple user from editing extension pages) that’s nice too but > >> less > >> >> important IMO. > >> >> > > >> >> > Thanks > >> >> > -Vincent > >> >> > > >> >> >> That was before I actually look at what we can do with our > security > >> >> system :) > >> >> >> > >> >> >> Turns out that it's not a huge fan of dynamic criteria like > >> >> >> "basic/advanced user", it's still possible but will require a big > of > >> >> >> work. Also since ADMIN imply EDIT forbidding basic admin to edit a > >> >> >> protected document would not exactly be straightforward. > >> >> >> > >> >> >> Before starting big stuff I would like to discuss in more details > >> what > >> >> >> we wa
Re: [xwiki-devs] [Proposal] Solutions to hide some pages from the navigation panel
Hello all, so, if I remember correctly, the navigation panel is just a call to the documentsTree macro. Unless otherwise specified, my remarks below are about the documentTree macro features. On Wed, May 2, 2018 at 6:02 PM, Marius Dumitru Florea < mariusdumitru.flo...@xwiki.com> wrote: > Hi devs, > > Some users have complained that the navigation panel shows top level pages > that they don't need/want to navigate to, most importantly the XWiki page. > > There are multiple ways in which we can fix this. > > Solution 1: Content Page > > Create a top level "Content" page for user content and configure the > navigation panel to show the contents of this page. > > Pros: > * Namespace isolation (no conflicts between user pages and application > pages) > > Cons: > * The user may want to navigate to a top level application page (although > it's better to use the application panel for this instead) > * All the paths / references used to access the user content will start > with this "Content" page > The documentTree macro already has this feature, actually, to be able to start in a given root and I thought about this solution (manually implemented with a custom documentTree with a custom root). However, I think it's too restrictive (to force all content to be rooted in "Content") and in order to technically make it happen you'd need to change too many places of XWiki: the create, copy and move screens (when location is chosen) in order to make sure that user does not create content somewhere else. > > > Solution 2: Blacklisting > > Add support for specifying a list of (top level) pages to exclude from the > navigation panel. > Most of the usecases I had fall into this category, with blacklisting only at root level (if this makes it easier to implement or doesn't introduce perf. issues). So to me the pages to exclude would be a feature of the documentTree macro (which can also be used as a gadget on a dashboard). > > Pros: > * The user (top level) pages created later on will be visible in the > navigation panel > * The blacklist could be used to filter not only top level pages but also > any nested page from the navigation panel. > > Cons: > * The blacklist depends on the installed apps. The administrator may have > to update the blacklist when new applications are installed > Actually, this is a feature :) : any page (be it extension or user created content) is whitelisted until an administrator decides that it should not be in the tree. Note that it's the administrator that installs extensions on a wiki, and at least in theory it's not done every morning. For the management of the blacklists of the navigation panel (what navigation panel will pass to the documentTree macro), we can use an administration section, just like we do for what the applications panel displays by default :D. In addition, it would be consistent with what we already have! > * The blacklist depends on whether you view hidden pages or not. If you > don't view hidden pages then the blacklist probably contains 4 pages: Help, > Menu, Sandbox, XWiki (there is an application panel entry for each of them > except XWiki), which is manageable. If you view hidden pages then you need > to black list 28+ pages which is hard to manage and maintain. > The fact that you see too many pages when you activate hidden pages in your profile is a problem that is not specific to the tree, so it shouldn't surprise anyone that the tree also shows too many things. To me, seeing hidden pages is not a "regular user in production" setting, it's mostly for setup / development phase. > * The filtering needs to happen on the database (otherwise we break the > pagination) so the database queries will become a bit more complex, which > could led to some performance penalty, depending on how long the blacklist > is. > > Solution 3: Whitelisting > > Add support for controlling the list of top level pages that are displayed > in the navigation panel. > this is the same principle as blacklisting (only "reversed"), and as far as I can project now, it already has a workaround: having multiple documentTree calls with the root parameter set and showroots to true. Also, the default create button of the wiki creates pages on the root of the wiki, next to "Main" and this would mean that the administrator would need to update the navigation panel any time a page is created, which is way more often than "any time an extension is installed". > > Pros: > * the whitelist doesn't depend on the installed extensions or hidden pages > so it's easier to maintain. > * the whitelist can be used to order the top level pages visible in the > navigation panel. > * the whitelist can be used to show at the top level (for navigation > purpose) a page that is not really a top level page > * No performance penalty > > Cons: > * The user (top level) pages created later on will not be visible in the > navigation panel. The administrator will have to add them to the whitelist > if they are
Re: [xwiki-devs] [Proposal] So which protection to we want by default for extensions pages
On Thu, May 3, 2018 at 1:32 PM, Vincent Massol wrote: > > > > On 3 May 2018, at 12:27, Ecaterina Moraru (Valica) > wrote: > > > > It would be interesting to have an Administration configuration to ask if > > extension customization are allowed or not: > > - for advanced developers that want total control of their instance and > > create a custom one, they would put YES and do the upgrades on their own; > > I’m fine with simple/advanced user but Thomas mentioned that it’s > hard/dangerous to do so I’m not sure we should focus on that one FTM. > > > - (2a) while for Cloud/MyXWiki it would be on NO, using the applications > as > > they are and only manage the content. > > > Note that it’s not just for Cloud/MyXWiki but any sane admin might want > that on the xwiki instance he/she administers to forbid users from changing > extension pages because he/she’ll be the one doing the upgrade and doesn’t > any bad surprise to upgrade! > They can do this already with access rights. The problem is that: * The Extension Manager doesn't have an UI to list the pages belonging to an installed XAR extension * The Admin doesn't always know which page from the extension XAR should be protected (which is code and which is demo content) We could probably add a step at the end of XAR extension install to allow the administrator to configure the extension/application access rights. This step could also be an administration section under User & Rights, e.g "Applications" where we show a tree with installed XAR extensions at the top and their pages below, allowing the administrator to configure the access rights. The issue is choosing/providing a default. The default could be based on the XAR page type, e.g. after a XAR extension is installed a script set edit right to allow for admin group based on the page type. > > It’s actually a sane default and the more I think about it and the more I > think it should be the default (and allow admins to turn page extension > editing on the first time they really need it). > > Thanks > -Vincent > > > > > On Thu, May 3, 2018 at 1:20 PM, Vincent Massol > wrote: > > > >> > >>> On 3 May 2018, at 12:11, Ecaterina Moraru (Valica) > >> wrote: > >>> > >>> How I see this problem for extension technical pages: > >>> - users -> EDIT right forced false. They don't see the "Edit" button, > so > >>> they are not tempted to edit. > >>> - devs -> WARN. They should be able to modify the pages, but on their > own > >>> expense. > >>> - admins -> WARN. They should be able to control everything, but be > aware > >>> of the risks. > >> > >> You’re forgetting the the hosting/easy upgrade use case ;) > >> > >> Thanks > >> -Vincent > >> > >>> > >>> From what I see the above goes into 1b or 3. The only difference is if > we > >>> should force or not the developers to be admins and also be advanced > >> users, > >>> which in practice it usually happens. > >>> > >>> Simpler visualization of the proposal, where -ED=(EDIT right to DENY) > and > >>> W=(Warning): > >>> > >>> | Users | Admins | > >>> |Basic|Advanced|Basic|Advanced| > >>> 0 | W | W| W | W| > >>> 1a| -ED | W| -ED || > >>> 1b| -ED | W| W | W| > >>> 2a| -ED | -ED | -ED | -ED | > >>> 2b| -ED | -ED | W | W| > >>> 3 | -ED | -ED | -ED | W| > >>> > >>> Thanks, > >>> Caty > >>> > >>> > >>> > >>> On Wed, May 2, 2018 at 8:02 PM, Thomas Mortagne < > >> thomas.morta...@xwiki.com> > >>> wrote: > >>> > Right I actually forgot to list one possibility in the first mail: > > 0) Warning for everyone (so what we have in 10.3) > > On Wed, May 2, 2018 at 6:56 PM, Vincent Massol > >> wrote: > > Hi Thomas, > > > >> On 30 Apr 2018, at 14:29, Thomas Mortagne < > thomas.morta...@xwiki.com> > wrote: > >> > >> Hi xwikiers, > >> > >> In 10.3 we introduced a warning to discourage users from editing > >> extension pages (unless the extension indicate it's OK to edit it). > >> > >> This was a first version to have something in 10.3 but the initial > >> (vague) plan (for 10.4 this time) base on previous discussions was: > >> > >> * EDIT right forced false for basic users > >> * still a warning for advanced users > >> * various options to change that (EDIT right forced false for > >> everyone, warning for everyone, etc.) > > > > Note: I haven’t read what’s below yet (looks complex ;)). > > > > From a functional POV the minimal needs IMO are: > > > > * The warning you’ve already implemented is good as the default > > * We also need to take the hosting use case, where some company > provide > xwiki hosting and they want to prevent users (including admins, for > superadmin it’s ok) from editing extension pages so that they can > >> perform > xwiki upgrades automatically with no conflicts. > > > > Ofc if we can support Advanced user vs Simple user use cases (i.
Re: [xwiki-devs] [Proposal] Solutions to hide some pages from the navigation panel
On Thu, May 3, 2018 at 4:28 PM, Ecaterina Moraru (Valica) wrote: > On Thu, May 3, 2018 at 4:21 PM, Marius Dumitru Florea < > mariusdumitru.flo...@xwiki.com> wrote: > > > On Thu, May 3, 2018 at 3:01 PM, Vincent Massol > wrote: > > > > > Hi Marius, > > > > > > See below > > > > > > > On 3 May 2018, at 13:24, Marius Dumitru Florea < > > > mariusdumitru.flo...@xwiki.com> wrote: > > > > > > > > On Thu, May 3, 2018 at 1:44 PM, Vincent Massol > > > wrote: > > > > > > > >> > > > >> > > > >>> On 3 May 2018, at 12:32, Marius Dumitru Florea < > > > >> mariusdumitru.flo...@xwiki.com> wrote: > > > >>> > > > >>> On Thu, May 3, 2018 at 11:58 AM, Ecaterina Moraru (Valica) < > > > >>> vali...@gmail.com> wrote: > > > >>> > > > On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < > > > mariusdumitru.flo...@xwiki.com> wrote: > > > > > > > Hi devs, > > > > > > > > Some users have complained that the navigation panel shows top > > level > > > pages > > > > that they don't need/want to navigate to, most importantly the > > XWiki > > > page. > > > > > > > > There are multiple ways in which we can fix this. > > > > > > > > Solution 1: Content Page > > > > > > > > Create a top level "Content" page for user content and configure > > the > > > > navigation panel to show the contents of this page. > > > > > > > > Pros: > > > > * Namespace isolation (no conflicts between user pages and > > > application > > > > pages) > > > > > > > > Cons: > > > > * The user may want to navigate to a top level application page > > > >> (although > > > > it's better to use the application panel for this instead) > > > > * All the paths / references used to access the user content will > > > start > > > > with this "Content" page > > > > > > > > > > > > > > >>> > > > >>> > > > S1: This solution is good if users would work in isolation or in > the > > > evaluation period, but for team and multiple people sharing > spaces, > > I > > > >> don't > > > see this as a valid solution. > > > > > > >>> > > > >>> The Content space is for all users, shared. This is not about > having > > a > > > >>> separate space for each user. > > > >>> > > > >>> > > > -0 > > > > > > > > > > > > > > Solution 2: Blacklisting > > > > > > > > Add support for specifying a list of (top level) pages to exclude > > > from > > > the > > > > navigation panel. > > > > > > > > Pros: > > > > * The user (top level) pages created later on will be visible in > > the > > > > navigation panel > > > > * The blacklist could be used to filter not only top level pages > > but > > > >> also > > > > any nested page from the navigation panel. > > > > > > > > Cons: > > > > * The blacklist depends on the installed apps. The administrator > > may > > > >> have > > > > to update the blacklist when new applications are installed > > > > * The blacklist depends on whether you view hidden pages or not. > If > > > you > > > > don't view hidden pages then the blacklist probably contains 4 > > pages: > > > Help, > > > > Menu, Sandbox, XWiki (there is an application panel entry for > each > > of > > > them > > > > except XWiki), which is manageable. If you view hidden pages then > > you > > > need > > > > to black list 28+ pages which is hard to manage and maintain. > > > > * The filtering needs to happen on the database (otherwise we > break > > > the > > > > pagination) so the database queries will become a bit more > complex, > > > >> which > > > > could led to some performance penalty, depending on how long the > > > blacklist > > > > is. > > > > > > > > > > > S2: I see the blacklist solution more as a hack for things in > XWiki > > > that > > > should be fixed (have users outside XWiki space, move Sandbox into > > > Help > > > space, hide Help pages and provide a dedicated Help entry in the > > User > > > >> menu, > > > etc.) but we don't have the time to do it. > > > -0 in an ideal state > > > > > > > > > > > > > > Solution 3: Whitelisting > > > > > > > > Add support for controlling the list of top level pages that are > > > displayed > > > > in the navigation panel. > > > > > > > > Pros: > > > > * the whitelist doesn't depend on the installed extensions or > > hidden > > > pages > > > > so it's easier to maintain. > > > > * the whitelist can be used to order the top level pages visible > in > > > the > > > > navigation panel. > > > > * the whitelist can be used to show at the top level (for > > navigation > > > > purpose) a page that is not really a top level page > > > > * No performance penalty > > > > > > > > Cons: > > > > * The user (top level) pages created later on will not be visible > > in > > > >> the
Re: [xwiki-devs] [GSoC] Community Bonding Period ending on 14th of May. PRs needed!
Hi again, An very important detail that I forgot to remind you (it's mentioned in the Student Guidelines as well) is that you need to be registered to the devs@xwiki.org mailing list [1] in order to be able to post messages to it. If you sent the email without being registered, you messages will not reach the list and we will not be able to see them. Thanks, Eduard -- [1] http://dev.xwiki.org/xwiki/bin/view/Community/Discuss#HMailingLists On Thu, May 3, 2018 at 2:58 AM, Алексей Овсянников < ovsyannikov.alexe...@gmail.com> wrote: > Got it! > > On Thu, May 3, 2018, 00:58 Eduard Moraru wrote: > >> Hello, GSoC students, >> >> As you all know, we are in the middle of the "Community Bonding" period >> of the GSoC 2018 program's timeline [1]. >> >> This is a very important period in which you are supposed to get familiar >> with the XWiki project, read documentation (APIs, processes, development >> practices, etc.), setup tooling and development environments, figure out >> the way the project is organized and what is the best approach for you to >> make an impact. At the end of this period, you should be ready and >> productive to start working on your cool project. (Nobody will complain if >> you have already started ;) ). >> >> Even more so, the community bonding period is about getting to know the >> community and helping the community to know you. So, if you have not yet >> introduced yourself or did not get the chance to exchange some initial >> thoughts with your mentor(s), now is the time to do it. You need to >> remember that GSoC is not a bounty program, but a community building one, >> so the main objective is not simply to deliver, at a certain deadline, a >> feature, but to be integrated in the open source community you have joined >> and help it grow (through your contributions). >> >> As such, on the technical side, your objective for this period is to get >> at least 1 of your Pull Requests (average size/complexity, must contain a >> few lines of code) to get reviewed and accepted either in the main >> repositories (platform/commons/rendering) or in one of the existing Contrib >> extensions. The PR needs to be associated to an existing Jira issue >> (bug/improvement). >> >> Make sure you read and follow the Student Guidelines, specifically the >> section dedicated to accepted students [2]. >> >> >> Reminder1: The deadline is the 14th of May. >> >> Reminder2: The community bonding period is also an eliminatory period. >> Students that choose to stay silent may be considered for elimination from >> the program. >> >> >> Thanks, >> Eduard >> >> -- >> [1] https://developers.google.com/open-source/gsoc/timeline >> [2] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines# >> HSuggestedwayofworkingforacceptedGSoCstudents >> >
Re: [xwiki-devs] [Proposal] So which protection to we want by default for extensions pages
On Thu, May 3, 2018 at 3:09 PM, Ecaterina Moraru (Valica) wrote: > On Thu, May 3, 2018 at 2:56 PM, Thomas Mortagne > wrote: > >> By "users" and "devs" you mean "basic" and advanced, right ? >> > > It would be ideal if we could just say it's just basic or advanced. I meant > more from a purpose point of view. > "Devs" can be defined as advanced users or advanced admins, but the main > differentiator is their clear intention to modify and create apps. Sure but there is no standard way to indicate that someone is a "dev" in XWiki so I will need more details :) IMO the closest we have right now is "advanced" so that' what I listed. > > > >> >> On Thu, May 3, 2018 at 12:11 PM, Ecaterina Moraru (Valica) >> wrote: >> > How I see this problem for extension technical pages: >> > - users -> EDIT right forced false. They don't see the "Edit" button, so >> > they are not tempted to edit. >> > - devs -> WARN. They should be able to modify the pages, but on their own >> > expense. >> > - admins -> WARN. They should be able to control everything, but be aware >> > of the risks. >> > >> > From what I see the above goes into 1b or 3. The only difference is if we >> > should force or not the developers to be admins and also be advanced >> users, >> > which in practice it usually happens. >> > >> > Simpler visualization of the proposal, where -ED=(EDIT right to DENY) and >> > W=(Warning): >> > >> > | Users | Admins | >> > |Basic|Advanced|Basic|Advanced| >> > 0 | W | W| W | W| >> > 1a| -ED | W| -ED || >> > 1b| -ED | W| W | W| >> > 2a| -ED | -ED | -ED | -ED | >> > 2b| -ED | -ED | W | W| >> > 3 | -ED | -ED | -ED | W| >> > >> > Thanks, >> > Caty >> > >> > >> > >> > On Wed, May 2, 2018 at 8:02 PM, Thomas Mortagne < >> thomas.morta...@xwiki.com> >> > wrote: >> > >> >> Right I actually forgot to list one possibility in the first mail: >> >> >> >> 0) Warning for everyone (so what we have in 10.3) >> >> >> >> On Wed, May 2, 2018 at 6:56 PM, Vincent Massol >> wrote: >> >> > Hi Thomas, >> >> > >> >> >> On 30 Apr 2018, at 14:29, Thomas Mortagne > > >> >> wrote: >> >> >> >> >> >> Hi xwikiers, >> >> >> >> >> >> In 10.3 we introduced a warning to discourage users from editing >> >> >> extension pages (unless the extension indicate it's OK to edit it). >> >> >> >> >> >> This was a first version to have something in 10.3 but the initial >> >> >> (vague) plan (for 10.4 this time) base on previous discussions was: >> >> >> >> >> >> * EDIT right forced false for basic users >> >> >> * still a warning for advanced users >> >> >> * various options to change that (EDIT right forced false for >> >> >> everyone, warning for everyone, etc.) >> >> > >> >> > Note: I haven’t read what’s below yet (looks complex ;)). >> >> > >> >> > From a functional POV the minimal needs IMO are: >> >> > >> >> > * The warning you’ve already implemented is good as the default >> >> > * We also need to take the hosting use case, where some company >> provide >> >> xwiki hosting and they want to prevent users (including admins, for >> >> superadmin it’s ok) from editing extension pages so that they can >> perform >> >> xwiki upgrades automatically with no conflicts. >> >> > >> >> > Ofc if we can support Advanced user vs Simple user use cases (i.e. >> >> forbid simple user from editing extension pages) that’s nice too but >> less >> >> important IMO. >> >> > >> >> > Thanks >> >> > -Vincent >> >> > >> >> >> That was before I actually look at what we can do with our security >> >> system :) >> >> >> >> >> >> Turns out that it's not a huge fan of dynamic criteria like >> >> >> "basic/advanced user", it's still possible but will require a big of >> >> >> work. Also since ADMIN imply EDIT forbidding basic admin to edit a >> >> >> protected document would not exactly be straightforward. >> >> >> >> >> >> Before starting big stuff I would like to discuss in more details >> what >> >> >> we want in the end. >> >> >> >> >> >> In this mail I would like to focus on default behavior and we can >> talk >> >> >> about which options we need to provide in another one: >> >> >> >> >> >> Note: in all of theses superdamin still have the right to edit >> >> >> everything (with a warning). >> >> >> >> >> >> 1) Basic/advanced based >> >> >> >> >> >> 1.a) >> >> >> >> >> >> Forced EDIT right to DENY for basic users. >> >> >> Edit warning for advanced users. >> >> >> Forced EDIT right to DENY for basic admins (we overwrite the ADMIN >> >> >> implied rights logic) >> >> >> >> >> >> 1.b) >> >> >> >> >> >> Forced EDIT right to DENY for basic users. >> >> >> Edit warning for advanced users. >> >> >> Edit warning for admins (they get EDIT trough ADMIN right). >> >> >> >> >> >> 2) Admin right based >> >> >> >> >> >> 2.a) >> >> >> >> >> >> Forced EDIT right to DENY for everyone >> >> >> Even admins >> >> >> >> >> >> 2.b) >> >> >> >> >> >> Forced EDIT right to DENY for everyone >> >> >> Edit warning for admins (th
Re: [xwiki-devs] [Proposal] Solutions to hide some pages from the navigation panel
On Thu, May 3, 2018 at 4:21 PM, Marius Dumitru Florea < mariusdumitru.flo...@xwiki.com> wrote: > On Thu, May 3, 2018 at 3:01 PM, Vincent Massol wrote: > > > Hi Marius, > > > > See below > > > > > On 3 May 2018, at 13:24, Marius Dumitru Florea < > > mariusdumitru.flo...@xwiki.com> wrote: > > > > > > On Thu, May 3, 2018 at 1:44 PM, Vincent Massol > > wrote: > > > > > >> > > >> > > >>> On 3 May 2018, at 12:32, Marius Dumitru Florea < > > >> mariusdumitru.flo...@xwiki.com> wrote: > > >>> > > >>> On Thu, May 3, 2018 at 11:58 AM, Ecaterina Moraru (Valica) < > > >>> vali...@gmail.com> wrote: > > >>> > > On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < > > mariusdumitru.flo...@xwiki.com> wrote: > > > > > Hi devs, > > > > > > Some users have complained that the navigation panel shows top > level > > pages > > > that they don't need/want to navigate to, most importantly the > XWiki > > page. > > > > > > There are multiple ways in which we can fix this. > > > > > > Solution 1: Content Page > > > > > > Create a top level "Content" page for user content and configure > the > > > navigation panel to show the contents of this page. > > > > > > Pros: > > > * Namespace isolation (no conflicts between user pages and > > application > > > pages) > > > > > > Cons: > > > * The user may want to navigate to a top level application page > > >> (although > > > it's better to use the application panel for this instead) > > > * All the paths / references used to access the user content will > > start > > > with this "Content" page > > > > > > > > > > >>> > > >>> > > S1: This solution is good if users would work in isolation or in the > > evaluation period, but for team and multiple people sharing spaces, > I > > >> don't > > see this as a valid solution. > > > > >>> > > >>> The Content space is for all users, shared. This is not about having > a > > >>> separate space for each user. > > >>> > > >>> > > -0 > > > > > > > > > > Solution 2: Blacklisting > > > > > > Add support for specifying a list of (top level) pages to exclude > > from > > the > > > navigation panel. > > > > > > Pros: > > > * The user (top level) pages created later on will be visible in > the > > > navigation panel > > > * The blacklist could be used to filter not only top level pages > but > > >> also > > > any nested page from the navigation panel. > > > > > > Cons: > > > * The blacklist depends on the installed apps. The administrator > may > > >> have > > > to update the blacklist when new applications are installed > > > * The blacklist depends on whether you view hidden pages or not. If > > you > > > don't view hidden pages then the blacklist probably contains 4 > pages: > > Help, > > > Menu, Sandbox, XWiki (there is an application panel entry for each > of > > them > > > except XWiki), which is manageable. If you view hidden pages then > you > > need > > > to black list 28+ pages which is hard to manage and maintain. > > > * The filtering needs to happen on the database (otherwise we break > > the > > > pagination) so the database queries will become a bit more complex, > > >> which > > > could led to some performance penalty, depending on how long the > > blacklist > > > is. > > > > > > > > S2: I see the blacklist solution more as a hack for things in XWiki > > that > > should be fixed (have users outside XWiki space, move Sandbox into > > Help > > space, hide Help pages and provide a dedicated Help entry in the > User > > >> menu, > > etc.) but we don't have the time to do it. > > -0 in an ideal state > > > > > > > > > > Solution 3: Whitelisting > > > > > > Add support for controlling the list of top level pages that are > > displayed > > > in the navigation panel. > > > > > > Pros: > > > * the whitelist doesn't depend on the installed extensions or > hidden > > pages > > > so it's easier to maintain. > > > * the whitelist can be used to order the top level pages visible in > > the > > > navigation panel. > > > * the whitelist can be used to show at the top level (for > navigation > > > purpose) a page that is not really a top level page > > > * No performance penalty > > > > > > Cons: > > > * The user (top level) pages created later on will not be visible > in > > >> the > > > navigation panel. The administrator will have to add them to the > > whitelist > > > if they are useful for the navigation. Although creating top level > > >> pages > > > should happen less often than creating nested pages under the > > existing > > top > > > level pages. > > > * the whitelist controls only the first level in the tree. The next > >
Re: [xwiki-devs] [Proposal] Solutions to hide some pages from the navigation panel
On Thu, May 3, 2018 at 3:01 PM, Vincent Massol wrote: > Hi Marius, > > See below > > > On 3 May 2018, at 13:24, Marius Dumitru Florea < > mariusdumitru.flo...@xwiki.com> wrote: > > > > On Thu, May 3, 2018 at 1:44 PM, Vincent Massol > wrote: > > > >> > >> > >>> On 3 May 2018, at 12:32, Marius Dumitru Florea < > >> mariusdumitru.flo...@xwiki.com> wrote: > >>> > >>> On Thu, May 3, 2018 at 11:58 AM, Ecaterina Moraru (Valica) < > >>> vali...@gmail.com> wrote: > >>> > On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < > mariusdumitru.flo...@xwiki.com> wrote: > > > Hi devs, > > > > Some users have complained that the navigation panel shows top level > pages > > that they don't need/want to navigate to, most importantly the XWiki > page. > > > > There are multiple ways in which we can fix this. > > > > Solution 1: Content Page > > > > Create a top level "Content" page for user content and configure the > > navigation panel to show the contents of this page. > > > > Pros: > > * Namespace isolation (no conflicts between user pages and > application > > pages) > > > > Cons: > > * The user may want to navigate to a top level application page > >> (although > > it's better to use the application panel for this instead) > > * All the paths / references used to access the user content will > start > > with this "Content" page > > > > > > >>> > >>> > S1: This solution is good if users would work in isolation or in the > evaluation period, but for team and multiple people sharing spaces, I > >> don't > see this as a valid solution. > > >>> > >>> The Content space is for all users, shared. This is not about having a > >>> separate space for each user. > >>> > >>> > -0 > > > > > > Solution 2: Blacklisting > > > > Add support for specifying a list of (top level) pages to exclude > from > the > > navigation panel. > > > > Pros: > > * The user (top level) pages created later on will be visible in the > > navigation panel > > * The blacklist could be used to filter not only top level pages but > >> also > > any nested page from the navigation panel. > > > > Cons: > > * The blacklist depends on the installed apps. The administrator may > >> have > > to update the blacklist when new applications are installed > > * The blacklist depends on whether you view hidden pages or not. If > you > > don't view hidden pages then the blacklist probably contains 4 pages: > Help, > > Menu, Sandbox, XWiki (there is an application panel entry for each of > them > > except XWiki), which is manageable. If you view hidden pages then you > need > > to black list 28+ pages which is hard to manage and maintain. > > * The filtering needs to happen on the database (otherwise we break > the > > pagination) so the database queries will become a bit more complex, > >> which > > could led to some performance penalty, depending on how long the > blacklist > > is. > > > > > S2: I see the blacklist solution more as a hack for things in XWiki > that > should be fixed (have users outside XWiki space, move Sandbox into > Help > space, hide Help pages and provide a dedicated Help entry in the User > >> menu, > etc.) but we don't have the time to do it. > -0 in an ideal state > > > > > > Solution 3: Whitelisting > > > > Add support for controlling the list of top level pages that are > displayed > > in the navigation panel. > > > > Pros: > > * the whitelist doesn't depend on the installed extensions or hidden > pages > > so it's easier to maintain. > > * the whitelist can be used to order the top level pages visible in > the > > navigation panel. > > * the whitelist can be used to show at the top level (for navigation > > purpose) a page that is not really a top level page > > * No performance penalty > > > > Cons: > > * The user (top level) pages created later on will not be visible in > >> the > > navigation panel. The administrator will have to add them to the > whitelist > > if they are useful for the navigation. Although creating top level > >> pages > > should happen less often than creating nested pages under the > existing > top > > level pages. > > * the whitelist controls only the first level in the tree. The next > levels > > will be dynamic (database queries) and with the default order. > > > > S3: I prefer this solution, but with the ability to also display some > dynamic pattern, something like: display X, Y and all children of Z, > or > all pages starting with A, or all pages created by group N :) (they > are > just ideas, I know some are very hard to implement). > +1 > > >>>
Re: [xwiki-devs] [Proposal] So which protection to we want by default for extensions pages
On Thu, May 3, 2018 at 2:56 PM, Thomas Mortagne wrote: > By "users" and "devs" you mean "basic" and advanced, right ? > It would be ideal if we could just say it's just basic or advanced. I meant more from a purpose point of view. "Devs" can be defined as advanced users or advanced admins, but the main differentiator is their clear intention to modify and create apps. > > On Thu, May 3, 2018 at 12:11 PM, Ecaterina Moraru (Valica) > wrote: > > How I see this problem for extension technical pages: > > - users -> EDIT right forced false. They don't see the "Edit" button, so > > they are not tempted to edit. > > - devs -> WARN. They should be able to modify the pages, but on their own > > expense. > > - admins -> WARN. They should be able to control everything, but be aware > > of the risks. > > > > From what I see the above goes into 1b or 3. The only difference is if we > > should force or not the developers to be admins and also be advanced > users, > > which in practice it usually happens. > > > > Simpler visualization of the proposal, where -ED=(EDIT right to DENY) and > > W=(Warning): > > > > | Users | Admins | > > |Basic|Advanced|Basic|Advanced| > > 0 | W | W| W | W| > > 1a| -ED | W| -ED || > > 1b| -ED | W| W | W| > > 2a| -ED | -ED | -ED | -ED | > > 2b| -ED | -ED | W | W| > > 3 | -ED | -ED | -ED | W| > > > > Thanks, > > Caty > > > > > > > > On Wed, May 2, 2018 at 8:02 PM, Thomas Mortagne < > thomas.morta...@xwiki.com> > > wrote: > > > >> Right I actually forgot to list one possibility in the first mail: > >> > >> 0) Warning for everyone (so what we have in 10.3) > >> > >> On Wed, May 2, 2018 at 6:56 PM, Vincent Massol > wrote: > >> > Hi Thomas, > >> > > >> >> On 30 Apr 2018, at 14:29, Thomas Mortagne > > >> wrote: > >> >> > >> >> Hi xwikiers, > >> >> > >> >> In 10.3 we introduced a warning to discourage users from editing > >> >> extension pages (unless the extension indicate it's OK to edit it). > >> >> > >> >> This was a first version to have something in 10.3 but the initial > >> >> (vague) plan (for 10.4 this time) base on previous discussions was: > >> >> > >> >> * EDIT right forced false for basic users > >> >> * still a warning for advanced users > >> >> * various options to change that (EDIT right forced false for > >> >> everyone, warning for everyone, etc.) > >> > > >> > Note: I haven’t read what’s below yet (looks complex ;)). > >> > > >> > From a functional POV the minimal needs IMO are: > >> > > >> > * The warning you’ve already implemented is good as the default > >> > * We also need to take the hosting use case, where some company > provide > >> xwiki hosting and they want to prevent users (including admins, for > >> superadmin it’s ok) from editing extension pages so that they can > perform > >> xwiki upgrades automatically with no conflicts. > >> > > >> > Ofc if we can support Advanced user vs Simple user use cases (i.e. > >> forbid simple user from editing extension pages) that’s nice too but > less > >> important IMO. > >> > > >> > Thanks > >> > -Vincent > >> > > >> >> That was before I actually look at what we can do with our security > >> system :) > >> >> > >> >> Turns out that it's not a huge fan of dynamic criteria like > >> >> "basic/advanced user", it's still possible but will require a big of > >> >> work. Also since ADMIN imply EDIT forbidding basic admin to edit a > >> >> protected document would not exactly be straightforward. > >> >> > >> >> Before starting big stuff I would like to discuss in more details > what > >> >> we want in the end. > >> >> > >> >> In this mail I would like to focus on default behavior and we can > talk > >> >> about which options we need to provide in another one: > >> >> > >> >> Note: in all of theses superdamin still have the right to edit > >> >> everything (with a warning). > >> >> > >> >> 1) Basic/advanced based > >> >> > >> >> 1.a) > >> >> > >> >> Forced EDIT right to DENY for basic users. > >> >> Edit warning for advanced users. > >> >> Forced EDIT right to DENY for basic admins (we overwrite the ADMIN > >> >> implied rights logic) > >> >> > >> >> 1.b) > >> >> > >> >> Forced EDIT right to DENY for basic users. > >> >> Edit warning for advanced users. > >> >> Edit warning for admins (they get EDIT trough ADMIN right). > >> >> > >> >> 2) Admin right based > >> >> > >> >> 2.a) > >> >> > >> >> Forced EDIT right to DENY for everyone > >> >> Even admins > >> >> > >> >> 2.b) > >> >> > >> >> Forced EDIT right to DENY for everyone > >> >> Edit warning for admins (they get EDIT trough ADMIN right). > >> >> > >> >> 3) Both > >> >> > >> >> Warning if you are both advanced user and have ADMIN right > >> >> Forced EDIT right to DENY for everyone else > >> >> > >> >> WDYT ? > >> >> > >> >> The initial plan was 1.a in my mind but I'm still hesitating. 2.b is > >> >> by far the easiest to implement and probably good enough but not sure > >> >> having ADMIN right
Re: [xwiki-devs] [Proposal] Solutions to hide some pages from the navigation panel
> On 3 May 2018, at 14:04, Thomas Mortagne wrote: > > On Thu, May 3, 2018 at 10:58 AM, Ecaterina Moraru (Valica) > wrote: >> On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < >> mariusdumitru.flo...@xwiki.com> wrote: >> >>> Hi devs, >>> >>> Some users have complained that the navigation panel shows top level pages >>> that they don't need/want to navigate to, most importantly the XWiki page. >>> >>> There are multiple ways in which we can fix this. >>> >>> Solution 1: Content Page >>> >>> Create a top level "Content" page for user content and configure the >>> navigation panel to show the contents of this page. >>> >>> Pros: >>> * Namespace isolation (no conflicts between user pages and application >>> pages) >>> >>> Cons: >>> * The user may want to navigate to a top level application page (although >>> it's better to use the application panel for this instead) >>> * All the paths / references used to access the user content will start >>> with this "Content" page >>> >>> >> S1: This solution is good if users would work in isolation or in the >> evaluation period, but for team and multiple people sharing spaces, I don't >> see this as a valid solution. >> -0 >> >> >>> >>> Solution 2: Blacklisting >>> >>> Add support for specifying a list of (top level) pages to exclude from the >>> navigation panel. >>> >>> Pros: >>> * The user (top level) pages created later on will be visible in the >>> navigation panel >>> * The blacklist could be used to filter not only top level pages but also >>> any nested page from the navigation panel. >>> >>> Cons: >>> * The blacklist depends on the installed apps. The administrator may have >>> to update the blacklist when new applications are installed >>> * The blacklist depends on whether you view hidden pages or not. If you >>> don't view hidden pages then the blacklist probably contains 4 pages: Help, >>> Menu, Sandbox, XWiki (there is an application panel entry for each of them >>> except XWiki), which is manageable. If you view hidden pages then you need >>> to black list 28+ pages which is hard to manage and maintain. >>> * The filtering needs to happen on the database (otherwise we break the >>> pagination) so the database queries will become a bit more complex, which >>> could led to some performance penalty, depending on how long the blacklist >>> is. >>> >>> >> S2: I see the blacklist solution more as a hack for things in XWiki that >> should be fixed (have users outside XWiki space, move Sandbox into Help >> space, hide Help pages and provide a dedicated Help entry in the User menu, >> etc.) but we don't have the time to do it. >> -0 in an ideal state >> >> >>> >>> Solution 3: Whitelisting >>> >>> Add support for controlling the list of top level pages that are displayed >>> in the navigation panel. >>> >>> Pros: >>> * the whitelist doesn't depend on the installed extensions or hidden pages >>> so it's easier to maintain. >>> * the whitelist can be used to order the top level pages visible in the >>> navigation panel. >>> * the whitelist can be used to show at the top level (for navigation >>> purpose) a page that is not really a top level page >>> * No performance penalty >>> >>> Cons: >>> * The user (top level) pages created later on will not be visible in the >>> navigation panel. The administrator will have to add them to the whitelist >>> if they are useful for the navigation. Although creating top level pages >>> should happen less often than creating nested pages under the existing top >>> level pages. >>> * the whitelist controls only the first level in the tree. The next levels >>> will be dynamic (database queries) and with the default order. >>> >> >> S3: I prefer this solution, but with the ability to also display some >> dynamic pattern, something like: display X, Y and all children of Z, or >> all pages starting with A, or all pages created by group N :) (they are >> just ideas, I know some are very hard to implement). >> +1 >> >> >>> >>> >>> Solution 4: Exclude extension pages >>> >>> Exclude from the navigation panel the top level pages that belong to an >>> installed extension, allowing the administrator to make some exceptions >>> (e.g. keep the home page). The rationale is that if an installed extension >>> has a top level page then that page is most probably the application home >>> page which should be accessible from the application panel. This can be >>> implemented on top of solution 3 (the whitelist is basically dynamic: we >>> collect the top level pages that don't belong to an extension). >>> >>> Pros: >>> * It does a clear separation between applications (accessible from the >>> application panel) and content (accessible from the navigation panel). The >>> navigation panel is currently mixing application pages and (user) content >>> pages. >>> * The administrator doesn't need to update the navigation panel >>> configuration to exclude a top level application home page each time an >>> application
Re: [xwiki-devs] [Proposal] Solutions to hide some pages from the navigation panel
On Thu, May 3, 2018 at 10:58 AM, Ecaterina Moraru (Valica) wrote: > On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < > mariusdumitru.flo...@xwiki.com> wrote: > >> Hi devs, >> >> Some users have complained that the navigation panel shows top level pages >> that they don't need/want to navigate to, most importantly the XWiki page. >> >> There are multiple ways in which we can fix this. >> >> Solution 1: Content Page >> >> Create a top level "Content" page for user content and configure the >> navigation panel to show the contents of this page. >> >> Pros: >> * Namespace isolation (no conflicts between user pages and application >> pages) >> >> Cons: >> * The user may want to navigate to a top level application page (although >> it's better to use the application panel for this instead) >> * All the paths / references used to access the user content will start >> with this "Content" page >> >> > S1: This solution is good if users would work in isolation or in the > evaluation period, but for team and multiple people sharing spaces, I don't > see this as a valid solution. > -0 > > >> >> Solution 2: Blacklisting >> >> Add support for specifying a list of (top level) pages to exclude from the >> navigation panel. >> >> Pros: >> * The user (top level) pages created later on will be visible in the >> navigation panel >> * The blacklist could be used to filter not only top level pages but also >> any nested page from the navigation panel. >> >> Cons: >> * The blacklist depends on the installed apps. The administrator may have >> to update the blacklist when new applications are installed >> * The blacklist depends on whether you view hidden pages or not. If you >> don't view hidden pages then the blacklist probably contains 4 pages: Help, >> Menu, Sandbox, XWiki (there is an application panel entry for each of them >> except XWiki), which is manageable. If you view hidden pages then you need >> to black list 28+ pages which is hard to manage and maintain. >> * The filtering needs to happen on the database (otherwise we break the >> pagination) so the database queries will become a bit more complex, which >> could led to some performance penalty, depending on how long the blacklist >> is. >> >> > S2: I see the blacklist solution more as a hack for things in XWiki that > should be fixed (have users outside XWiki space, move Sandbox into Help > space, hide Help pages and provide a dedicated Help entry in the User menu, > etc.) but we don't have the time to do it. > -0 in an ideal state > > >> >> Solution 3: Whitelisting >> >> Add support for controlling the list of top level pages that are displayed >> in the navigation panel. >> >> Pros: >> * the whitelist doesn't depend on the installed extensions or hidden pages >> so it's easier to maintain. >> * the whitelist can be used to order the top level pages visible in the >> navigation panel. >> * the whitelist can be used to show at the top level (for navigation >> purpose) a page that is not really a top level page >> * No performance penalty >> >> Cons: >> * The user (top level) pages created later on will not be visible in the >> navigation panel. The administrator will have to add them to the whitelist >> if they are useful for the navigation. Although creating top level pages >> should happen less often than creating nested pages under the existing top >> level pages. >> * the whitelist controls only the first level in the tree. The next levels >> will be dynamic (database queries) and with the default order. >> > > S3: I prefer this solution, but with the ability to also display some > dynamic pattern, something like: display X, Y and all children of Z, or > all pages starting with A, or all pages created by group N :) (they are > just ideas, I know some are very hard to implement). > +1 > > >> >> >> Solution 4: Exclude extension pages >> >> Exclude from the navigation panel the top level pages that belong to an >> installed extension, allowing the administrator to make some exceptions >> (e.g. keep the home page). The rationale is that if an installed extension >> has a top level page then that page is most probably the application home >> page which should be accessible from the application panel. This can be >> implemented on top of solution 3 (the whitelist is basically dynamic: we >> collect the top level pages that don't belong to an extension). >> >> Pros: >> * It does a clear separation between applications (accessible from the >> application panel) and content (accessible from the navigation panel). The >> navigation panel is currently mixing application pages and (user) content >> pages. >> * The administrator doesn't need to update the navigation panel >> configuration to exclude a top level application home page each time an >> application is installed >> * The hidden top level extension code pages are not shown even when "show >> hidden pages" is set to true >> * The user top level pages created later on appear in the tree >> automatically >>
Re: [xwiki-devs] [Proposal] So which protection to we want by default for extensions pages
> On 3 May 2018, at 13:56, Thomas Mortagne wrote: > > By "users" and "devs" you mean "basic" and advanced, right ? “simple” and “advanced” since “basic” doesn’t exist ;) http://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/PageEditing -Vincent > > On Thu, May 3, 2018 at 12:11 PM, Ecaterina Moraru (Valica) > wrote: >> How I see this problem for extension technical pages: >> - users -> EDIT right forced false. They don't see the "Edit" button, so >> they are not tempted to edit. >> - devs -> WARN. They should be able to modify the pages, but on their own >> expense. >> - admins -> WARN. They should be able to control everything, but be aware >> of the risks. >> >> From what I see the above goes into 1b or 3. The only difference is if we >> should force or not the developers to be admins and also be advanced users, >> which in practice it usually happens. >> >> Simpler visualization of the proposal, where -ED=(EDIT right to DENY) and >> W=(Warning): >> >> | Users | Admins | >> |Basic|Advanced|Basic|Advanced| >> 0 | W | W| W | W| >> 1a| -ED | W| -ED || >> 1b| -ED | W| W | W| >> 2a| -ED | -ED | -ED | -ED | >> 2b| -ED | -ED | W | W| >> 3 | -ED | -ED | -ED | W| >> >> Thanks, >> Caty >> >> >> >> On Wed, May 2, 2018 at 8:02 PM, Thomas Mortagne >> wrote: >> >>> Right I actually forgot to list one possibility in the first mail: >>> >>> 0) Warning for everyone (so what we have in 10.3) >>> >>> On Wed, May 2, 2018 at 6:56 PM, Vincent Massol wrote: Hi Thomas, > On 30 Apr 2018, at 14:29, Thomas Mortagne >>> wrote: > > Hi xwikiers, > > In 10.3 we introduced a warning to discourage users from editing > extension pages (unless the extension indicate it's OK to edit it). > > This was a first version to have something in 10.3 but the initial > (vague) plan (for 10.4 this time) base on previous discussions was: > > * EDIT right forced false for basic users > * still a warning for advanced users > * various options to change that (EDIT right forced false for > everyone, warning for everyone, etc.) Note: I haven’t read what’s below yet (looks complex ;)). From a functional POV the minimal needs IMO are: * The warning you’ve already implemented is good as the default * We also need to take the hosting use case, where some company provide >>> xwiki hosting and they want to prevent users (including admins, for >>> superadmin it’s ok) from editing extension pages so that they can perform >>> xwiki upgrades automatically with no conflicts. Ofc if we can support Advanced user vs Simple user use cases (i.e. >>> forbid simple user from editing extension pages) that’s nice too but less >>> important IMO. Thanks -Vincent > That was before I actually look at what we can do with our security >>> system :) > > Turns out that it's not a huge fan of dynamic criteria like > "basic/advanced user", it's still possible but will require a big of > work. Also since ADMIN imply EDIT forbidding basic admin to edit a > protected document would not exactly be straightforward. > > Before starting big stuff I would like to discuss in more details what > we want in the end. > > In this mail I would like to focus on default behavior and we can talk > about which options we need to provide in another one: > > Note: in all of theses superdamin still have the right to edit > everything (with a warning). > > 1) Basic/advanced based > > 1.a) > > Forced EDIT right to DENY for basic users. > Edit warning for advanced users. > Forced EDIT right to DENY for basic admins (we overwrite the ADMIN > implied rights logic) > > 1.b) > > Forced EDIT right to DENY for basic users. > Edit warning for advanced users. > Edit warning for admins (they get EDIT trough ADMIN right). > > 2) Admin right based > > 2.a) > > Forced EDIT right to DENY for everyone > Even admins > > 2.b) > > Forced EDIT right to DENY for everyone > Edit warning for admins (they get EDIT trough ADMIN right). > > 3) Both > > Warning if you are both advanced user and have ADMIN right > Forced EDIT right to DENY for everyone else > > WDYT ? > > The initial plan was 1.a in my mind but I'm still hesitating. 2.b is > by far the easiest to implement and probably good enough but not sure > having ADMIN right is the right criteria to be allowed to force edit > of protected pages since it's not about security and more about > knowledge. > > I'm -1 for 2.a) as a default. It's way too harsh for the product (but > I can understand it as an option in a cloud offering for example). > It's quite young and we wi
Re: [xwiki-devs] [Proposal] Solutions to hide some pages from the navigation panel
Hi Marius, See below > On 3 May 2018, at 13:24, Marius Dumitru Florea > wrote: > > On Thu, May 3, 2018 at 1:44 PM, Vincent Massol wrote: > >> >> >>> On 3 May 2018, at 12:32, Marius Dumitru Florea < >> mariusdumitru.flo...@xwiki.com> wrote: >>> >>> On Thu, May 3, 2018 at 11:58 AM, Ecaterina Moraru (Valica) < >>> vali...@gmail.com> wrote: >>> On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < mariusdumitru.flo...@xwiki.com> wrote: > Hi devs, > > Some users have complained that the navigation panel shows top level pages > that they don't need/want to navigate to, most importantly the XWiki page. > > There are multiple ways in which we can fix this. > > Solution 1: Content Page > > Create a top level "Content" page for user content and configure the > navigation panel to show the contents of this page. > > Pros: > * Namespace isolation (no conflicts between user pages and application > pages) > > Cons: > * The user may want to navigate to a top level application page >> (although > it's better to use the application panel for this instead) > * All the paths / references used to access the user content will start > with this "Content" page > > >>> >>> S1: This solution is good if users would work in isolation or in the evaluation period, but for team and multiple people sharing spaces, I >> don't see this as a valid solution. >>> >>> The Content space is for all users, shared. This is not about having a >>> separate space for each user. >>> >>> -0 > > Solution 2: Blacklisting > > Add support for specifying a list of (top level) pages to exclude from the > navigation panel. > > Pros: > * The user (top level) pages created later on will be visible in the > navigation panel > * The blacklist could be used to filter not only top level pages but >> also > any nested page from the navigation panel. > > Cons: > * The blacklist depends on the installed apps. The administrator may >> have > to update the blacklist when new applications are installed > * The blacklist depends on whether you view hidden pages or not. If you > don't view hidden pages then the blacklist probably contains 4 pages: Help, > Menu, Sandbox, XWiki (there is an application panel entry for each of them > except XWiki), which is manageable. If you view hidden pages then you need > to black list 28+ pages which is hard to manage and maintain. > * The filtering needs to happen on the database (otherwise we break the > pagination) so the database queries will become a bit more complex, >> which > could led to some performance penalty, depending on how long the blacklist > is. > > S2: I see the blacklist solution more as a hack for things in XWiki that should be fixed (have users outside XWiki space, move Sandbox into Help space, hide Help pages and provide a dedicated Help entry in the User >> menu, etc.) but we don't have the time to do it. -0 in an ideal state > > Solution 3: Whitelisting > > Add support for controlling the list of top level pages that are displayed > in the navigation panel. > > Pros: > * the whitelist doesn't depend on the installed extensions or hidden pages > so it's easier to maintain. > * the whitelist can be used to order the top level pages visible in the > navigation panel. > * the whitelist can be used to show at the top level (for navigation > purpose) a page that is not really a top level page > * No performance penalty > > Cons: > * The user (top level) pages created later on will not be visible in >> the > navigation panel. The administrator will have to add them to the whitelist > if they are useful for the navigation. Although creating top level >> pages > should happen less often than creating nested pages under the existing top > level pages. > * the whitelist controls only the first level in the tree. The next levels > will be dynamic (database queries) and with the default order. > S3: I prefer this solution, but with the ability to also display some dynamic pattern, something like: display X, Y and all children of Z, or all pages starting with A, or all pages created by group N :) (they are just ideas, I know some are very hard to implement). +1 > > > Solution 4: Exclude extension pages > > Exclude from the navigation panel the top level pages that belong to an > installed extension, allowing the administrator to make some exceptions > (e.g. keep the home page). The rationale is that if an installed extension > has a top level page then that page is mo
Re: [xwiki-devs] [Proposal] So which protection to we want by default for extensions pages
By "users" and "devs" you mean "basic" and advanced, right ? On Thu, May 3, 2018 at 12:11 PM, Ecaterina Moraru (Valica) wrote: > How I see this problem for extension technical pages: > - users -> EDIT right forced false. They don't see the "Edit" button, so > they are not tempted to edit. > - devs -> WARN. They should be able to modify the pages, but on their own > expense. > - admins -> WARN. They should be able to control everything, but be aware > of the risks. > > From what I see the above goes into 1b or 3. The only difference is if we > should force or not the developers to be admins and also be advanced users, > which in practice it usually happens. > > Simpler visualization of the proposal, where -ED=(EDIT right to DENY) and > W=(Warning): > > | Users | Admins | > |Basic|Advanced|Basic|Advanced| > 0 | W | W| W | W| > 1a| -ED | W| -ED || > 1b| -ED | W| W | W| > 2a| -ED | -ED | -ED | -ED | > 2b| -ED | -ED | W | W| > 3 | -ED | -ED | -ED | W| > > Thanks, > Caty > > > > On Wed, May 2, 2018 at 8:02 PM, Thomas Mortagne > wrote: > >> Right I actually forgot to list one possibility in the first mail: >> >> 0) Warning for everyone (so what we have in 10.3) >> >> On Wed, May 2, 2018 at 6:56 PM, Vincent Massol wrote: >> > Hi Thomas, >> > >> >> On 30 Apr 2018, at 14:29, Thomas Mortagne >> wrote: >> >> >> >> Hi xwikiers, >> >> >> >> In 10.3 we introduced a warning to discourage users from editing >> >> extension pages (unless the extension indicate it's OK to edit it). >> >> >> >> This was a first version to have something in 10.3 but the initial >> >> (vague) plan (for 10.4 this time) base on previous discussions was: >> >> >> >> * EDIT right forced false for basic users >> >> * still a warning for advanced users >> >> * various options to change that (EDIT right forced false for >> >> everyone, warning for everyone, etc.) >> > >> > Note: I haven’t read what’s below yet (looks complex ;)). >> > >> > From a functional POV the minimal needs IMO are: >> > >> > * The warning you’ve already implemented is good as the default >> > * We also need to take the hosting use case, where some company provide >> xwiki hosting and they want to prevent users (including admins, for >> superadmin it’s ok) from editing extension pages so that they can perform >> xwiki upgrades automatically with no conflicts. >> > >> > Ofc if we can support Advanced user vs Simple user use cases (i.e. >> forbid simple user from editing extension pages) that’s nice too but less >> important IMO. >> > >> > Thanks >> > -Vincent >> > >> >> That was before I actually look at what we can do with our security >> system :) >> >> >> >> Turns out that it's not a huge fan of dynamic criteria like >> >> "basic/advanced user", it's still possible but will require a big of >> >> work. Also since ADMIN imply EDIT forbidding basic admin to edit a >> >> protected document would not exactly be straightforward. >> >> >> >> Before starting big stuff I would like to discuss in more details what >> >> we want in the end. >> >> >> >> In this mail I would like to focus on default behavior and we can talk >> >> about which options we need to provide in another one: >> >> >> >> Note: in all of theses superdamin still have the right to edit >> >> everything (with a warning). >> >> >> >> 1) Basic/advanced based >> >> >> >> 1.a) >> >> >> >> Forced EDIT right to DENY for basic users. >> >> Edit warning for advanced users. >> >> Forced EDIT right to DENY for basic admins (we overwrite the ADMIN >> >> implied rights logic) >> >> >> >> 1.b) >> >> >> >> Forced EDIT right to DENY for basic users. >> >> Edit warning for advanced users. >> >> Edit warning for admins (they get EDIT trough ADMIN right). >> >> >> >> 2) Admin right based >> >> >> >> 2.a) >> >> >> >> Forced EDIT right to DENY for everyone >> >> Even admins >> >> >> >> 2.b) >> >> >> >> Forced EDIT right to DENY for everyone >> >> Edit warning for admins (they get EDIT trough ADMIN right). >> >> >> >> 3) Both >> >> >> >> Warning if you are both advanced user and have ADMIN right >> >> Forced EDIT right to DENY for everyone else >> >> >> >> WDYT ? >> >> >> >> The initial plan was 1.a in my mind but I'm still hesitating. 2.b is >> >> by far the easiest to implement and probably good enough but not sure >> >> having ADMIN right is the right criteria to be allowed to force edit >> >> of protected pages since it's not about security and more about >> >> knowledge. >> >> >> >> I'm -1 for 2.a) as a default. It's way too harsh for the product (but >> >> I can understand it as an option in a cloud offering for example). >> >> It's quite young and we will most probably forget to indicate that >> >> some pages are OK for edit for a little while, plus there is Contrib >> >> extensions which will probably never get configured properly because >> >> not really maintained anymore but still used. >> >> >> >> In term of refactoring/hacking to the cu
Re: [xwiki-devs] [Proposal] Solutions to hide some pages from the navigation panel
On Thu, May 3, 2018 at 1:44 PM, Vincent Massol wrote: > > > > On 3 May 2018, at 12:32, Marius Dumitru Florea < > mariusdumitru.flo...@xwiki.com> wrote: > > > > On Thu, May 3, 2018 at 11:58 AM, Ecaterina Moraru (Valica) < > > vali...@gmail.com> wrote: > > > >> On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < > >> mariusdumitru.flo...@xwiki.com> wrote: > >> > >>> Hi devs, > >>> > >>> Some users have complained that the navigation panel shows top level > >> pages > >>> that they don't need/want to navigate to, most importantly the XWiki > >> page. > >>> > >>> There are multiple ways in which we can fix this. > >>> > >>> Solution 1: Content Page > >>> > >>> Create a top level "Content" page for user content and configure the > >>> navigation panel to show the contents of this page. > >>> > >>> Pros: > >>> * Namespace isolation (no conflicts between user pages and application > >>> pages) > >>> > >>> Cons: > >>> * The user may want to navigate to a top level application page > (although > >>> it's better to use the application panel for this instead) > >>> * All the paths / references used to access the user content will start > >>> with this "Content" page > >>> > >>> > >> > > > > > >> S1: This solution is good if users would work in isolation or in the > >> evaluation period, but for team and multiple people sharing spaces, I > don't > >> see this as a valid solution. > >> > > > > The Content space is for all users, shared. This is not about having a > > separate space for each user. > > > > > >> -0 > >> > >> > >>> > >>> Solution 2: Blacklisting > >>> > >>> Add support for specifying a list of (top level) pages to exclude from > >> the > >>> navigation panel. > >>> > >>> Pros: > >>> * The user (top level) pages created later on will be visible in the > >>> navigation panel > >>> * The blacklist could be used to filter not only top level pages but > also > >>> any nested page from the navigation panel. > >>> > >>> Cons: > >>> * The blacklist depends on the installed apps. The administrator may > have > >>> to update the blacklist when new applications are installed > >>> * The blacklist depends on whether you view hidden pages or not. If you > >>> don't view hidden pages then the blacklist probably contains 4 pages: > >> Help, > >>> Menu, Sandbox, XWiki (there is an application panel entry for each of > >> them > >>> except XWiki), which is manageable. If you view hidden pages then you > >> need > >>> to black list 28+ pages which is hard to manage and maintain. > >>> * The filtering needs to happen on the database (otherwise we break the > >>> pagination) so the database queries will become a bit more complex, > which > >>> could led to some performance penalty, depending on how long the > >> blacklist > >>> is. > >>> > >>> > >> S2: I see the blacklist solution more as a hack for things in XWiki that > >> should be fixed (have users outside XWiki space, move Sandbox into Help > >> space, hide Help pages and provide a dedicated Help entry in the User > menu, > >> etc.) but we don't have the time to do it. > >> -0 in an ideal state > >> > >> > >>> > >>> Solution 3: Whitelisting > >>> > >>> Add support for controlling the list of top level pages that are > >> displayed > >>> in the navigation panel. > >>> > >>> Pros: > >>> * the whitelist doesn't depend on the installed extensions or hidden > >> pages > >>> so it's easier to maintain. > >>> * the whitelist can be used to order the top level pages visible in the > >>> navigation panel. > >>> * the whitelist can be used to show at the top level (for navigation > >>> purpose) a page that is not really a top level page > >>> * No performance penalty > >>> > >>> Cons: > >>> * The user (top level) pages created later on will not be visible in > the > >>> navigation panel. The administrator will have to add them to the > >> whitelist > >>> if they are useful for the navigation. Although creating top level > pages > >>> should happen less often than creating nested pages under the existing > >> top > >>> level pages. > >>> * the whitelist controls only the first level in the tree. The next > >> levels > >>> will be dynamic (database queries) and with the default order. > >>> > >> > >> S3: I prefer this solution, but with the ability to also display some > >> dynamic pattern, something like: display X, Y and all children of Z, or > >> all pages starting with A, or all pages created by group N :) (they are > >> just ideas, I know some are very hard to implement). > >> +1 > >> > >> > >>> > >>> > >>> Solution 4: Exclude extension pages > >>> > >>> Exclude from the navigation panel the top level pages that belong to an > >>> installed extension, allowing the administrator to make some exceptions > >>> (e.g. keep the home page). The rationale is that if an installed > >> extension > >>> has a top level page then that page is most probably the application > home > >>> page which should be accessible from the application panel. This can be > >>> implemented on top of s
Re: [xwiki-devs] [Proposal] Solutions to hide some pages from the navigation panel
Hi Caty, > On 3 May 2018, at 10:58, Ecaterina Moraru (Valica) wrote: > > On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < > mariusdumitru.flo...@xwiki.com> wrote: [snip] >> >> Solution 3: Whitelisting >> >> Add support for controlling the list of top level pages that are displayed >> in the navigation panel. >> >> Pros: >> * the whitelist doesn't depend on the installed extensions or hidden pages >> so it's easier to maintain. >> * the whitelist can be used to order the top level pages visible in the >> navigation panel. >> * the whitelist can be used to show at the top level (for navigation >> purpose) a page that is not really a top level page >> * No performance penalty >> >> Cons: >> * The user (top level) pages created later on will not be visible in the >> navigation panel. The administrator will have to add them to the whitelist >> if they are useful for the navigation. Although creating top level pages >> should happen less often than creating nested pages under the existing top >> level pages. >> * the whitelist controls only the first level in the tree. The next levels >> will be dynamic (database queries) and with the default order. >> > > S3: I prefer this solution, but with the ability to also display some > dynamic pattern, something like: display X, Y and all children of Z, or > all pages starting with A, or all pages created by group N :) (they are > just ideas, I know some are very hard to implement). > +1 [snip] > I prefer solution 3, but with the ability to sort and also to include some > dynamic parts :) is this possible? > > Thanks, > Caty FTR I don’t like solution 3 alone because I find it a bit less useful than blacklisting. If the need is to display only some known elements in the Nav, it’s already possible (not easy though ;)) to create your own Nav tree. IMO the difficulty is when users want to benefit from the automatic navigation for new pages (they’re listed by default) but they also want to control things they don’t want to see in the navigation (not because they necessarily want to hide them in the wiki for everyone to see but because it’s a navigation and they want to not display some parts that are less important - ie not provide a top level nav to them). This is why I’m advocating to have both a blacklist and a whitelist so that we can support all use cases. If this is doable technically then it’s the best solution. Now the Nav tree already has an issue: it’s very slow. So we need to fix this slowness and yet be able to filter with a whitelist and a blacklist too :) I guess it depends if we want to fix the configurability issue for good or only fix some aspects of it (ie. XWiki space, Home space, apps when they’re installed). [snip] Thanks -Vincent
Re: [xwiki-devs] [Proposal] Solutions to hide some pages from the navigation panel
> On 3 May 2018, at 12:32, Marius Dumitru Florea > wrote: > > On Thu, May 3, 2018 at 11:58 AM, Ecaterina Moraru (Valica) < > vali...@gmail.com> wrote: > >> On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < >> mariusdumitru.flo...@xwiki.com> wrote: >> >>> Hi devs, >>> >>> Some users have complained that the navigation panel shows top level >> pages >>> that they don't need/want to navigate to, most importantly the XWiki >> page. >>> >>> There are multiple ways in which we can fix this. >>> >>> Solution 1: Content Page >>> >>> Create a top level "Content" page for user content and configure the >>> navigation panel to show the contents of this page. >>> >>> Pros: >>> * Namespace isolation (no conflicts between user pages and application >>> pages) >>> >>> Cons: >>> * The user may want to navigate to a top level application page (although >>> it's better to use the application panel for this instead) >>> * All the paths / references used to access the user content will start >>> with this "Content" page >>> >>> >> > > >> S1: This solution is good if users would work in isolation or in the >> evaluation period, but for team and multiple people sharing spaces, I don't >> see this as a valid solution. >> > > The Content space is for all users, shared. This is not about having a > separate space for each user. > > >> -0 >> >> >>> >>> Solution 2: Blacklisting >>> >>> Add support for specifying a list of (top level) pages to exclude from >> the >>> navigation panel. >>> >>> Pros: >>> * The user (top level) pages created later on will be visible in the >>> navigation panel >>> * The blacklist could be used to filter not only top level pages but also >>> any nested page from the navigation panel. >>> >>> Cons: >>> * The blacklist depends on the installed apps. The administrator may have >>> to update the blacklist when new applications are installed >>> * The blacklist depends on whether you view hidden pages or not. If you >>> don't view hidden pages then the blacklist probably contains 4 pages: >> Help, >>> Menu, Sandbox, XWiki (there is an application panel entry for each of >> them >>> except XWiki), which is manageable. If you view hidden pages then you >> need >>> to black list 28+ pages which is hard to manage and maintain. >>> * The filtering needs to happen on the database (otherwise we break the >>> pagination) so the database queries will become a bit more complex, which >>> could led to some performance penalty, depending on how long the >> blacklist >>> is. >>> >>> >> S2: I see the blacklist solution more as a hack for things in XWiki that >> should be fixed (have users outside XWiki space, move Sandbox into Help >> space, hide Help pages and provide a dedicated Help entry in the User menu, >> etc.) but we don't have the time to do it. >> -0 in an ideal state >> >> >>> >>> Solution 3: Whitelisting >>> >>> Add support for controlling the list of top level pages that are >> displayed >>> in the navigation panel. >>> >>> Pros: >>> * the whitelist doesn't depend on the installed extensions or hidden >> pages >>> so it's easier to maintain. >>> * the whitelist can be used to order the top level pages visible in the >>> navigation panel. >>> * the whitelist can be used to show at the top level (for navigation >>> purpose) a page that is not really a top level page >>> * No performance penalty >>> >>> Cons: >>> * The user (top level) pages created later on will not be visible in the >>> navigation panel. The administrator will have to add them to the >> whitelist >>> if they are useful for the navigation. Although creating top level pages >>> should happen less often than creating nested pages under the existing >> top >>> level pages. >>> * the whitelist controls only the first level in the tree. The next >> levels >>> will be dynamic (database queries) and with the default order. >>> >> >> S3: I prefer this solution, but with the ability to also display some >> dynamic pattern, something like: display X, Y and all children of Z, or >> all pages starting with A, or all pages created by group N :) (they are >> just ideas, I know some are very hard to implement). >> +1 >> >> >>> >>> >>> Solution 4: Exclude extension pages >>> >>> Exclude from the navigation panel the top level pages that belong to an >>> installed extension, allowing the administrator to make some exceptions >>> (e.g. keep the home page). The rationale is that if an installed >> extension >>> has a top level page then that page is most probably the application home >>> page which should be accessible from the application panel. This can be >>> implemented on top of solution 3 (the whitelist is basically dynamic: we >>> collect the top level pages that don't belong to an extension). >>> >>> Pros: >>> * It does a clear separation between applications (accessible from the >>> application panel) and content (accessible from the navigation panel). >> The >>> navigation panel is currently mixing applic
Re: [xwiki-devs] [Proposal] Solutions to hide some pages from the navigation panel
On Thu, May 3, 2018 at 11:58 AM, Ecaterina Moraru (Valica) < vali...@gmail.com> wrote: > On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < > mariusdumitru.flo...@xwiki.com> wrote: > > > Hi devs, > > > > Some users have complained that the navigation panel shows top level > pages > > that they don't need/want to navigate to, most importantly the XWiki > page. > > > > There are multiple ways in which we can fix this. > > > > Solution 1: Content Page > > > > Create a top level "Content" page for user content and configure the > > navigation panel to show the contents of this page. > > > > Pros: > > * Namespace isolation (no conflicts between user pages and application > > pages) > > > > Cons: > > * The user may want to navigate to a top level application page (although > > it's better to use the application panel for this instead) > > * All the paths / references used to access the user content will start > > with this "Content" page > > > > > > S1: This solution is good if users would work in isolation or in the > evaluation period, but for team and multiple people sharing spaces, I don't > see this as a valid solution. > The Content space is for all users, shared. This is not about having a separate space for each user. > -0 > > > > > > Solution 2: Blacklisting > > > > Add support for specifying a list of (top level) pages to exclude from > the > > navigation panel. > > > > Pros: > > * The user (top level) pages created later on will be visible in the > > navigation panel > > * The blacklist could be used to filter not only top level pages but also > > any nested page from the navigation panel. > > > > Cons: > > * The blacklist depends on the installed apps. The administrator may have > > to update the blacklist when new applications are installed > > * The blacklist depends on whether you view hidden pages or not. If you > > don't view hidden pages then the blacklist probably contains 4 pages: > Help, > > Menu, Sandbox, XWiki (there is an application panel entry for each of > them > > except XWiki), which is manageable. If you view hidden pages then you > need > > to black list 28+ pages which is hard to manage and maintain. > > * The filtering needs to happen on the database (otherwise we break the > > pagination) so the database queries will become a bit more complex, which > > could led to some performance penalty, depending on how long the > blacklist > > is. > > > > > S2: I see the blacklist solution more as a hack for things in XWiki that > should be fixed (have users outside XWiki space, move Sandbox into Help > space, hide Help pages and provide a dedicated Help entry in the User menu, > etc.) but we don't have the time to do it. > -0 in an ideal state > > > > > > Solution 3: Whitelisting > > > > Add support for controlling the list of top level pages that are > displayed > > in the navigation panel. > > > > Pros: > > * the whitelist doesn't depend on the installed extensions or hidden > pages > > so it's easier to maintain. > > * the whitelist can be used to order the top level pages visible in the > > navigation panel. > > * the whitelist can be used to show at the top level (for navigation > > purpose) a page that is not really a top level page > > * No performance penalty > > > > Cons: > > * The user (top level) pages created later on will not be visible in the > > navigation panel. The administrator will have to add them to the > whitelist > > if they are useful for the navigation. Although creating top level pages > > should happen less often than creating nested pages under the existing > top > > level pages. > > * the whitelist controls only the first level in the tree. The next > levels > > will be dynamic (database queries) and with the default order. > > > > S3: I prefer this solution, but with the ability to also display some > dynamic pattern, something like: display X, Y and all children of Z, or > all pages starting with A, or all pages created by group N :) (they are > just ideas, I know some are very hard to implement). > +1 > > > > > > > > Solution 4: Exclude extension pages > > > > Exclude from the navigation panel the top level pages that belong to an > > installed extension, allowing the administrator to make some exceptions > > (e.g. keep the home page). The rationale is that if an installed > extension > > has a top level page then that page is most probably the application home > > page which should be accessible from the application panel. This can be > > implemented on top of solution 3 (the whitelist is basically dynamic: we > > collect the top level pages that don't belong to an extension). > > > > Pros: > > * It does a clear separation between applications (accessible from the > > application panel) and content (accessible from the navigation panel). > The > > navigation panel is currently mixing application pages and (user) content > > pages. > > * The administrator doesn't need to update the navigation panel > > configuration to exclude a top level applic
Re: [xwiki-devs] [Proposal] So which protection to we want by default for extensions pages
> On 3 May 2018, at 12:27, Ecaterina Moraru (Valica) wrote: > > It would be interesting to have an Administration configuration to ask if > extension customization are allowed or not: > - for advanced developers that want total control of their instance and > create a custom one, they would put YES and do the upgrades on their own; I’m fine with simple/advanced user but Thomas mentioned that it’s hard/dangerous to do so I’m not sure we should focus on that one FTM. > - (2a) while for Cloud/MyXWiki it would be on NO, using the applications as > they are and only manage the content. Note that it’s not just for Cloud/MyXWiki but any sane admin might want that on the xwiki instance he/she administers to forbid users from changing extension pages because he/she’ll be the one doing the upgrade and doesn’t any bad surprise to upgrade! It’s actually a sane default and the more I think about it and the more I think it should be the default (and allow admins to turn page extension editing on the first time they really need it). Thanks -Vincent > > On Thu, May 3, 2018 at 1:20 PM, Vincent Massol wrote: > >> >>> On 3 May 2018, at 12:11, Ecaterina Moraru (Valica) >> wrote: >>> >>> How I see this problem for extension technical pages: >>> - users -> EDIT right forced false. They don't see the "Edit" button, so >>> they are not tempted to edit. >>> - devs -> WARN. They should be able to modify the pages, but on their own >>> expense. >>> - admins -> WARN. They should be able to control everything, but be aware >>> of the risks. >> >> You’re forgetting the the hosting/easy upgrade use case ;) >> >> Thanks >> -Vincent >> >>> >>> From what I see the above goes into 1b or 3. The only difference is if we >>> should force or not the developers to be admins and also be advanced >> users, >>> which in practice it usually happens. >>> >>> Simpler visualization of the proposal, where -ED=(EDIT right to DENY) and >>> W=(Warning): >>> >>> | Users | Admins | >>> |Basic|Advanced|Basic|Advanced| >>> 0 | W | W| W | W| >>> 1a| -ED | W| -ED || >>> 1b| -ED | W| W | W| >>> 2a| -ED | -ED | -ED | -ED | >>> 2b| -ED | -ED | W | W| >>> 3 | -ED | -ED | -ED | W| >>> >>> Thanks, >>> Caty >>> >>> >>> >>> On Wed, May 2, 2018 at 8:02 PM, Thomas Mortagne < >> thomas.morta...@xwiki.com> >>> wrote: >>> Right I actually forgot to list one possibility in the first mail: 0) Warning for everyone (so what we have in 10.3) On Wed, May 2, 2018 at 6:56 PM, Vincent Massol >> wrote: > Hi Thomas, > >> On 30 Apr 2018, at 14:29, Thomas Mortagne wrote: >> >> Hi xwikiers, >> >> In 10.3 we introduced a warning to discourage users from editing >> extension pages (unless the extension indicate it's OK to edit it). >> >> This was a first version to have something in 10.3 but the initial >> (vague) plan (for 10.4 this time) base on previous discussions was: >> >> * EDIT right forced false for basic users >> * still a warning for advanced users >> * various options to change that (EDIT right forced false for >> everyone, warning for everyone, etc.) > > Note: I haven’t read what’s below yet (looks complex ;)). > > From a functional POV the minimal needs IMO are: > > * The warning you’ve already implemented is good as the default > * We also need to take the hosting use case, where some company provide xwiki hosting and they want to prevent users (including admins, for superadmin it’s ok) from editing extension pages so that they can >> perform xwiki upgrades automatically with no conflicts. > > Ofc if we can support Advanced user vs Simple user use cases (i.e. forbid simple user from editing extension pages) that’s nice too but >> less important IMO. > > Thanks > -Vincent > >> That was before I actually look at what we can do with our security system :) >> >> Turns out that it's not a huge fan of dynamic criteria like >> "basic/advanced user", it's still possible but will require a big of >> work. Also since ADMIN imply EDIT forbidding basic admin to edit a >> protected document would not exactly be straightforward. >> >> Before starting big stuff I would like to discuss in more details what >> we want in the end. >> >> In this mail I would like to focus on default behavior and we can talk >> about which options we need to provide in another one: >> >> Note: in all of theses superdamin still have the right to edit >> everything (with a warning). >> >> 1) Basic/advanced based >> >> 1.a) >> >> Forced EDIT right to DENY for basic users. >> Edit warning for advanced users. >> Forced EDIT right to DENY for basic admins (we overwrite the ADMIN >> implied rights logic) >>
Re: [xwiki-devs] [Proposal] Solutions to hide some pages from the navigation panel
Hi Caty, > On 3 May 2018, at 12:14, Ecaterina Moraru (Valica) wrote: > > On Thu, May 3, 2018 at 12:07 PM, Vincent Massol wrote: > >> >> >>> On 3 May 2018, at 10:58, Ecaterina Moraru (Valica) >> wrote: >>> >>> On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < >>> mariusdumitru.flo...@xwiki.com> wrote: >>> Hi devs, Some users have complained that the navigation panel shows top level >> pages that they don't need/want to navigate to, most importantly the XWiki >> page. There are multiple ways in which we can fix this. Solution 1: Content Page Create a top level "Content" page for user content and configure the navigation panel to show the contents of this page. Pros: * Namespace isolation (no conflicts between user pages and application pages) Cons: * The user may want to navigate to a top level application page >> (although it's better to use the application panel for this instead) * All the paths / references used to access the user content will start with this "Content" page >>> S1: This solution is good if users would work in isolation or in the >>> evaluation period, but for team and multiple people sharing spaces, I >> don't >>> see this as a valid solution. >>> -0 >>> >>> Solution 2: Blacklisting Add support for specifying a list of (top level) pages to exclude from >> the navigation panel. Pros: * The user (top level) pages created later on will be visible in the navigation panel * The blacklist could be used to filter not only top level pages but >> also any nested page from the navigation panel. Cons: * The blacklist depends on the installed apps. The administrator may >> have to update the blacklist when new applications are installed * The blacklist depends on whether you view hidden pages or not. If you don't view hidden pages then the blacklist probably contains 4 pages: >> Help, Menu, Sandbox, XWiki (there is an application panel entry for each of >> them except XWiki), which is manageable. If you view hidden pages then you >> need to black list 28+ pages which is hard to manage and maintain. * The filtering needs to happen on the database (otherwise we break the pagination) so the database queries will become a bit more complex, >> which could led to some performance penalty, depending on how long the >> blacklist is. >>> S2: I see the blacklist solution more as a hack for things in XWiki that >>> should be fixed (have users outside XWiki space, move Sandbox into Help >>> space, hide Help pages and provide a dedicated Help entry in the User >> menu, >>> etc.) but we don't have the time to do it. >>> -0 in an ideal state >> >> What you’re saying is that users will always want to show the full tree in >> the Navigation panel and that there are no use cases where they’ll want to >> hide some parts (that they have created). I believe that this use case >> exists. >> > > If they want to hide something, they have the Hidden pages mechanism. I’m trying to read between the lines and I guess you mean this because you assume that users will want the Navigation Panel in sync with the rest of the features of XWiki, i.e. for ex that when they search they don’t see results that don’t appear in the Nav panel, right? So you’re saying in essence that you want the Nav panel to represent exactly what the users sees in this wiki…. However if that were true, we wouldn’t be having this discussion that we have now… It’s because users want to control the navigation panel content that we’re discussing this ;) You mention below that you like the whitelist, but you’ll get exactly the same “discrepancy" issue: when you search users will find pages not listed in the nav panel! Also this is really not reasonable to say “users should use the hide page mechanism” because 1) it’ll mean those pages won’t be found in the search for example 2) it’s just impossibly hard to use to hide a full page and all its children (it works at a page level) and 3) you can hide some pages but as soon as someone adds a new page in that space, it’ll appear in the Nav Panel. So, I don’t believe they can use the Hidden pages mechanism. Do you agree? Thanks -Vincent > > >> >> This is why we need to agree about the use cases first before even >> discussing solutions! >> >> And this is why in my previous reply I’ve put what I consider to be the >> use cases we need to implement. Pasting it again here: >> >> “ >> * I believe we need to satisfy **all** the following generic use cases >> (with the whitelist taking precedence for example): >> ** Be able for the admin user to black list some nodes and children >> ** Be able for the admin user to white list some nodes and children >> “ >> >> So first let’s agree or disagree that these are real use cases we
Re: [xwiki-devs] [Proposal] So which protection to we want by default for extensions pages
It would be interesting to have an Administration configuration to ask if extension customization are allowed or not: - for advanced developers that want total control of their instance and create a custom one, they would put YES and do the upgrades on their own; - (2a) while for Cloud/MyXWiki it would be on NO, using the applications as they are and only manage the content. On Thu, May 3, 2018 at 1:20 PM, Vincent Massol wrote: > > > On 3 May 2018, at 12:11, Ecaterina Moraru (Valica) > wrote: > > > > How I see this problem for extension technical pages: > > - users -> EDIT right forced false. They don't see the "Edit" button, so > > they are not tempted to edit. > > - devs -> WARN. They should be able to modify the pages, but on their own > > expense. > > - admins -> WARN. They should be able to control everything, but be aware > > of the risks. > > You’re forgetting the the hosting/easy upgrade use case ;) > > Thanks > -Vincent > > > > > From what I see the above goes into 1b or 3. The only difference is if we > > should force or not the developers to be admins and also be advanced > users, > > which in practice it usually happens. > > > > Simpler visualization of the proposal, where -ED=(EDIT right to DENY) and > > W=(Warning): > > > > | Users | Admins | > > |Basic|Advanced|Basic|Advanced| > > 0 | W | W| W | W| > > 1a| -ED | W| -ED || > > 1b| -ED | W| W | W| > > 2a| -ED | -ED | -ED | -ED | > > 2b| -ED | -ED | W | W| > > 3 | -ED | -ED | -ED | W| > > > > Thanks, > > Caty > > > > > > > > On Wed, May 2, 2018 at 8:02 PM, Thomas Mortagne < > thomas.morta...@xwiki.com> > > wrote: > > > >> Right I actually forgot to list one possibility in the first mail: > >> > >> 0) Warning for everyone (so what we have in 10.3) > >> > >> On Wed, May 2, 2018 at 6:56 PM, Vincent Massol > wrote: > >>> Hi Thomas, > >>> > On 30 Apr 2018, at 14:29, Thomas Mortagne > >> wrote: > > Hi xwikiers, > > In 10.3 we introduced a warning to discourage users from editing > extension pages (unless the extension indicate it's OK to edit it). > > This was a first version to have something in 10.3 but the initial > (vague) plan (for 10.4 this time) base on previous discussions was: > > * EDIT right forced false for basic users > * still a warning for advanced users > * various options to change that (EDIT right forced false for > everyone, warning for everyone, etc.) > >>> > >>> Note: I haven’t read what’s below yet (looks complex ;)). > >>> > >>> From a functional POV the minimal needs IMO are: > >>> > >>> * The warning you’ve already implemented is good as the default > >>> * We also need to take the hosting use case, where some company provide > >> xwiki hosting and they want to prevent users (including admins, for > >> superadmin it’s ok) from editing extension pages so that they can > perform > >> xwiki upgrades automatically with no conflicts. > >>> > >>> Ofc if we can support Advanced user vs Simple user use cases (i.e. > >> forbid simple user from editing extension pages) that’s nice too but > less > >> important IMO. > >>> > >>> Thanks > >>> -Vincent > >>> > That was before I actually look at what we can do with our security > >> system :) > > Turns out that it's not a huge fan of dynamic criteria like > "basic/advanced user", it's still possible but will require a big of > work. Also since ADMIN imply EDIT forbidding basic admin to edit a > protected document would not exactly be straightforward. > > Before starting big stuff I would like to discuss in more details what > we want in the end. > > In this mail I would like to focus on default behavior and we can talk > about which options we need to provide in another one: > > Note: in all of theses superdamin still have the right to edit > everything (with a warning). > > 1) Basic/advanced based > > 1.a) > > Forced EDIT right to DENY for basic users. > Edit warning for advanced users. > Forced EDIT right to DENY for basic admins (we overwrite the ADMIN > implied rights logic) > > 1.b) > > Forced EDIT right to DENY for basic users. > Edit warning for advanced users. > Edit warning for admins (they get EDIT trough ADMIN right). > > 2) Admin right based > > 2.a) > > Forced EDIT right to DENY for everyone > Even admins > > 2.b) > > Forced EDIT right to DENY for everyone > Edit warning for admins (they get EDIT trough ADMIN right). > > 3) Both > > Warning if you are both advanced user and have ADMIN right > Forced EDIT right to DENY for everyone else > > WDYT ? > > The initial plan was 1.a in my mind but I'm still hesitating. 2.b is > by far the easiest to implement and probably
Re: [xwiki-devs] [Proposal] Solutions to hide some pages from the navigation panel
On Wed, May 2, 2018 at 7:24 PM, Thomas Mortagne wrote: > On Wed, May 2, 2018 at 6:02 PM, Marius Dumitru Florea > wrote: > > Hi devs, > > > > Some users have complained that the navigation panel shows top level > pages > > that they don't need/want to navigate to, most importantly the XWiki > page. > > > > There are multiple ways in which we can fix this. > > > > Solution 1: Content Page > > > > Create a top level "Content" page for user content and configure the > > navigation panel to show the contents of this page. > > > > Pros: > > * Namespace isolation (no conflicts between user pages and application > > pages) > > > > Cons: > > * The user may want to navigate to a top level application page (although > > it's better to use the application panel for this instead) > > * All the paths / references used to access the user content will start > > with this "Content" page > > > > > > Solution 2: Blacklisting > > > > Add support for specifying a list of (top level) pages to exclude from > the > > navigation panel. > > > > Pros: > > * The user (top level) pages created later on will be visible in the > > navigation panel > > * The blacklist could be used to filter not only top level pages but also > > any nested page from the navigation panel. > > > > Cons: > > * The blacklist depends on the installed apps. The administrator may have > > to update the blacklist when new applications are installed > > * The blacklist depends on whether you view hidden pages or not. If you > > don't view hidden pages then the blacklist probably contains 4 pages: > Help, > > Menu, Sandbox, XWiki (there is an application panel entry for each of > them > > except XWiki), which is manageable. If you view hidden pages then you > need > > to black list 28+ pages which is hard to manage and maintain. > > * The filtering needs to happen on the database (otherwise we break the > > pagination) so the database queries will become a bit more complex, which > > could led to some performance penalty, depending on how long the > blacklist > > is. > > > > > > Solution 3: Whitelisting > > > > Add support for controlling the list of top level pages that are > displayed > > in the navigation panel. > > > > Pros: > > * the whitelist doesn't depend on the installed extensions or hidden > pages > > so it's easier to maintain. > > * the whitelist can be used to order the top level pages visible in the > > navigation panel. > > * the whitelist can be used to show at the top level (for navigation > > purpose) a page that is not really a top level page > > * No performance penalty > > > > Cons: > > * The user (top level) pages created later on will not be visible in the > > navigation panel. The administrator will have to add them to the > whitelist > > if they are useful for the navigation. Although creating top level pages > > should happen less often than creating nested pages under the existing > top > > level pages. > > * the whitelist controls only the first level in the tree. The next > levels > > will be dynamic (database queries) and with the default order. > > > > > > Solution 4: Exclude extension pages > > > > Exclude from the navigation panel the top level pages that belong to an > > installed extension, allowing the administrator to make some exceptions > > (e.g. keep the home page). > > > Maybe a slightly better default criteria could be "extension page with > type denying edit" (which means things like Main.WebHome won't be > hidden by default). > Good point! We should do this indeed. > > The rationale is that if an installed extension > > has a top level page then that page is most probably the application home > > page which should be accessible from the application panel. This can be > > implemented on top of solution 3 (the whitelist is basically dynamic: we > > collect the top level pages that don't belong to an extension). > > > > Pros: > > * It does a clear separation between applications (accessible from the > > application panel) and content (accessible from the navigation panel). > The > > navigation panel is currently mixing application pages and (user) content > > pages. > > * The administrator doesn't need to update the navigation panel > > configuration to exclude a top level application home page each time an > > application is installed > > * The hidden top level extension code pages are not shown even when "show > > hidden pages" is set to true > > * The user top level pages created later on appear in the tree > automatically > > > > > Cons: > > * The user won't be able to navigate easily to an application home page: > > ** if the application panel is not shown > > ** or if the application doesn't provide an application panel entry > > ** or if the administrator has removed the entry from the application > panel > > > Isn't this going to be a pain for pagination too since it's based on > an information which is not stored in the database ? > Well, in this case (only for the top level) will do the pagination in Vel
Re: [xwiki-devs] [Proposal] So which protection to we want by default for extensions pages
> On 3 May 2018, at 12:11, Ecaterina Moraru (Valica) wrote: > > How I see this problem for extension technical pages: > - users -> EDIT right forced false. They don't see the "Edit" button, so > they are not tempted to edit. > - devs -> WARN. They should be able to modify the pages, but on their own > expense. > - admins -> WARN. They should be able to control everything, but be aware > of the risks. You’re forgetting the the hosting/easy upgrade use case ;) Thanks -Vincent > > From what I see the above goes into 1b or 3. The only difference is if we > should force or not the developers to be admins and also be advanced users, > which in practice it usually happens. > > Simpler visualization of the proposal, where -ED=(EDIT right to DENY) and > W=(Warning): > > | Users | Admins | > |Basic|Advanced|Basic|Advanced| > 0 | W | W| W | W| > 1a| -ED | W| -ED || > 1b| -ED | W| W | W| > 2a| -ED | -ED | -ED | -ED | > 2b| -ED | -ED | W | W| > 3 | -ED | -ED | -ED | W| > > Thanks, > Caty > > > > On Wed, May 2, 2018 at 8:02 PM, Thomas Mortagne > wrote: > >> Right I actually forgot to list one possibility in the first mail: >> >> 0) Warning for everyone (so what we have in 10.3) >> >> On Wed, May 2, 2018 at 6:56 PM, Vincent Massol wrote: >>> Hi Thomas, >>> On 30 Apr 2018, at 14:29, Thomas Mortagne >> wrote: Hi xwikiers, In 10.3 we introduced a warning to discourage users from editing extension pages (unless the extension indicate it's OK to edit it). This was a first version to have something in 10.3 but the initial (vague) plan (for 10.4 this time) base on previous discussions was: * EDIT right forced false for basic users * still a warning for advanced users * various options to change that (EDIT right forced false for everyone, warning for everyone, etc.) >>> >>> Note: I haven’t read what’s below yet (looks complex ;)). >>> >>> From a functional POV the minimal needs IMO are: >>> >>> * The warning you’ve already implemented is good as the default >>> * We also need to take the hosting use case, where some company provide >> xwiki hosting and they want to prevent users (including admins, for >> superadmin it’s ok) from editing extension pages so that they can perform >> xwiki upgrades automatically with no conflicts. >>> >>> Ofc if we can support Advanced user vs Simple user use cases (i.e. >> forbid simple user from editing extension pages) that’s nice too but less >> important IMO. >>> >>> Thanks >>> -Vincent >>> That was before I actually look at what we can do with our security >> system :) Turns out that it's not a huge fan of dynamic criteria like "basic/advanced user", it's still possible but will require a big of work. Also since ADMIN imply EDIT forbidding basic admin to edit a protected document would not exactly be straightforward. Before starting big stuff I would like to discuss in more details what we want in the end. In this mail I would like to focus on default behavior and we can talk about which options we need to provide in another one: Note: in all of theses superdamin still have the right to edit everything (with a warning). 1) Basic/advanced based 1.a) Forced EDIT right to DENY for basic users. Edit warning for advanced users. Forced EDIT right to DENY for basic admins (we overwrite the ADMIN implied rights logic) 1.b) Forced EDIT right to DENY for basic users. Edit warning for advanced users. Edit warning for admins (they get EDIT trough ADMIN right). 2) Admin right based 2.a) Forced EDIT right to DENY for everyone Even admins 2.b) Forced EDIT right to DENY for everyone Edit warning for admins (they get EDIT trough ADMIN right). 3) Both Warning if you are both advanced user and have ADMIN right Forced EDIT right to DENY for everyone else WDYT ? The initial plan was 1.a in my mind but I'm still hesitating. 2.b is by far the easiest to implement and probably good enough but not sure having ADMIN right is the right criteria to be allowed to force edit of protected pages since it's not about security and more about knowledge. I'm -1 for 2.a) as a default. It's way too harsh for the product (but I can understand it as an option in a cloud offering for example). It's quite young and we will most probably forget to indicate that some pages are OK for edit for a little while, plus there is Contrib extensions which will probably never get configured properly because not really maintained anymore but still used. In term of refactoring/hacking to the current design the most dangerous opt
Re: [xwiki-devs] [Proposal] Solutions to hide some pages from the navigation panel
On Wed, May 2, 2018 at 7:18 PM, Vincent Massol wrote: > Hi Marius, > > Thanks for working on this. > > Some general remarks/ideas. > > * I believe we need to satisfy **all** the following generic use cases > (with the whitelist taking precedence for example): > ** Be able for the admin user to black list some nodes and children > ** Be able for the admin user to white list some nodes and children > I haven't seen any user requests for these *generic* use cases. What I've seen are requests for removing from the tree *top level pages* that belong to applications: - https://forum.xwiki.org/t/release-notes-how-to-remove-it-from-navigation/494 "I have installed the cool application of “Release Notes” but I would like to have access to my Release Notes only by the Application panel and not by the Navigation menu." http://jira.xwiki.org/browse/XWIKI-12895 "This could be a field where one specifies a list of root nodes (more than one) than one would like to exclude." "The example discussed yesterday was about removing the "XWiki" space from the list (not really "content" from an end user perspective), the "Main" space (e.g. if used together with the showRoot="true" people are confused why they expand the "Home" link on the wiki and get another "Home" link inside pointing to the same page), and the "Sandbox" (as it is a playground, and not "real content" - a wiki owner might decide that "Sandbox" will linked from a separate panel, and should not be mixed with the "actual, serious content"). Another example is the "MoccaCalendar" that people might not want to see in the tree because it is already in the applications panel." "I'm looking for something like this: #set ($blacklistedSpaces = ['Main', 'AnnotationCode', 'ColorThemes', 'XWiki', 'Panels', 'Scheduler', 'Stats', 'AppWithinMinutes', 'Blog', 'Space1', 'Space2', 'Space3', 'Space4', 'Macros', 'Space5', 'Space6', 'Space7'])" - Which can be translated to: * Exclude from the navigation panel top level pages that correspond to applications accessible from the application panel * Exclude from the navigation panel application pages (non user content) The problem is at the *top level* because at the top level there are pages that the administrator doesn't "own" (cannot rename or delete safely). > * When the admin defines the black list and white list in the Admin UI, I > agree that one whitelist filter he could add is the “Don’t show top level > application pages”. However for me this is just one filter among several > that he should be able to add. In other words he could choose this white > list + some manual ones. I even agree that this whitelist could be turned > on by default. > I see where you go with this but I find it overly complicated. > * I don’t see how solution 4 alone would solve the “XWiki” space needing > to be blacklisted use case. > The "XWiki" page is provided by an extension so solution 4 will exclude it by default (unless the admin adds an exception). > > So in other words my preference from a functional POV is both solutions 2, > 3 and 4 :) > > Note that I don’t know at this point the performance cost. > > Thanks > -Vincent > > > > On 2 May 2018, at 18:02, Marius Dumitru Florea < > mariusdumitru.flo...@xwiki.com> wrote: > > > > Hi devs, > > > > Some users have complained that the navigation panel shows top level > pages > > that they don't need/want to navigate to, most importantly the XWiki > page. > > > > There are multiple ways in which we can fix this. > > > > Solution 1: Content Page > > > > Create a top level "Content" page for user content and configure the > > navigation panel to show the contents of this page. > > > > Pros: > > * Namespace isolation (no conflicts between user pages and application > > pages) > > > > Cons: > > * The user may want to navigate to a top level application page (although > > it's better to use the application panel for this instead) > > * All the paths / references used to access the user content will start > > with this "Content" page > > > > > > Solution 2: Blacklisting > > > > Add support for specifying a list of (top level) pages to exclude from > the > > navigation panel. > > > > Pros: > > * The user (top level) pages created later on will be visible in the > > navigation panel > > * The blacklist could be used to filter not only top level pages but also > > any nested page from the navigation panel. > > > > Cons: > > * The blacklist depends on the installed apps. The administrator may have > > to update the blacklist when new applications are installed > > * The blacklist depends on whether you view hidden pages or not. If you > > don't view hidden pages then the blacklist probably contains 4 pages: > Help, > > Menu, Sandbox, XWiki (there is an application panel entry for each of > them > > except XWiki), which is manageable. If you view hidden pages then you > need > > to black list 28+ pages which is hard to manage and maintain. > > * The filtering needs to happen on the datab
Re: [xwiki-devs] [Proposal] Solutions to hide some pages from the navigation panel
On Thu, May 3, 2018 at 12:07 PM, Vincent Massol wrote: > > > > On 3 May 2018, at 10:58, Ecaterina Moraru (Valica) > wrote: > > > > On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < > > mariusdumitru.flo...@xwiki.com> wrote: > > > >> Hi devs, > >> > >> Some users have complained that the navigation panel shows top level > pages > >> that they don't need/want to navigate to, most importantly the XWiki > page. > >> > >> There are multiple ways in which we can fix this. > >> > >> Solution 1: Content Page > >> > >> Create a top level "Content" page for user content and configure the > >> navigation panel to show the contents of this page. > >> > >> Pros: > >> * Namespace isolation (no conflicts between user pages and application > >> pages) > >> > >> Cons: > >> * The user may want to navigate to a top level application page > (although > >> it's better to use the application panel for this instead) > >> * All the paths / references used to access the user content will start > >> with this "Content" page > >> > >> > > S1: This solution is good if users would work in isolation or in the > > evaluation period, but for team and multiple people sharing spaces, I > don't > > see this as a valid solution. > > -0 > > > > > >> > >> Solution 2: Blacklisting > >> > >> Add support for specifying a list of (top level) pages to exclude from > the > >> navigation panel. > >> > >> Pros: > >> * The user (top level) pages created later on will be visible in the > >> navigation panel > >> * The blacklist could be used to filter not only top level pages but > also > >> any nested page from the navigation panel. > >> > >> Cons: > >> * The blacklist depends on the installed apps. The administrator may > have > >> to update the blacklist when new applications are installed > >> * The blacklist depends on whether you view hidden pages or not. If you > >> don't view hidden pages then the blacklist probably contains 4 pages: > Help, > >> Menu, Sandbox, XWiki (there is an application panel entry for each of > them > >> except XWiki), which is manageable. If you view hidden pages then you > need > >> to black list 28+ pages which is hard to manage and maintain. > >> * The filtering needs to happen on the database (otherwise we break the > >> pagination) so the database queries will become a bit more complex, > which > >> could led to some performance penalty, depending on how long the > blacklist > >> is. > >> > >> > > S2: I see the blacklist solution more as a hack for things in XWiki that > > should be fixed (have users outside XWiki space, move Sandbox into Help > > space, hide Help pages and provide a dedicated Help entry in the User > menu, > > etc.) but we don't have the time to do it. > > -0 in an ideal state > > What you’re saying is that users will always want to show the full tree in > the Navigation panel and that there are no use cases where they’ll want to > hide some parts (that they have created). I believe that this use case > exists. > If they want to hide something, they have the Hidden pages mechanism. > > This is why we need to agree about the use cases first before even > discussing solutions! > > And this is why in my previous reply I’ve put what I consider to be the > use cases we need to implement. Pasting it again here: > > “ > * I believe we need to satisfy **all** the following generic use cases > (with the whitelist taking precedence for example): > ** Be able for the admin user to black list some nodes and children > ** Be able for the admin user to white list some nodes and children > “ > > So first let’s agree or disagree that these are real use cases we need to > satisfy for a generic platform such as XWiki :) > > WDYT? > > Thanks > -Vincent > > > > >> > >> Solution 3: Whitelisting > >> > >> Add support for controlling the list of top level pages that are > displayed > >> in the navigation panel. > >> > >> Pros: > >> * the whitelist doesn't depend on the installed extensions or hidden > pages > >> so it's easier to maintain. > >> * the whitelist can be used to order the top level pages visible in the > >> navigation panel. > >> * the whitelist can be used to show at the top level (for navigation > >> purpose) a page that is not really a top level page > >> * No performance penalty > >> > >> Cons: > >> * The user (top level) pages created later on will not be visible in the > >> navigation panel. The administrator will have to add them to the > whitelist > >> if they are useful for the navigation. Although creating top level pages > >> should happen less often than creating nested pages under the existing > top > >> level pages. > >> * the whitelist controls only the first level in the tree. The next > levels > >> will be dynamic (database queries) and with the default order. > >> > > > > S3: I prefer this solution, but with the ability to also display some > > dynamic pattern, something like: display X, Y and all children of Z, or > > all pages starting with A, or all pages created by group N :)
Re: [xwiki-devs] [Proposal] So which protection to we want by default for extensions pages
How I see this problem for extension technical pages: - users -> EDIT right forced false. They don't see the "Edit" button, so they are not tempted to edit. - devs -> WARN. They should be able to modify the pages, but on their own expense. - admins -> WARN. They should be able to control everything, but be aware of the risks. >From what I see the above goes into 1b or 3. The only difference is if we should force or not the developers to be admins and also be advanced users, which in practice it usually happens. Simpler visualization of the proposal, where -ED=(EDIT right to DENY) and W=(Warning): | Users | Admins | |Basic|Advanced|Basic|Advanced| 0 | W | W| W | W| 1a| -ED | W| -ED || 1b| -ED | W| W | W| 2a| -ED | -ED | -ED | -ED | 2b| -ED | -ED | W | W| 3 | -ED | -ED | -ED | W| Thanks, Caty On Wed, May 2, 2018 at 8:02 PM, Thomas Mortagne wrote: > Right I actually forgot to list one possibility in the first mail: > > 0) Warning for everyone (so what we have in 10.3) > > On Wed, May 2, 2018 at 6:56 PM, Vincent Massol wrote: > > Hi Thomas, > > > >> On 30 Apr 2018, at 14:29, Thomas Mortagne > wrote: > >> > >> Hi xwikiers, > >> > >> In 10.3 we introduced a warning to discourage users from editing > >> extension pages (unless the extension indicate it's OK to edit it). > >> > >> This was a first version to have something in 10.3 but the initial > >> (vague) plan (for 10.4 this time) base on previous discussions was: > >> > >> * EDIT right forced false for basic users > >> * still a warning for advanced users > >> * various options to change that (EDIT right forced false for > >> everyone, warning for everyone, etc.) > > > > Note: I haven’t read what’s below yet (looks complex ;)). > > > > From a functional POV the minimal needs IMO are: > > > > * The warning you’ve already implemented is good as the default > > * We also need to take the hosting use case, where some company provide > xwiki hosting and they want to prevent users (including admins, for > superadmin it’s ok) from editing extension pages so that they can perform > xwiki upgrades automatically with no conflicts. > > > > Ofc if we can support Advanced user vs Simple user use cases (i.e. > forbid simple user from editing extension pages) that’s nice too but less > important IMO. > > > > Thanks > > -Vincent > > > >> That was before I actually look at what we can do with our security > system :) > >> > >> Turns out that it's not a huge fan of dynamic criteria like > >> "basic/advanced user", it's still possible but will require a big of > >> work. Also since ADMIN imply EDIT forbidding basic admin to edit a > >> protected document would not exactly be straightforward. > >> > >> Before starting big stuff I would like to discuss in more details what > >> we want in the end. > >> > >> In this mail I would like to focus on default behavior and we can talk > >> about which options we need to provide in another one: > >> > >> Note: in all of theses superdamin still have the right to edit > >> everything (with a warning). > >> > >> 1) Basic/advanced based > >> > >> 1.a) > >> > >> Forced EDIT right to DENY for basic users. > >> Edit warning for advanced users. > >> Forced EDIT right to DENY for basic admins (we overwrite the ADMIN > >> implied rights logic) > >> > >> 1.b) > >> > >> Forced EDIT right to DENY for basic users. > >> Edit warning for advanced users. > >> Edit warning for admins (they get EDIT trough ADMIN right). > >> > >> 2) Admin right based > >> > >> 2.a) > >> > >> Forced EDIT right to DENY for everyone > >> Even admins > >> > >> 2.b) > >> > >> Forced EDIT right to DENY for everyone > >> Edit warning for admins (they get EDIT trough ADMIN right). > >> > >> 3) Both > >> > >> Warning if you are both advanced user and have ADMIN right > >> Forced EDIT right to DENY for everyone else > >> > >> WDYT ? > >> > >> The initial plan was 1.a in my mind but I'm still hesitating. 2.b is > >> by far the easiest to implement and probably good enough but not sure > >> having ADMIN right is the right criteria to be allowed to force edit > >> of protected pages since it's not about security and more about > >> knowledge. > >> > >> I'm -1 for 2.a) as a default. It's way too harsh for the product (but > >> I can understand it as an option in a cloud offering for example). > >> It's quite young and we will most probably forget to indicate that > >> some pages are OK for edit for a little while, plus there is Contrib > >> extensions which will probably never get configured properly because > >> not really maintained anymore but still used. > >> > >> In term of refactoring/hacking to the current design the most > >> dangerous option is working around the imply link between ADMIN and > >> EDIT rights. The right system was not really designed for > >> basic/advanced criteria use case but it's OK. > >> > >> Thanks, > >> -- > >> Thomas Mortagne > > > > > > -- > Thomas Mortagne
Re: [xwiki-devs] [Proposal] Solutions to hide some pages from the navigation panel
> On 3 May 2018, at 10:58, Ecaterina Moraru (Valica) wrote: > > On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < > mariusdumitru.flo...@xwiki.com> wrote: > >> Hi devs, >> >> Some users have complained that the navigation panel shows top level pages >> that they don't need/want to navigate to, most importantly the XWiki page. >> >> There are multiple ways in which we can fix this. >> >> Solution 1: Content Page >> >> Create a top level "Content" page for user content and configure the >> navigation panel to show the contents of this page. >> >> Pros: >> * Namespace isolation (no conflicts between user pages and application >> pages) >> >> Cons: >> * The user may want to navigate to a top level application page (although >> it's better to use the application panel for this instead) >> * All the paths / references used to access the user content will start >> with this "Content" page >> >> > S1: This solution is good if users would work in isolation or in the > evaluation period, but for team and multiple people sharing spaces, I don't > see this as a valid solution. > -0 > > >> >> Solution 2: Blacklisting >> >> Add support for specifying a list of (top level) pages to exclude from the >> navigation panel. >> >> Pros: >> * The user (top level) pages created later on will be visible in the >> navigation panel >> * The blacklist could be used to filter not only top level pages but also >> any nested page from the navigation panel. >> >> Cons: >> * The blacklist depends on the installed apps. The administrator may have >> to update the blacklist when new applications are installed >> * The blacklist depends on whether you view hidden pages or not. If you >> don't view hidden pages then the blacklist probably contains 4 pages: Help, >> Menu, Sandbox, XWiki (there is an application panel entry for each of them >> except XWiki), which is manageable. If you view hidden pages then you need >> to black list 28+ pages which is hard to manage and maintain. >> * The filtering needs to happen on the database (otherwise we break the >> pagination) so the database queries will become a bit more complex, which >> could led to some performance penalty, depending on how long the blacklist >> is. >> >> > S2: I see the blacklist solution more as a hack for things in XWiki that > should be fixed (have users outside XWiki space, move Sandbox into Help > space, hide Help pages and provide a dedicated Help entry in the User menu, > etc.) but we don't have the time to do it. > -0 in an ideal state What you’re saying is that users will always want to show the full tree in the Navigation panel and that there are no use cases where they’ll want to hide some parts (that they have created). I believe that this use case exists. This is why we need to agree about the use cases first before even discussing solutions! And this is why in my previous reply I’ve put what I consider to be the use cases we need to implement. Pasting it again here: “ * I believe we need to satisfy **all** the following generic use cases (with the whitelist taking precedence for example): ** Be able for the admin user to black list some nodes and children ** Be able for the admin user to white list some nodes and children “ So first let’s agree or disagree that these are real use cases we need to satisfy for a generic platform such as XWiki :) WDYT? Thanks -Vincent > >> >> Solution 3: Whitelisting >> >> Add support for controlling the list of top level pages that are displayed >> in the navigation panel. >> >> Pros: >> * the whitelist doesn't depend on the installed extensions or hidden pages >> so it's easier to maintain. >> * the whitelist can be used to order the top level pages visible in the >> navigation panel. >> * the whitelist can be used to show at the top level (for navigation >> purpose) a page that is not really a top level page >> * No performance penalty >> >> Cons: >> * The user (top level) pages created later on will not be visible in the >> navigation panel. The administrator will have to add them to the whitelist >> if they are useful for the navigation. Although creating top level pages >> should happen less often than creating nested pages under the existing top >> level pages. >> * the whitelist controls only the first level in the tree. The next levels >> will be dynamic (database queries) and with the default order. >> > > S3: I prefer this solution, but with the ability to also display some > dynamic pattern, something like: display X, Y and all children of Z, or > all pages starting with A, or all pages created by group N :) (they are > just ideas, I know some are very hard to implement). > +1 > > >> >> >> Solution 4: Exclude extension pages >> >> Exclude from the navigation panel the top level pages that belong to an >> installed extension, allowing the administrator to make some exceptions >> (e.g. keep the home page). The rationale is that if an installed extension >> has a top level
Re: [xwiki-devs] [Proposal] Solutions to hide some pages from the navigation panel
On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < mariusdumitru.flo...@xwiki.com> wrote: > Hi devs, > > Some users have complained that the navigation panel shows top level pages > that they don't need/want to navigate to, most importantly the XWiki page. > > There are multiple ways in which we can fix this. > > Solution 1: Content Page > > Create a top level "Content" page for user content and configure the > navigation panel to show the contents of this page. > > Pros: > * Namespace isolation (no conflicts between user pages and application > pages) > > Cons: > * The user may want to navigate to a top level application page (although > it's better to use the application panel for this instead) > * All the paths / references used to access the user content will start > with this "Content" page > > S1: This solution is good if users would work in isolation or in the evaluation period, but for team and multiple people sharing spaces, I don't see this as a valid solution. -0 > > Solution 2: Blacklisting > > Add support for specifying a list of (top level) pages to exclude from the > navigation panel. > > Pros: > * The user (top level) pages created later on will be visible in the > navigation panel > * The blacklist could be used to filter not only top level pages but also > any nested page from the navigation panel. > > Cons: > * The blacklist depends on the installed apps. The administrator may have > to update the blacklist when new applications are installed > * The blacklist depends on whether you view hidden pages or not. If you > don't view hidden pages then the blacklist probably contains 4 pages: Help, > Menu, Sandbox, XWiki (there is an application panel entry for each of them > except XWiki), which is manageable. If you view hidden pages then you need > to black list 28+ pages which is hard to manage and maintain. > * The filtering needs to happen on the database (otherwise we break the > pagination) so the database queries will become a bit more complex, which > could led to some performance penalty, depending on how long the blacklist > is. > > S2: I see the blacklist solution more as a hack for things in XWiki that should be fixed (have users outside XWiki space, move Sandbox into Help space, hide Help pages and provide a dedicated Help entry in the User menu, etc.) but we don't have the time to do it. -0 in an ideal state > > Solution 3: Whitelisting > > Add support for controlling the list of top level pages that are displayed > in the navigation panel. > > Pros: > * the whitelist doesn't depend on the installed extensions or hidden pages > so it's easier to maintain. > * the whitelist can be used to order the top level pages visible in the > navigation panel. > * the whitelist can be used to show at the top level (for navigation > purpose) a page that is not really a top level page > * No performance penalty > > Cons: > * The user (top level) pages created later on will not be visible in the > navigation panel. The administrator will have to add them to the whitelist > if they are useful for the navigation. Although creating top level pages > should happen less often than creating nested pages under the existing top > level pages. > * the whitelist controls only the first level in the tree. The next levels > will be dynamic (database queries) and with the default order. > S3: I prefer this solution, but with the ability to also display some dynamic pattern, something like: display X, Y and all children of Z, or all pages starting with A, or all pages created by group N :) (they are just ideas, I know some are very hard to implement). +1 > > > Solution 4: Exclude extension pages > > Exclude from the navigation panel the top level pages that belong to an > installed extension, allowing the administrator to make some exceptions > (e.g. keep the home page). The rationale is that if an installed extension > has a top level page then that page is most probably the application home > page which should be accessible from the application panel. This can be > implemented on top of solution 3 (the whitelist is basically dynamic: we > collect the top level pages that don't belong to an extension). > > Pros: > * It does a clear separation between applications (accessible from the > application panel) and content (accessible from the navigation panel). The > navigation panel is currently mixing application pages and (user) content > pages. > * The administrator doesn't need to update the navigation panel > configuration to exclude a top level application home page each time an > application is installed > * The hidden top level extension code pages are not shown even when "show > hidden pages" is set to true > * The user top level pages created later on appear in the tree > automatically > > Cons: > * The user won't be able to navigate easily to an application home page: > ** if the application panel is not shown > ** or if the application doesn't provide an application panel entry > ** or
