Re: [xwiki-devs] [Proposal] Using JUnit5 from now on?

[Eduard Moraru]

+1 (still have to catch up on the changes in JUnit5)

For example if we need to add a method to a JUnit4 test, we convert it to
> JUnit5 and then add the new test method. It’s pretty simple to do the
> conversion.


This, however, is most likely going to be a PITA.

Thanks,
Eduard

On Wed, May 2, 2018 at 3:01 PM, Ecaterina Moraru (Valica)  wrote:

> +0
>
> Thanks,
> Caty
>
> On Wed, May 2, 2018 at 11:18 AM, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
>
> > +1
> >
> > Thanks,
> > Marius
> >
> > On Sun, Apr 29, 2018 at 3:52 PM, Vincent Massol 
> > wrote:
> >
> > > Hi devs,
> > >
> > > I’ve recently worked on converting our JUnit4 @Rule rules into JUnit5
> > > equivalent.
> > >
> > > There are now equivalent for:
> > > - MockitoComponentManagerRule,
> > > - ComponentManagerRule
> > > - AllLogRule
> > > - MockitoOldcoreRule
> > >
> > > See http://dev.xwiki.org/xwiki/bin/view/Community/Testing#
> > HJavaUnitTesting
> > > for examples of how to use them.
> > >
> > > Feel free to ask here if you have questions or if you have ideas on how
> > to
> > > better integrate with JUnit5 (I’m sure we’ll need to perform some
> tuning
> > > and there are use cases that I have forgotten that we’ll need to
> > support).
> > >
> > > I’m thus proposing that from now on, we start writing new tests as
> JUnit5
> > > tests and that we start converting old JUnit3/4 tests into JUnit5 ones.
> > For
> > > example if we need to add a method to a JUnit4 test, we convert it to
> > > JUnit5 and then add the new test method. It’s pretty simple to do the
> > > conversion.
> > >
> > > WDYT?
> > >
> > > Thanks
> > > -Vincent
> > >
> > >
> > >
> >
>

Re: [xwiki-devs] [Proposal] So which protection to we want by default for extensions pages

[Thomas Mortagne]

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

[xwiki-devs] [GSoC] Community Bonding Period ending on 14th of May. PRs needed!

[Eduard Moraru]

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

[Vincent Massol]

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

Re: [xwiki-devs] [Proposal] Solutions to hide some pages from the navigation panel

[Vincent Massol]

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

* 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 don’t see how solution 4 alone would solve the “XWiki” space needing to be 
blacklisted use case.

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

[xwiki-devs] [Proposal] Solutions to hide some pages from the navigation panel

[Marius Dumitru Florea]

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


I prefer solution 4.

WDYT?

Thanks,
Marius

Re: [xwiki-devs] [Proposal] Using JUnit5 from now on?

[Ecaterina Moraru (Valica)]

+0

Thanks,
Caty

On Wed, May 2, 2018 at 11:18 AM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> +1
>
> Thanks,
> Marius
>
> On Sun, Apr 29, 2018 at 3:52 PM, Vincent Massol 
> wrote:
>
> > Hi devs,
> >
> > I’ve recently worked on converting our JUnit4 @Rule rules into JUnit5
> > equivalent.
> >
> > There are now equivalent for:
> > - MockitoComponentManagerRule,
> > - ComponentManagerRule
> > - AllLogRule
> > - MockitoOldcoreRule
> >
> > See http://dev.xwiki.org/xwiki/bin/view/Community/Testing#
> HJavaUnitTesting
> > for examples of how to use them.
> >
> > Feel free to ask here if you have questions or if you have ideas on how
> to
> > better integrate with JUnit5 (I’m sure we’ll need to perform some tuning
> > and there are use cases that I have forgotten that we’ll need to
> support).
> >
> > I’m thus proposing that from now on, we start writing new tests as JUnit5
> > tests and that we start converting old JUnit3/4 tests into JUnit5 ones.
> For
> > example if we need to add a method to a JUnit4 test, we convert it to
> > JUnit5 and then add the new test method. It’s pretty simple to do the
> > conversion.
> >
> > WDYT?
> >
> > Thanks
> > -Vincent
> >
> >
> >
>

Re: [xwiki-devs] [Brainstorming] Roadmap Application

[Ecaterina Moraru (Valica)]

It would be a nice app.
I particularly liked the KanBan idea.

It would be great in the future to have a Development Flavor, with these
Roadmap* related apps, with JIRA integration, etc.

On Wed, May 2, 2018 at 11:54 AM, Vincent Massol  wrote:

> Hi devs,
>
> I’ve started brainstorming about the idea of a Roadmap Application at
> http://design.xwiki.org/xwiki/bin/view/Proposal/RoadmapApplication
>
> Feel free to comment/edit the page there or add your ideas here.
>
> Disclaimer: I don’t have any time to work on this ATM ;)
>
> Thanks
> -Vincent

[xwiki-devs] [Brainstorming] Roadmap Application

[Vincent Massol]

Hi devs,

I’ve started brainstorming about the idea of a Roadmap Application at 
http://design.xwiki.org/xwiki/bin/view/Proposal/RoadmapApplication

Feel free to comment/edit the page there or add your ideas here.

Disclaimer: I don’t have any time to work on this ATM ;)

Thanks
-Vincent

Re: [xwiki-devs] [Proposal] Using JUnit5 from now on?

[Marius Dumitru Florea]

+1

Thanks,
Marius

On Sun, Apr 29, 2018 at 3:52 PM, Vincent Massol  wrote:

> Hi devs,
>
> I’ve recently worked on converting our JUnit4 @Rule rules into JUnit5
> equivalent.
>
> There are now equivalent for:
> - MockitoComponentManagerRule,
> - ComponentManagerRule
> - AllLogRule
> - MockitoOldcoreRule
>
> See http://dev.xwiki.org/xwiki/bin/view/Community/Testing#HJavaUnitTesting
> for examples of how to use them.
>
> Feel free to ask here if you have questions or if you have ideas on how to
> better integrate with JUnit5 (I’m sure we’ll need to perform some tuning
> and there are use cases that I have forgotten that we’ll need to support).
>
> I’m thus proposing that from now on, we start writing new tests as JUnit5
> tests and that we start converting old JUnit3/4 tests into JUnit5 ones. For
> example if we need to add a method to a JUnit4 test, we convert it to
> JUnit5 and then add the new test method. It’s pretty simple to do the
> conversion.
>
> WDYT?
>
> Thanks
> -Vincent
>
>
>

Re: [xwiki-devs] [Proposal] Using JUnit5 from now on?

[Alex Cotiugă]

+1

Thanks,
Alex

On Mon, Apr 30, 2018 at 11:06 AM, Thomas Mortagne  wrote:

> +1, I actually started to write simple tests using Junit 5 since a
> little while (except for those that were requiring one of our custom
> rules)
>
>
> On Sun, Apr 29, 2018 at 2:52 PM, Vincent Massol 
> wrote:
> > Hi devs,
> >
> > I’ve recently worked on converting our JUnit4 @Rule rules into JUnit5
> equivalent.
> >
> > There are now equivalent for:
> > - MockitoComponentManagerRule,
> > - ComponentManagerRule
> > - AllLogRule
> > - MockitoOldcoreRule
> >
> > See http://dev.xwiki.org/xwiki/bin/view/Community/Testing#
> HJavaUnitTesting for examples of how to use them.
> >
> > Feel free to ask here if you have questions or if you have ideas on how
> to better integrate with JUnit5 (I’m sure we’ll need to perform some tuning
> and there are use cases that I have forgotten that we’ll need to support).
> >
> > I’m thus proposing that from now on, we start writing new tests as
> JUnit5 tests and that we start converting old JUnit3/4 tests into JUnit5
> ones. For example if we need to add a method to a JUnit4 test, we convert
> it to JUnit5 and then add the new test method. It’s pretty simple to do the
> conversion.
> >
> > WDYT?
> >
> > Thanks
> > -Vincent
> >
> >
>
>
>
> --
> Thomas Mortagne
>