[xwiki-devs] [ANN] XWiki 11.7 released

[Marius Dumitru Florea]

The XWiki development team is proud to announce the availability of XWiki
11.7.
This release brings a new date picker and various merge improvements.
Developers will also be able to reuse the standard color picker and the
merge API give more details about the conflicts.

You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download

Make sure to review the release notes:
https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.7

Thanks for your support
-The XWiki dev team

Re: [xwiki-devs] [Proposal] Remove XWiki.User enable property and introduce email_check property

[Marius Dumitru Florea]

+1

Thanks,
Marius

On Thu, Aug 22, 2019 at 5:01 PM Simon Urli  wrote:

> Hi everyone,
>
> I recently (in XWiki 11.6RC1) introduced a new property "enabled" in
> XWiki.User as part of https://jira.xwiki.org/browse/XWIKI-12654 to
> distinguish between inactive users (who have not confirm their
> registration with the token sent by email), and disabled users (who are
> deactivated by an admin, or by a security mechanism).
>
> Now as Marius noticed those two properties are quite redundant,
> especially when you want to know which users are really active.
> So it introduces unnecessary complexity and we might even need to change
> existing extension to check enabled users (cf the last comments on
> XWIKI-12564).
>
> So before doing those changes, I propose to fix immediately the issue by
> removing that newly introduced property and by introducing a new
> property only for assessing that users' email are checked.
>
> Then we will only have to check "active" property to check if a user is
> active or not, and we could rely on it to set them enabled or disabled
> in the admin.
> The email_check property would be used only for the check email
> mechanism, so it will avoid any confusion in the semantic.
>
> WDYT?
> Simon
>
> --
> Simon Urli
> Software Engineer at XWiki SAS
> simon.u...@xwiki.com
> More about us at http://www.xwiki.com
>

Re: [xwiki-devs] [contrib] any interest in another authenticator that deals with failed logins

[Marius Dumitru Florea]

+1 to publish it. Thanks!

On Mon, Aug 19, 2019 at 8:44 AM Clemens Klein-Robbenhaar <
robbenh...@green-meadows.de> wrote:

> Hi devs.
>
>   I noticed that the recent 11.6.x series have introduced a way to deal
> with attempts to guess a users password by introducing a strategy to
> handle repeated login failures. I should have payed attention before
> this was published because I have been implementing something similar
> because of several user requests.
>
>   Anyway, my alternative solution has been finished in parallel, and I
> wonder if there is any interest of hosting this as a contrib project.
>
> The implementation differs in the following details:
>
>   - it does not use the new AuthenticationFailureEvents and the
> introduced component API, instead it implements its own XWikiAuthService
>   - this means it works for 10.x, too (which my users are mostly running)
>   - otoh it does not work with e.g. the LDAPAuthenticator
>   - it also allows to block IPs (not that I care much about, but some
> people want this)
>   - it unblocks the user after a given time frame without having an
> Admin to intervene
>
> I guess I can migrate at least most of it into the new
> AuthenticationFailureStrategy to have a showcase for a different
> implementation, but for now it is a separate and already slightly
> outdated implementation.
>
> I think I will upload the results to e.x.o anyway (with a big note that
> this is superseded since XWiki 11.6), but is there any interest of
> hosting this as an xwiki-contrib project, maybe with the name
> 'authenticator-blocking', package 'org.xwiki.contrib.blockingauth' and
> maybe even a Jira project like 'BLOCKINGAUTH' ?
>
> Best,
> Clemens
>
>

Re: [xwiki-devs] Use the new Mail Sender API for the Share Page By Mail feature

[Marius Dumitru Florea]

Hi Gabriel,

On Fri, Aug 9, 2019 at 2:07 PM Gabriel Raileanu 
wrote:

> Hello everyone!
>
> Currently, I'm working on moving to the new Mail Sender API for share page
> by mail, which is related in XWiki-11786
> . After having some discussions
> with Vincent, we decided to include the possibility of sending the email to
> groups, related in XWiki-12112  >.
>
> Even if everything looks good for now, a problem just appeared when trying
> to access the recipient name (it's used in the email body, for addressing
> the recipient (*Hello ${recipientName}*).
> It seems like the new API it's not providing other information than the
> email address, which was confirmed by XWiki-12207
> .
>
> For now, I worked here
>  with some
> code
> from Vincent's commits
> .
>
> Also, after a few discussions with Marius, we concluded that for having the
> name of the recipient in the message, the code needs some refactoring,
> which can take a considerable amount of time.



> Another solution is to
> exclude the *recipientName *from the body of the message and keep only
> *Hello
> *(which would be a regression). This will be a shorter solution, but with
> the benefit of having the possibility to send emails to groups.
> What's your opinion on this?
>

I'm hesitating. In any case, I wouldn't remove ${recipientName} from the
mail template. I would use Velocity's silent notation and add a FIXME
comment to explain that the recipient name is not available until we fix
XWiki-12207. Plus add a comment on XWiki-12207 to remember to fix the Share
Page by email template when we close it.

There's also the small issue that the Mail Sender API expects separate
lists with users, groups and mail addresses, while on the UI we currently
have a single input and I would keep it that way, i.e. a single input that
suggests users and groups and that allows you to enter free text (mail
addresses). So we would need to split the submitted list into users, groups
and mail addresses. Not complex but something to keep in mind.


>
> Thanks a lot!
>
> Have a nice day!
> --
>  *Gabriel Răileanu*
> *Software Developer Engineer Intern*
> gabriel.raile...@xwiki.com
>

Re: [xwiki-devs] [Proposal] Best practice: tests must not output anything outside of the target directory

[Marius Dumitru Florea]

+1

On Thu, Aug 1, 2019 at 12:01 PM Vincent Massol  wrote:

> Hi Simon,
>
> > On 1 Aug 2019, at 10:43, Simon Urli  wrote:
> >
> > Hi Vincent,
> >
> > On 01/08/2019 10:35, Vincent Massol wrote:
> >> Hi devs,
> >> I was pretty sure that this was discussed before but I can’t find it so
> I’m posting it again since I noticed that we continue to have tests (and
> even add new ones) that use the OS tmp directory to output test data.
> >> Tests must not generate anything outside of the target/ directory as
> this will cause several problems:
> >> * not clean generated test data after the test
> >> * create a state that can make other tests fail
> >> * generate errors in jenkins since jenkins monitors created files and
> doesn't allow to remove files outside of the worskspace
> >> WDYT?
> >> If ok I’ll add it to
> https://dev.xwiki.org/xwiki/bin/view/Community/Testing/JavaUnitTesting/#HBestpractices
> >
> > I agree on the principle, but before adding it we need a utility method
> to know where to put those resources: I guess it would return a relative
> path to the target directory of the current module, but we need this method
> to avoid having to rely on explicit paths in our tests.
>
> Yes, I agree. I can write a junit5 extension similar to
> https://junit.org/junit5/docs/current/user-guide/#writing-tests-built-in-extensions-TempDirectory
> (this one will use the system tmp dir).
>
> > It might also allow us to clean automatically those paths in a tearDown
> method if we want.
>
> I wouldn’t do this. It’s important to leave the tmp dir present and not
> touch target/ , fro debugging purposes. In any case target lifecycle is
> already taken care of when we do a mvn clean.
>
> Thanks
> -Vincent
>
> >
> > Simon
> >> Thanks
> >> -Vincent
> >> PS: Ideally we should have a automatic verification in the build but it
> doesn’t seem easy to implement, so right now, I’m only proposing it as a
> best practice.
> >
> > --
> > Simon Urli
> > Software Engineer at XWiki SAS
> > simon.u...@xwiki.com
> > More about us at http://www.xwiki.com
>
>

Re: [xwiki-devs] [Proposal] Use an attribute whitelist for HtmlCleaner restricted mode

[Marius Dumitru Florea]

On Thu, Jul 25, 2019 at 5:33 PM Simon Urli  wrote:

> Hi Marius,
>
> On 25/07/2019 16:22, Marius Dumitru Florea wrote:
> > On Thu, Jul 25, 2019 at 11:39 AM Simon Urli 
> wrote:
> >
> >> Hi everyone,
> >>
> >> I'm currently working on improving security on XWiki comments. We
> >> already use a restricted mode in our comments but that does not cover
> >> every possible case. In order to improve it we should also filter out
> >> some part of the html when using the html  macro.
> >>
> >
> > Is the HTML macro needed in comments? Do you have a real use case for
> this?
> > Wouldn't it be more simple to completly forbid HTML and script macros in
> > comments?
>
> That's also an option, but potentially more breaking.
>
> IMO the decision was already taken a while ago with
>
> https://github.com/xwiki-contrib/syntax-markdown/commit/907dc0630a1b7cad4292c1472deb7ae4d68c66ae


I don't understand why a change in markdown syntax (contrib project) can be
considered as decision for the XWiki Project. But anyway, any decision can
be revisited.

Again, do you have a real use case where you need HTML macro in comments?


>
> which forces to use html macro with clean option when used in restricted
> mode, but does not prevent to use html macro at all. Contrary to the
> script macro which have all been disabled on the following commit:
>
> https://github.com/xwiki/xwiki-platform/commit/544d290a37cf86dff27aa7bc12be3f6a219f1508
>
> Simon
> >
> > Thanks,
> > Marius
> >
> >
> >>
> >> I propose:
> >>
> >> (a) that we use a configurable whitelist of HTML attributes that
> >> would be allowed in the output HTML: all the other attributes would be
> >> filtered out.
> >>
> >> (b) that the HTML macro is put in restricted mode for users who do
> >> not have scripting rights.
> >>
> >> For (a) I'm hesitating between a whitelist or a blacklist: I assume a
> >> blacklist would be shorter but there's also more risk of missing
> >> something. On the contrary a configurable whitelist doesn't prevent
> >> administrator to accept more than what we give in standard.
> >>
> >> A first whitelist could be (taken from:
> >>
> >>
> https://github.com/xwiki/xwiki-platform/pull/122/files#diff-c33fcb5dca86b155928768dd6e6fbf7eR146
> >> )
> >> alt, class, height, id, name, rel, scope, style, target, title, width
> >>
> >> Note that href is not included in this list for example.
> >>
> >> WDYT?
> >>
> >> Simon
> >>
> >> --
> >> Simon Urli
> >> Software Engineer at XWiki SAS
> >> simon.u...@xwiki.com
> >> More about us at http://www.xwiki.com
> >>
>
> --
> Simon Urli
> Software Engineer at XWiki SAS
> simon.u...@xwiki.com
> More about us at http://www.xwiki.com
>

Re: [xwiki-devs] [Proposal] Use an attribute whitelist for HtmlCleaner restricted mode

[Marius Dumitru Florea]

On Thu, Jul 25, 2019 at 11:39 AM Simon Urli  wrote:

> Hi everyone,
>
> I'm currently working on improving security on XWiki comments. We
> already use a restricted mode in our comments but that does not cover
> every possible case. In order to improve it we should also filter out
> some part of the html when using the html  macro.
>

Is the HTML macro needed in comments? Do you have a real use case for this?
Wouldn't it be more simple to completly forbid HTML and script macros in
comments?

Thanks,
Marius


>
> I propose:
>
>(a) that we use a configurable whitelist of HTML attributes that
> would be allowed in the output HTML: all the other attributes would be
> filtered out.
>
>(b) that the HTML macro is put in restricted mode for users who do
> not have scripting rights.
>
> For (a) I'm hesitating between a whitelist or a blacklist: I assume a
> blacklist would be shorter but there's also more risk of missing
> something. On the contrary a configurable whitelist doesn't prevent
> administrator to accept more than what we give in standard.
>
> A first whitelist could be (taken from:
>
> https://github.com/xwiki/xwiki-platform/pull/122/files#diff-c33fcb5dca86b155928768dd6e6fbf7eR146
> )
> alt, class, height, id, name, rel, scope, style, target, title, width
>
> Note that href is not included in this list for example.
>
> WDYT?
>
> Simon
>
> --
> Simon Urli
> Software Engineer at XWiki SAS
> simon.u...@xwiki.com
> More about us at http://www.xwiki.com
>

[xwiki-devs] [ANN] XWiki 11.5 released

[Marius Dumitru Florea]

The XWiki development team is proud to announce the availability of XWiki
11.5.

This release continues the work on improving concurrent editing of pages
and introduces new page and attachment pickers for macros. The code macro
gets a new layout to display line numbers. Inline editing support for wiki
macros has also been greatly improved.

You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download

Make sure to review the release notes:
https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.5

Thanks for your support
-The XWiki dev team

Re: [xwiki-devs] [Proposal] Merge on save

[Marius Dumitru Florea]

On Mon, May 27, 2019 at 5:25 PM Eduard Moraru  wrote:

> Hi,
>
> I feel we're over-engineering things a bit, at least for a fist version. My
> feeling is that the approach is to go with an UI-first version (the whole
> talk about being able to choose "mine" vs "their" versions) and only then,
> at a later point, coming back to a text-based version that allows you to
> fix the details. Why not go the other way around, in a simpler and already
> familiar (to some at least) yet flexible solution of starting with the
> text-based version, since



> we are editing wiki syntax after all?
>

Simple users that are using the WYSIWYG editor are not using the wiki
syntax directly. It's scary enough for them to see the changes (in the
History tab for instance) on wiki syntax. You now want them to fix a merge
conflict in wiki syntax? I feel it's too much.


>
> IMO, the easiest thing we could do is that, when a save is attempted, a
> merge should be attempted first. If no conflict occurs and the merge can be
> done automatically, the save should be done on the DB as well and



> the user should not perceive anything, thus not affecting his flow.
>

I don't agree. I think we should use a different **notification** message
than "Saved". I think it's useful to know that a merge was needed, even if
one could be done automatically.


>
> Note: I hope we are all on the same page when I say that the merge conflict
> resolution should target/work on wiki syntax in the UI as well.
>

If you're referring to the diffs, then yes, we don't have visual diffs ATM
(on HTML) and even if we had, a visual diff might hide some changes and
thus I don't think it would be suited for a merge conflict resolution. But
showing the wiki syntax diff and giving the (simple) user some action
buttons is definitely easier (for they) than to ask them to fix the merge
conflict by editing the wiki syntax directly.

Thanks,
Marius


>
> If, however, conflicts do occur, the save does not go to the DB. Instead:
> * If it was a save&continue, the UI should inform the user (popup/bottom
> screen notification) that the save failed because of a conflict and offer
> the possibility to keep editing or resolve the conflict
> * If it was a save&view (or if the user clicked "resolve conflict" after a
> failed save&continue), the UI should reload the (wiki) editor with the
> entire merged content that will include the conflicts in a way that is (at
> least in the first implementation) similar to how git conflicts are
> displayed in a file, i.e. clearly marked in the content (where the conflict
> starts and ends), showing your version vs the version that is currently on
> the server (in the DB). Example (with html, but imagine wiki syntax here
> and we could use something better than "HEAD", etc.):
>
> https://d33v4339jhl8k0.cloudfront.net/docs/assets/55c3b5cae4b01fdb81eb1259/images/569e7be1c697914361560809/file-AzxXs4HkkG.png
>
> An improved version (iteration) of this could then be to use something like
> CodeMirror's "merge" addon (since we already use CodeMirror in the syntax
> highlighting application). It supports 2-way or 3-way display and live diff
> computation between the versions, synchronized scrollbars, and other neat
> stuff: https://codemirror.net/demo/merge.html We could decide if in "our"
> version we include the user's original version OR if we put directly the
> merged version (where the auto-merges are already applied) OR if we have a
> button under the user's original version to perform auto-merge on request,
> leaving just the remaining conflicts to be handled by the user. Finally,
> when save&view is pressed in this mode (note: probably we need to disable
> save&continue so that the "conflict resolution" action is "atomic", i.e.
> without leaving the content in an unfinished merge state), whatever the
> edited version is will overwrite the DB version of the document (i.e. force
> with whatever it contains).
>
> WDYT?
>
> Thanks,
> Eduard
>
> On Fri, May 24, 2019 at 2:53 PM Ecaterina Moraru (Valica) <
> vali...@gmail.com>
> wrote:
>
> > On Thu, May 23, 2019 at 6:33 PM Simon Urli  wrote:
> >
> > >
> > >
> > > On 23/05/2019 16:00, Ecaterina Moraru (Valica) wrote:
> > > > On Thu, May 23, 2019 at 12:10 PM Simon Urli 
> > > wrote:
> > > >
> > > >> So trying to sum up the discussion to see if we all agree.
> > > >>
> > > >> All the above is in the case of a save conflict:
> > > >>
> > > >> 1. Default behaviour for all users is to try an automatic merge, and
> > to
> > > >> display a window conflict resolution in case of merge conflict. The
> > > >> conflict resolution is an all-or-nothing based, allowing to choose a
> > > >> version over another.
> > > >>
> > > >
> > > > I don't agree about the all-or-nothing, since I would prefer to
> accept
> > > what
> > > > we can, warn on conflicts.
> > > > We should show a resolution conflict when the conflict is on the same
> > > line.
> > > > Auto-merge the rest.
> > >
> > > Apparently I wasn't clear about my

[xwiki-devs] Fwd: [Proposal] WikiMacro inline editing: 2 new dedicated macros

[Marius Dumitru Florea]

-- Forwarded message -
From: Marius Dumitru Florea 
Date: Tue, May 21, 2019 at 1:06 PM
Subject: Re: [xwiki-devs] [Proposal] WikiMacro inline editing: 2 new
dedicated macros
To: Simon Urli 


On Mon, May 20, 2019 at 11:57 AM Simon Urli  wrote:

> Hello Marius,
>
> On 14/05/2019 13:12, Simon Urli wrote:
> >
> >
> > On 14/05/2019 13:07, Marius Dumitru Florea wrote:
> >> On Tue, May 14, 2019 at 2:04 PM Simon Urli  >> <mailto:simon.u...@xwiki.com>> wrote:
> >>
> >>
> >>
> >> On 14/05/2019 13:02, Marius Dumitru Florea wrote:
> >>  > On Tue, May 14, 2019 at 1:55 PM Simon Urli  >> <mailto:simon.u...@xwiki.com>
> >>  > <mailto:simon.u...@xwiki.com <mailto:simon.u...@xwiki.com>>>
> >> wrote:
> >>  >
> >>  >
> >>  >
> >>  > On 14/05/2019 12:43, Marius Dumitru Florea wrote:
> >>  >  > On Fri, May 10, 2019 at 11:21 AM Simon Urli
> >> mailto:simon.u...@xwiki.com>
> >>  > <mailto:simon.u...@xwiki.com <mailto:simon.u...@xwiki.com>>
> >>  >  > <mailto:simon.u...@xwiki.com <mailto:simon.u...@xwiki.com
> >
> >> <mailto:simon.u...@xwiki.com <mailto:simon.u...@xwiki.com>>>>
> wrote:
> >>  >  >
> >>  >  > Hi Marius, all,
> >>  >  >
> >>  >  > On 09/05/2019 09:29, Simon Urli wrote:
> >>  >  >  > Hi Marius, all,
> >>  >  >  >
> >>  >  >  > On 08/05/2019 14:09, Marius Dumitru Florea wrote:
> >>  >  >  >> Hi Simon,
> >>  >  >  >>
> >>  >  >  >> As I commented on
> >>  >  > https://github.com/xwiki/xwiki-platform/pull/1109 I
> >>  >  >  >> think
> >>  >  >  >> that most of the time you will want to use a
> >> scripting
> >>  > macro +
> >>  >  > HTML macro
> >>  >  >  >> like this:
> >>  >  >  >>
> >>  >  >  >> {{velocity}}
> >>  >  >  >> {{html clean="false"}}
> >>  >  >  >> 
> >>  >  >  >>...
> >>  >  >  >>
> >>  >  >  >>...
> >>  >  >  >> 
> >>  >  >  >> {{/html}}
> >>  >  >  >> {{/velocity}}
> >>  >  >  >>
> >>  >  >  >> An example of such a macro could be:
> >>  >  >  >>
> >>  >  >  >> {{figure src="someImage.png"}}some
> >> description{{/figure}}
> >>  >  >  >>
> >>  >  >  >> The macro code would look like this:
> >>  >  >  >>
> >>  >  >  >> {{velocity}}
> >>  >  >  >> {{html clean="false"}}
> >>  >  >  >> 
> >>  >  >  >>
> >>  >  >  >>  
> >>  >  >  >>
> >>  >  >  >>
> >>  >  >  >>  
> >>  >  >  >>
> >>  >  >  >> 
> >>  >  >  >> {{/html}}
> >>  >  >  >> {{/velocity}}
> >>  >  >  >>
> >>  >  >  >> I know you can output DIVs with wiki syntax but
> >> that's
> >>  > not the
> >>  >  > point. The
> >>  >  >  >> point is that we want to use HTML for the UI and
> >> leave
> >>  > the wiki
> >>  >  > syntax
> >>  >  >  >> for
> >>  >  >  >> the user content. So I don't think
> >> ``wikimacrocontent``
> >>  > is that
> >>  >  > useful
> >>  >  >  >> (if
> >>  >  >  >> it&#x

Re: [xwiki-devs] [Proposal] Roadmaps for 11.5 and 11.6

[Marius Dumitru Florea]

On Tue, May 21, 2019 at 12:23 PM Vincent Massol  wrote:

> Hi devs,
>
> Here’s a proposal for 11.5 + 11.6, discussed with Thomas, Marius and Simon
> already.
>
> XWiki 11.5
> ==
>
> * BFD: All
> * Hibernate upgrade to finish - Assignee: Thomas
> * "Finish the autocomplete of references which has been dropped since Adel
> left and we still don't have it in the WYSIWYG + implement autocomplete on
> attachments.”. - Assignee: Marius
> * Merge on Save: https://jira.xwiki.org/browse/XWIKI-175 - Assignee: Simon
>
> Dates:
> * 11.5RC1: 17 June 2019
> * 11.5: 24 June 2019
>
> XWiki 11.6
> =
>
> * BFD: All
> * Velocity upgrade (too dangerous for 11.2/11.3) - Assignee: Thomas
>


> * Security: Add permissions for xobjects to prevent giving all permissions
> to users with edit rights on a page. - Assignee: Marius (+ Thomas)?
>

Sounds good.

Thanks,
Marius


> * Limit number of login attempts until user gets blocked -
> http://jira.xwiki.org/browse/XWIKI-15488 - Assignee: Simon ?
>
> Dates:
> * 11.6RC1: 22 July 2019 (added one more week due to the XWiki SAS seminar)
> * 11.6: 29 July 2019
>
> Others
> ==
>
> The following item couldn’t be planned for 11.5 or 11.6 due to lack of
> time/manpower but we should consider it for 11.7+:
> * Better handling of user removal and transfer of rights (
> http://jira.xwiki.org/browse/XWIKI-12142 )
>
> WDYT?
>
> @devs: please confirm that you’re ok. @Simon, please let me know if it’s
> ok for the item where there’s a question mark. @Marius: same for you.
>
> @evalica: I didn’t put any investigations/designs but we should IMO. Any
> proposals?
>
> Thanks
> -Vincent
>
>

Re: [xwiki-devs] [Proposal] WikiMacro inline editing: 2 new dedicated macros

[Marius Dumitru Florea]

On Thu, May 9, 2019 at 4:15 PM Simon Urli  wrote:

> Hi,
>
> On 09/05/2019 14:52, Vincent Massol wrote:
> > Hi Simon,
> >
> >> On 9 May 2019, at 09:36, Simon Urli  wrote:
> >>
> >> Hi Vincent,
> >>
> >> On 09/05/2019 09:10, Vincent Massol wrote:
> >>> Hi Simon,
>  On 7 May 2019, at 08:21, Simon Urli  wrote:
> 
>  Hi everyone,
> 
>  I'm currently working on allowing inline editing on new wikimacros.
> >>> Why only on wikimacros? We also need to be able to edit existing
> wikimacros to make them inline-editable.
> >>
> >> of course, here I only meant that already existing macro wouldn't be
> inline editable immediately, they would require some edition for that.
> >>
>  My first challenge right now is to cope with the problem of inserting
> the macro content and allowing to inline edit it.
> 
>  In order to do so, I propose to create two new dedicated macro:
>    - wikimacrocontent: would allow to insert and inline edit a wiki
> macro content
>    - wikimacroparameter: the same for a parameter.
> 
>  The idea would be to be able to write something such as:
> 
>  {{velocity}}
>  {{wikimacrocontent/}}
>  This is a content of $xcontext.macro.content.length() characters.
>  {{/velocity}}
> >>> I don’t understand. The content is "This is a content of
> $xcontext.macro.content.length() characters.” but it’s outside of
> “{{wikimacrocontent/}}”, is this a typo?
> >>
> >> Indeed you didn't understand my example :)
> >> It was the code of the wikimacro, not the code of its usage.
> >
> > Right...
> >
> >> So if I call this macro foobar, I will execute it with something such
> as:
> >> {{foobar}}foo bar{{/foobar}}
> >>
> >> And it will ouput:
> >> foo bar
> >> This is a content of 7 characters.
> >
> > Ah yes, my bad, I mixed up the macro code content and the macro usage
> content. Indeed, I now understand that we’re trying to make changes to the
> macro usage content.
> >
> > Now we need to take into account in the design the ability to provide
> some custom mapping between what you edit and how it modifies the usage
> content.
> >
> > For example, imagine the JIRA macro when using a static list of JIRA
> issues:
> >
> > {{jira url=“…”}}
> > XWIKI-1000
> > XWIKI-1001
> > …
> > {{/jira}}
> >
> > Or Imagine the {{gallery}} macro when used with static images:
> >
> > {{gallery}}
> > img1
> > img2
> > {{/gallery}}
> >
> > In these 2 cases we’ll want some custom editors ideally and a custom
> serialization mechanism to generate back the modified content. This needs
> to be possible (pluggable) with the new APIs.
>
> Yeah I didn't mention it yet since it comes next, but it's already
> something I had in mind since Denis already has this usecase for his
> project. I need to discuss with Marius about it since it really reminds
> what has been done for the pickers, but anyway for me it should be a
> specific parameter of the macro that would be used to load a given
> widget for edition and call a script to process/transform the input to
> the expected output.
>
>

> Another thing mentioned by Denis that we should plan in the design, is
> the ability to only allow some WYSIWYG inputs for inline editing: for
> example, restricting to only inline styling, so disabling in the WYSIWYG
> editor everything's related to a new block.
>

This is already possible. See
https://github.com/xwiki-contrib/application-ckeditor/blob/master/webjar/src/main/resources/config.js#L114
. List allows everything ATM but we can introduce new "content"
types that restrict the allowed content using the allowedContent
configuration property.


> But again, for me those are features that are coming next.
>
> Simon
>
> >
> > Note that in these 2 examples I’m mentioning “static” since it’s
> possible to use Velocity script around the macro. But in this case the
> outer macro becomes the {{velocity}} macro which will be inline editable
> only as text.
> >
> > Other examples are when the macro code script parses the content and
> would like to expose only some part of it as inline editable. This requires
> a way to mark some subpart as being inline editable and a custom serializer
> to reconstruct the modified content.
> >
> >
> >> In edition the "foo bar" part will be inline editable, but not the
> "This is a content of 7 characters.".
> >> Did you mean:
> >>> {{wikimacrocontent}}
> >>> This is a content of $xcontext.macro.content.length() characters.
> >>> {{/wikimacrocontent}}
> >>> ?
>  So the purpose of those macros would be twofold:
>    1. to ease the insertion of macro content/parameters (no need to
> always use {{velocity}}$xcontext.macro.content{{/velocity}}
> >>> What is $xcontext.macro.content? I’ve never used that when writing
> wiki macros.
> >>
> >> According to the doc it's currently the standard way to access the
> macro content:
> https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/Tutorials/WritingMacros/WikiMacroTutorial/#HContent
>    2. to create the de

Re: [xwiki-devs] [Proposal] WikiMacro inline editing: 2 new dedicated macros

[Marius Dumitru Florea]

Hi Simon,

As I commented on https://github.com/xwiki/xwiki-platform/pull/1109 I think
that most of the time you will want to use a scripting macro + HTML macro
like this:

{{velocity}}
{{html clean="false"}}

  ...
  
  ...

{{/html}}
{{/velocity}}

An example of such a macro could be:

{{figure src="someImage.png"}}some description{{/figure}}

The macro code would look like this:

{{velocity}}
{{html clean="false"}}

  

  
  

  

{{/html}}
{{/velocity}}

I know you can output DIVs with wiki syntax but that's not the point. The
point is that we want to use HTML for the UI and leave the wiki syntax for
the user content. So I don't think ``wikimacrocontent`` is that useful (if
it's only purpose is to help you output the ``non-generated-content`` DIV).

Thanks,
Marius


On Tue, May 7, 2019 at 9:21 AM Simon Urli  wrote:

> Hi everyone,
>
> I'm currently working on allowing inline editing on new wikimacros.
> My first challenge right now is to cope with the problem of inserting
> the macro content and allowing to inline edit it.
>
> In order to do so, I propose to create two new dedicated macro:
>- wikimacrocontent: would allow to insert and inline edit a wiki
> macro content
>- wikimacroparameter: the same for a parameter.
>
> The idea would be to be able to write something such as:
>
> {{velocity}}
> {{wikimacrocontent/}}
> This is a content of $xcontext.macro.content.length() characters.
> {{/velocity}}
>
> So the purpose of those macros would be twofold:
>1. to ease the insertion of macro content/parameters (no need to
> always use {{velocity}}$xcontext.macro.content{{/velocity}}
>2. to create the dedicated metadata around the content and to be
> processed during wikimacro rendering to allow inline editing
>
> Of course those macro would be only to be used inside a wikimacro.
> I started to develop the wikimacroccontent, so I have a first working
> POC, but I'd like to know WDYT about this.
>
> I would also be really happy if you could give me some wikimacro
> examples where the inline editing would make sense, so I could use it in
> my tests.
>
> Thanks,
> Simon
> --
> Simon Urli
> Software Engineer at XWiki SAS
> simon.u...@xwiki.com
> More about us at http://www.xwiki.com
>

Re: [xwiki-devs] Analysis of BFD releases 11.2 and 11.3

[Marius Dumitru Florea]

On Mon, May 6, 2019 at 3:55 PM Vincent Massol  wrote:

>
>
> > On 6 May 2019, at 13:10, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
> >
> > On Mon, May 6, 2019 at 1:07 PM Vincent Massol 
> wrote:
> >
> >>
> >>
> >>> On 6 May 2019, at 11:42, Marius Dumitru Florea <
> >> mariusdumitru.flo...@xwiki.com> wrote:
> >>>
> >>> On Thu, May 2, 2019 at 12:22 PM Simon Urli 
> wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> On 02/05/2019 11:20, Thomas Mortagne wrote:
> >>>>> On Thu, May 2, 2019 at 10:57 AM Vincent Massol 
> >>>> wrote:
> >>>>>>
> >>>>>> I did a quick analysis of 11.2 & 11.3 to see how many bugs we fixed
> >>>> since they were supposed to be BFD releases.
> >>>>>>
> >>>>>> The results are not that impressive:
> >>>>>>
> >>>>>> * XWiki 11.0 (non BFD): 32 bugs closed
> >>>>>> * XWiki 11.1 (non BFD) 44 bugs closed
> >>>>>> * XWiki 11.2 (BFD): 37 bugs closed
> >>>>>> * XWiki 11.3 (BFD): 54 bugs closed
> >>>>>>
> >>>>>> Here’s the graph:
> >>>>>> https://www.evernote.com/l/AHcQ57uKyNRK-YmB09gvM70OXXVTIhFWcs0
> >>>>>>
> >>>>>> The graph shows that during the period (March and April) we had:
> >>>>>> * Created issues (128)
> >>>>>> * Resolved issues (123)
> >>>>>>
> >>>>>> So we were not even able to catch up with created bugs during the
> >>>> period.
> >>>>>>
> >>>>>> So the question is: why are we not able to catch up?
> >>>>>>
> >>>>>> Let’s look at who closed bugs during the period:
> >>>>>> https://www.evernote.com/l/AHfj3Z0DW8RAuZ0AHw9BX6cnoDZc89KPvog
> >>>>>>
> >>>>>> Top resolvers:
> >>>>>>
> >>>>>> * Simon Urli - 32
> >>>>>> * Thomas Mortagne - 30
> >>>>>> * Vincent Massol - 15
> >>>>>> * Guillaume Delhumeau - 5
> >>>>>> * Marius Dumitru Florea - 2
> >>>>>>
> >>>>>> So one reason is that we roughly have only 2 main issue resolvers
> >>>> (Simon and Thomas) and the other committers are not closing enough. So
> >> not
> >>>> enough manpower.
> >>>>>>
> >>>>>> Would be interesting to see if we have more bugs being created every
> >>>> month these days when compared to, say, 2 years ago.
> >>>>>>
> >>>>>> For ex:
> >>>>>> * category = 1 AND type = Bug and created >= 2019-03-01 and
> >> created
> >>>> <= 2019-03-31
> >>>>>> ** 70 bugs created
> >>>>>> * category = 1 AND type = Bug and created >= 2018-03-01 and
> >> created
> >>>> <= 2018-03-31
> >>>>>> ** 41 bugs created
> >>>>>> * category = 1 AND type = Bug and created >= 2017-03-01 and
> >> created
> >>>> <= 2017-03-31
> >>>>>> ** 46 bugs created
> >>>>>> * category = 1 AND type = Bug and created >= 2016-03-01 and
> >> created
> >>>> <= 2016-03-31
> >>>>>> ** 81 bugs created
> >>>>>>
> >>>>>> More generally:
> >>>>>> * category = 1 AND type = Bug and created >= 2015-01-01 and
> >> created
> >>>> <= 2015-12-31
> >>>>>> ** 780 bugs created
> >>>>>> * category = 1 AND type = Bug and created >= 2016-01-01 and
> >> created
> >>>> <= 2016-12-31
> >>>>>> ** 732 bugs created
> >>>>>> * category = 10000 AND type = Bug and created >= 2017-01-01 and
> >> created
> >>>> <= 2017-12-31
> >>>>>> ** 609 bugs created
> >>>>>> * category = 1 AND type = Bug and created >= 2019-01-01 and
> >> created
> >>>> <= 2019-12-31
> >>>>>> * 257 bugs created so far. Extrapolates to 257*3 = 771
> >>>>>>
> >>>>>> So it seems we don’t have spec

Re: [xwiki-devs] Analysis of BFD releases 11.2 and 11.3

[Marius Dumitru Florea]

And this
https://jira.xwiki.org/issues/?jql=category%20%3D%201%20AND%20issuetype%20%3D%20Bug%20AND%20status%20%3D%20Closed%20AND%20resolved%20%3E%3D%202019-03-01%20AND%20assignee%20in%20(mflorea)
shows 10 bugs for me during March and April.

On Mon, May 6, 2019 at 2:10 PM Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> On Mon, May 6, 2019 at 1:07 PM Vincent Massol  wrote:
>
>>
>>
>> > On 6 May 2019, at 11:42, Marius Dumitru Florea <
>> mariusdumitru.flo...@xwiki.com> wrote:
>> >
>> > On Thu, May 2, 2019 at 12:22 PM Simon Urli 
>> wrote:
>> >
>> >> Hi all,
>> >>
>> >> On 02/05/2019 11:20, Thomas Mortagne wrote:
>> >>> On Thu, May 2, 2019 at 10:57 AM Vincent Massol 
>> >> wrote:
>> >>>>
>> >>>> I did a quick analysis of 11.2 & 11.3 to see how many bugs we fixed
>> >> since they were supposed to be BFD releases.
>> >>>>
>> >>>> The results are not that impressive:
>> >>>>
>> >>>> * XWiki 11.0 (non BFD): 32 bugs closed
>> >>>> * XWiki 11.1 (non BFD) 44 bugs closed
>> >>>> * XWiki 11.2 (BFD): 37 bugs closed
>> >>>> * XWiki 11.3 (BFD): 54 bugs closed
>> >>>>
>> >>>> Here’s the graph:
>> >>>> https://www.evernote.com/l/AHcQ57uKyNRK-YmB09gvM70OXXVTIhFWcs0
>> >>>>
>> >>>> The graph shows that during the period (March and April) we had:
>> >>>> * Created issues (128)
>> >>>> * Resolved issues (123)
>> >>>>
>> >>>> So we were not even able to catch up with created bugs during the
>> >> period.
>> >>>>
>> >>>> So the question is: why are we not able to catch up?
>> >>>>
>> >>>> Let’s look at who closed bugs during the period:
>> >>>> https://www.evernote.com/l/AHfj3Z0DW8RAuZ0AHw9BX6cnoDZc89KPvog
>> >>>>
>> >>>> Top resolvers:
>> >>>>
>> >>>> * Simon Urli - 32
>> >>>> * Thomas Mortagne - 30
>> >>>> * Vincent Massol - 15
>> >>>> * Guillaume Delhumeau - 5
>> >>>> * Marius Dumitru Florea - 2
>> >>>>
>> >>>> So one reason is that we roughly have only 2 main issue resolvers
>> >> (Simon and Thomas) and the other committers are not closing enough. So
>> not
>> >> enough manpower.
>> >>>>
>> >>>> Would be interesting to see if we have more bugs being created every
>> >> month these days when compared to, say, 2 years ago.
>> >>>>
>> >>>> For ex:
>> >>>> * category = 1 AND type = Bug and created >= 2019-03-01 and
>> created
>> >> <= 2019-03-31
>> >>>> ** 70 bugs created
>> >>>> * category = 1 AND type = Bug and created >= 2018-03-01 and
>> created
>> >> <= 2018-03-31
>> >>>> ** 41 bugs created
>> >>>> * category = 1 AND type = Bug and created >= 2017-03-01 and
>> created
>> >> <= 2017-03-31
>> >>>> ** 46 bugs created
>> >>>> * category = 1 AND type = Bug and created >= 2016-03-01 and
>> created
>> >> <= 2016-03-31
>> >>>> ** 81 bugs created
>> >>>>
>> >>>> More generally:
>> >>>> * category = 1 AND type = Bug and created >= 2015-01-01 and
>> created
>> >> <= 2015-12-31
>> >>>> ** 780 bugs created
>> >>>> * category = 1 AND type = Bug and created >= 2016-01-01 and
>> created
>> >> <= 2016-12-31
>> >>>> ** 732 bugs created
>> >>>> * category = 1 AND type = Bug and created >= 2017-01-01 and
>> created
>> >> <= 2017-12-31
>> >>>> ** 609 bugs created
>> >>>> * category = 1 AND type = Bug and created >= 2019-01-01 and
>> created
>> >> <= 2019-12-31
>> >>>> * 257 bugs created so far. Extrapolates to 257*3 = 771
>> >>>>
>> >>>> So it seems we don’t have specifically more bugs being reported in
>> >> general.
>> >>>>
>> >>>> So it seems it’s mostly a manpower/focus issue.
>> >>>
>> >>> Yes
>> >>>
>> >>>>
>> >>>> WDYT?
>> >>
>> >>
>> >
>> >> FTR Marius was on leave for a full month during those BFD releases, so
>> >> we lost an important manpower for fixing issues then.
>> >>
>> >
>> > Besides that I also worked on fixing some CKEditor integration bugs
>> which
>> > are not counted. Not much, I counted 7 bugs, but still.
>>
>>
>
>> They’re supposed to be counted :) I’ve used “category = 1” which
>> includes bundled contrib extensions.
>>
>
> They are definitely not counted. Can you give a link to the jira filter
> you used? For instance
> https://jira.xwiki.org/issues/?jql=project%20%3D%20CKEDITOR%20AND%20issuetype%20%3D%20Bug%20AND%20status%20%3D%20Closed%20AND%20resolved%20%3E%3D%202019-03-01%20AND%20assignee%20in%20(mflorea)%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
> shows 7 bugs closed during March and April.
>
>
>>
>> Thanks
>> -Vincent
>>
>> >
>> >
>> >>
>> >>>>
>> >>>> Thanks
>> >>>> -Vincent
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >> --
>> >> Simon Urli
>> >> Software Engineer at XWiki SAS
>> >> simon.u...@xwiki.com
>> >> More about us at http://www.xwiki.com
>>
>>

Re: [xwiki-devs] Analysis of BFD releases 11.2 and 11.3

[Marius Dumitru Florea]

On Mon, May 6, 2019 at 1:07 PM Vincent Massol  wrote:

>
>
> > On 6 May 2019, at 11:42, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
> >
> > On Thu, May 2, 2019 at 12:22 PM Simon Urli  wrote:
> >
> >> Hi all,
> >>
> >> On 02/05/2019 11:20, Thomas Mortagne wrote:
> >>> On Thu, May 2, 2019 at 10:57 AM Vincent Massol 
> >> wrote:
> >>>>
> >>>> I did a quick analysis of 11.2 & 11.3 to see how many bugs we fixed
> >> since they were supposed to be BFD releases.
> >>>>
> >>>> The results are not that impressive:
> >>>>
> >>>> * XWiki 11.0 (non BFD): 32 bugs closed
> >>>> * XWiki 11.1 (non BFD) 44 bugs closed
> >>>> * XWiki 11.2 (BFD): 37 bugs closed
> >>>> * XWiki 11.3 (BFD): 54 bugs closed
> >>>>
> >>>> Here’s the graph:
> >>>> https://www.evernote.com/l/AHcQ57uKyNRK-YmB09gvM70OXXVTIhFWcs0
> >>>>
> >>>> The graph shows that during the period (March and April) we had:
> >>>> * Created issues (128)
> >>>> * Resolved issues (123)
> >>>>
> >>>> So we were not even able to catch up with created bugs during the
> >> period.
> >>>>
> >>>> So the question is: why are we not able to catch up?
> >>>>
> >>>> Let’s look at who closed bugs during the period:
> >>>> https://www.evernote.com/l/AHfj3Z0DW8RAuZ0AHw9BX6cnoDZc89KPvog
> >>>>
> >>>> Top resolvers:
> >>>>
> >>>> * Simon Urli - 32
> >>>> * Thomas Mortagne - 30
> >>>> * Vincent Massol - 15
> >>>> * Guillaume Delhumeau - 5
> >>>> * Marius Dumitru Florea - 2
> >>>>
> >>>> So one reason is that we roughly have only 2 main issue resolvers
> >> (Simon and Thomas) and the other committers are not closing enough. So
> not
> >> enough manpower.
> >>>>
> >>>> Would be interesting to see if we have more bugs being created every
> >> month these days when compared to, say, 2 years ago.
> >>>>
> >>>> For ex:
> >>>> * category = 1 AND type = Bug and created >= 2019-03-01 and
> created
> >> <= 2019-03-31
> >>>> ** 70 bugs created
> >>>> * category = 1 AND type = Bug and created >= 2018-03-01 and
> created
> >> <= 2018-03-31
> >>>> ** 41 bugs created
> >>>> * category = 1 AND type = Bug and created >= 2017-03-01 and
> created
> >> <= 2017-03-31
> >>>> ** 46 bugs created
> >>>> * category = 1 AND type = Bug and created >= 2016-03-01 and
> created
> >> <= 2016-03-31
> >>>> ** 81 bugs created
> >>>>
> >>>> More generally:
> >>>> * category = 1 AND type = Bug and created >= 2015-01-01 and
> created
> >> <= 2015-12-31
> >>>> ** 780 bugs created
> >>>> * category = 1 AND type = Bug and created >= 2016-01-01 and
> created
> >> <= 2016-12-31
> >>>> ** 732 bugs created
> >>>> * category = 1 AND type = Bug and created >= 2017-01-01 and
> created
> >> <= 2017-12-31
> >>>> ** 609 bugs created
> >>>> * category = 1 AND type = Bug and created >= 2019-01-01 and
> created
> >> <= 2019-12-31
> >>>> * 257 bugs created so far. Extrapolates to 257*3 = 771
> >>>>
> >>>> So it seems we don’t have specifically more bugs being reported in
> >> general.
> >>>>
> >>>> So it seems it’s mostly a manpower/focus issue.
> >>>
> >>> Yes
> >>>
> >>>>
> >>>> WDYT?
> >>
> >>
> >
> >> FTR Marius was on leave for a full month during those BFD releases, so
> >> we lost an important manpower for fixing issues then.
> >>
> >
> > Besides that I also worked on fixing some CKEditor integration bugs which
> > are not counted. Not much, I counted 7 bugs, but still.
>
>

> They’re supposed to be counted :) I’ve used “category = 1” which
> includes bundled contrib extensions.
>

They are definitely not counted. Can you give a link to the jira filter you
used? For instance
https://jira.xwiki.org/issues/?jql=project%20%3D%20CKEDITOR%20AND%20issuetype%20%3D%20Bug%20AND%20status%20%3D%20Closed%20AND%20resolved%20%3E%3D%202019-03-01%20AND%20assignee%20in%20(mflorea)%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
shows 7 bugs closed during March and April.


>
> Thanks
> -Vincent
>
> >
> >
> >>
> >>>>
> >>>> Thanks
> >>>> -Vincent
> >>>>
> >>>>
> >>>
> >>>
> >>
> >> --
> >> Simon Urli
> >> Software Engineer at XWiki SAS
> >> simon.u...@xwiki.com
> >> More about us at http://www.xwiki.com
>
>

Re: [xwiki-devs] Analysis of BFD releases 11.2 and 11.3

[Marius Dumitru Florea]

On Thu, May 2, 2019 at 12:22 PM Simon Urli  wrote:

> Hi all,
>
> On 02/05/2019 11:20, Thomas Mortagne wrote:
> > On Thu, May 2, 2019 at 10:57 AM Vincent Massol 
> wrote:
> >>
> >> I did a quick analysis of 11.2 & 11.3 to see how many bugs we fixed
> since they were supposed to be BFD releases.
> >>
> >> The results are not that impressive:
> >>
> >> * XWiki 11.0 (non BFD): 32 bugs closed
> >> * XWiki 11.1 (non BFD) 44 bugs closed
> >> * XWiki 11.2 (BFD): 37 bugs closed
> >> * XWiki 11.3 (BFD): 54 bugs closed
> >>
> >> Here’s the graph:
> >> https://www.evernote.com/l/AHcQ57uKyNRK-YmB09gvM70OXXVTIhFWcs0
> >>
> >> The graph shows that during the period (March and April) we had:
> >> * Created issues (128)
> >> * Resolved issues (123)
> >>
> >> So we were not even able to catch up with created bugs during the
> period.
> >>
> >> So the question is: why are we not able to catch up?
> >>
> >> Let’s look at who closed bugs during the period:
> >> https://www.evernote.com/l/AHfj3Z0DW8RAuZ0AHw9BX6cnoDZc89KPvog
> >>
> >> Top resolvers:
> >>
> >> * Simon Urli - 32
> >> * Thomas Mortagne - 30
> >> * Vincent Massol - 15
> >> * Guillaume Delhumeau - 5
> >> * Marius Dumitru Florea - 2
> >>
> >> So one reason is that we roughly have only 2 main issue resolvers
> (Simon and Thomas) and the other committers are not closing enough. So not
> enough manpower.
> >>
> >> Would be interesting to see if we have more bugs being created every
> month these days when compared to, say, 2 years ago.
> >>
> >> For ex:
> >> * category = 1 AND type = Bug and created >= 2019-03-01 and created
> <= 2019-03-31
> >> ** 70 bugs created
> >> * category = 1 AND type = Bug and created >= 2018-03-01 and created
> <= 2018-03-31
> >> ** 41 bugs created
> >> * category = 1 AND type = Bug and created >= 2017-03-01 and created
> <= 2017-03-31
> >> ** 46 bugs created
> >> * category = 1 AND type = Bug and created >= 2016-03-01 and created
> <= 2016-03-31
> >> ** 81 bugs created
> >>
> >> More generally:
> >> * category = 1 AND type = Bug and created >= 2015-01-01 and created
> <= 2015-12-31
> >> ** 780 bugs created
> >> * category = 1 AND type = Bug and created >= 2016-01-01 and created
> <= 2016-12-31
> >> ** 732 bugs created
> >> * category = 1 AND type = Bug and created >= 2017-01-01 and created
> <= 2017-12-31
> >> ** 609 bugs created
> >> * category = 1 AND type = Bug and created >= 2019-01-01 and created
> <= 2019-12-31
> >> * 257 bugs created so far. Extrapolates to 257*3 = 771
> >>
> >> So it seems we don’t have specifically more bugs being reported in
> general.
> >>
> >> So it seems it’s mostly a manpower/focus issue.
> >
> > Yes
> >
> >>
> >> WDYT?
>
>

> FTR Marius was on leave for a full month during those BFD releases, so
> we lost an important manpower for fixing issues then.
>

Besides that I also worked on fixing some CKEditor integration bugs which
are not counted. Not much, I counted 7 bugs, but still.


>
> >>
> >> Thanks
> >> -Vincent
> >>
> >>
> >
> >
>
> --
> Simon Urli
> Software Engineer at XWiki SAS
> simon.u...@xwiki.com
> More about us at http://www.xwiki.com
>

[xwiki-devs] [ANN] XWiki 11.3RC1 released

[Marius Dumitru Florea]

The XWiki development team is proud to announce the availability of XWiki
11.3RC1.
This release comes with a lot of bug fixes and a couple of small
improvements for things like the live table date filter, the Database List
field from AppWithinMinutes or the Delete User modal. There's also a new
Tomcat 9 based Debian package that you might want to try.

You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download

Make sure to review the release notes:
https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.3RC1

Thanks for your support
-The XWiki dev team

Re: [xwiki-devs] [Brainstorming] Failing build when deprecated APIs are used in scripts?

[Marius Dumitru Florea]

+1

Thanks,
Marius

On Fri, Mar 29, 2019 at 11:27 AM Vincent Massol  wrote:

> Hi devs,
>
> I'd like to discuss about introducing a checker in the tests to fail the
> test if there's a warning message about a deprecated APIs being used in
> scripts.
>
> For example:
>
> ```
> 23:59:28.308 [main] INFO  org.xwiki.test.ui.TestDebugger -
> GroupIT-addUserAndSubgroupToGroup started
> 23:59:32.593 [Exec Stream Pumper] ERROR o.x.t.i.XWikiLogOutputStream -
> 2019-03-28 23:59:32,593 [
> http://localhost:8080/xwiki/bin/view/XWiki/XWikiPreferences?xpage=getgroups&offset=1&limit=15&reqNo=1]
> WARN  o.x.v.i.DefaultVelocityEngine  - Deprecated usage of method
> [com.xpn.xwiki.plugin.rightsmanager.RightsManagerPluginApi.countAllMembersNamesForGroup]
> in 21:/templates/getgroups.vm@62,37
> 23:59:35.824 [Exec Stream Pumper] ERROR o.x.t.i.XWikiLogOutputStream -
> 2019-03-28 23:59:35,824 [
> http://localhost:8080/xwiki/bin/view/XWiki/XWikiPreferences?xpage=getgroups&offset=1&limit=15&reqNo=2]
> WARN  o.x.v.i.DefaultVelocityEngine  - Deprecated usage of method
> [com.xpn.xwiki.plugin.rightsmanager.RightsManagerPluginApi.countAllMembersNamesForGroup]
> in 18:/templates/getgroups.vm@62,37
> 23:59:41.349 [Exec Stream Pumper] ERROR o.x.t.i.XWikiLogOutputStream -
> 2019-03-28 23:59:41,348 [
> http://localhost:8080/xwiki/bin/view/XWiki/XWikiPreferences?xpage=getgroups&offset=1&limit=15&reqNo=3]
> WARN  o.x.v.i.DefaultVelocityEngine  - Deprecated usage of method
> [com.xpn.xwiki.plugin.rightsmanager.RightsManagerPluginApi.countAllMembersNamesForGroup]
> in 21:/templates/getgroups.vm@62,37
> 23:59:58.503 [main] INFO  org.xwiki.test.ui.TestDebugger -
> GroupIT-addUserAndSubgroupToGroup passed
> ```
>
> Rationale:
> * This adds warnings in the xwiki logs when users navigate to those pages
> which isn’t nice.
> * It also helps reducing the number of deprecated methods we use (I have
> the feeling this is not reducing) and helps us move towards being able to
> move the deprecated code to legacy.
>
> WDYT?
>
> Thanks
> -Vincent

Re: [xwiki-devs] [Proposal] Improve our Test Coverage strategy (TAKE 3)

[Marius Dumitru Florea]

+1

Thanks,
Marius

On Thu, Mar 21, 2019 at 7:03 PM Thomas Mortagne 
wrote:

> +1
>
> On Thu, Mar 21, 2019 at 5:41 PM Vincent Massol  wrote:
> >
> > Hi devs,
> >
> > I remember that we talked about this new global test coverage strategy
> but I don’t recall where and I couldn’t find an email about it. So I’m
> reposting the strategy that I’ve just finished implementing.
> >
> > * Every day the Clover job runs:
> https://ci.xwiki.org/view/Tools/job/Clover/
> > * It generates a global coverage report and compares it automatically
> with the first report generated for the current version
> > * If the global coverage is reduced, then:
> > ** an email is sent to notificati...@xwiki.org containing the report
> > ** the job is marked as FAILING
> > ** A failing badge is added to the job history
> > ** A red large text is added to the job page and a link to the report is
> sent
> > * Developers MUST fix the global coverage before we can release a
> version, so the it means the global coverage must not be reduced during a
> version.
> > * The RM should check the CI (already part of his chores) and the
> “Recommended Failing” view on ci.xwiki.org must not have errors or
> failures (so that includes pitest job and clover job).
> >
> > Any comments? Does that seem ok to you?
> >
> > If you confirm it’s ok, I’ll document it on
> https://dev.xwiki.org/xwiki/bin/view/Community/Testing/TestCoverage/
> >
> > Note: A few minutes ago an email has been sent since the global coverage
> has been reduced compared to yesterday.
> >
> > See
> http://maven.xwiki.org/site/clover/20190321/XWikiReport-20190320-0128-20190321-1059.html
> >
> > So we need to fix it now.
> >
> > Thanks
> > -Vincent
> >
>
>
> --
> Thomas Mortagne
>

Re: [xwiki-devs] [Proposal] Introduce a new table BackLinks for solving issues on wiki farms

[Marius Dumitru Florea]

+1, but since you're adding a new table maybe it's a good idea to have a
backlink **type** column. I'm thinking that there are multiple ways in
which 2 entities can be linked: wiki syntax link, image syntax, parameter
of a macro call, etc. Notice that I mentioned entities. Maybe we shouldn't
limit this table to wiki pages. Here's an example: you put a link to an
attachment in the value of an object property. This means the object
property is linked to the attachment.

Thanks,
Marius

Re: [xwiki-devs] [UX][Proposal] Notifications UI 11.x

[Marius Dumitru Florea]

Looks great!

On Mon, Feb 25, 2019 at 7:47 PM Ecaterina Moraru (Valica) 
wrote:

> Hi devs,
>
> http://jira.xwiki.org/browse/XWIKI-16119 wants to make the Notifications /
> Activity Stream look nicer.
>
> I've made a proposal at
> https://design.xwiki.org/xwiki/bin/view/Proposal/Notifications11x/
>
> Let me know what you think.
>
> Thanks,
> Caty
>

[xwiki-devs] [ANN] XWiki 11.1 RC1 released

[Marius Dumitru Florea]

The XWiki development team is proud to announce the availability of XWiki
11.1 RC1.
This release adds support for renaming apps created with App Within Minutes
and brings improvements to the WYSIWYG editor: inline editing of the Box
Macro title and macro category count displayed by the Macro Selector.
Advanced users can now copy the page reference from the Information tab at
the bottom of each page.

You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download

Make sure to review the release notes:
https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.1RC1/

Thanks for your support
-The XWiki dev team

Re: [xwiki-devs] [ANN] New committer: Simon Urli

[Marius Dumitru Florea]

Congrats Simon!

On Mon, Feb 11, 2019 at 10:04 AM Vincent Massol  wrote:

> Hi Devs,
>
> The XWiki committers have voted a new committer: Simon Urli.
>
> Welcome as a committer Simon :)
>
> @Simon: Congrats, and thank you for the work you’ve done so far. Keep it
> up.
>
> See https://dev.xwiki.org/xwiki/bin/view/Community/Committership
>
> We’ll add you to the various places.
>
> Thanks
> -Vincent
>
>

Re: [xwiki-devs] [Proposal] Improve our Test Coverage strategy (TAKE 3)

[Marius Dumitru Florea]

+1

Thanks,
Marius

On Sun, Feb 10, 2019 at 3:50 PM Vincent Massol  wrote:

> Hi devs,
>
> After TAKE 2 (see http://markmail.org/message/owtyhkmrz4tcbymn ),  and
> after analyzing several modules (I analyzed about 4-5 in total), I think we
> should improve a bit the strategy to make it usable and applicable.
>
> Lessons learnt
> 
>
> * It takes a lot of time to analyze a single global tpc drop (every time
> it takes me around 2 hours)
> * In general the results of the analysis are not that great. There are
> often “good enough” reasons for the drop. It’s often a lack of unit tests
> and code that is exercised by functional tests but the path has changed for
> various reasons.
> * I find the ratio of time to spend on the analysis vs result to be too
> low.
> * In the end what’s important is that our global TPC continues to grow
>
> New Strategy
> ===
>
> * We run the Clover Jenkins pipeline every night (between 11PM-8AM)
> * The pipeline sends an email whenever the new report has its global TPC
> going down when compared with the baseline (vs one or more modules had
> their TPC lowered in TAKE 2)
> * The baseline report is the report generated just after each XS release.
> This means that we keep the same baseline during a XS release
> ** Technically it means that the pipeline will update the latest.txt file
> (which contains the clover report timestamp) when it notices a version
> change
> * We add a step in the Release Plan Template to have the report passing
> before we can release.
> * The RM is in charge of a release from day 1 to the release day (already
> the case), and is also in charge of making sure that the global coverage
> job failures get addressed before the release day so that we’re ready on
> the release day.
> * Implementation detail: don’t send a failure email when there are failing
> tests in the build, to avoid false positives
>
> WDYT?
>
> Thanks
> -Vincent

Re: [xwiki-devs] Update objects on class rename

[Marius Dumitru Florea]

On Fri, Feb 8, 2019 at 4:12 PM Vincent Massol  wrote:

>
>
> > On 8 Feb 2019, at 14:00, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
> >
> > On Fri, Feb 8, 2019 at 1:51 PM Vincent Massol 
> wrote:
> >
> >>
> >>
> >>> On 8 Feb 2019, at 12:45, Marius Dumitru Florea <
> >> mariusdumitru.flo...@xwiki.com> wrote:
> >>>
> >>> On Fri, Feb 8, 2019 at 10:25 AM Vincent Massol 
> >> wrote:
> >>>
> >>>>
> >>>>
> >>>>> On 8 Feb 2019, at 09:20, Marius Dumitru Florea <
> >>>> mariusdumitru.flo...@xwiki.com> wrote:
> >>>>>
> >>>>> On Fri, Feb 8, 2019 at 9:52 AM Vincent Massol 
> >>>> wrote:
> >>>>>
> >>>>>> Hi Marius/All,
> >>>>>>
> >>>>>> See below
> >>>>>>
> >>>>>>> On 31 Jan 2019, at 11:29, Vincent Massol 
> wrote:
> >>>>>>>
> >>>>>>> Hi Marius/all,
> >>>>>>>
> >>>>>>>> On 30 Jan 2019, at 15:45, Marius Dumitru Florea <
> >>>>>> mariusdumitru.flo...@xwiki.com> wrote:
> >>>>>>>>
> >>>>>>>> Hi devs,
> >>>>>>>>
> >>>>>>>> I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need
> it
> >>>> for
> >>>>>>>> https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change
> >> the
> >>>>>> page
> >>>>>>>> rename job (from refactoring module) to update the existing
> objects
> >>>>>> when a
> >>>>>>>> class is renamed *if the "Update links" options is checked*.
> >>>>>>>>
> >>>>>>>> Of course, we could add a new option (e.g. "Update objects") but:
> >>>>>>>>
> >>>>>>>> * it complicates the rename UI (too many options)
> >>>>>>>> * I think most of the users understand the current "Update links"
> >>>>>> option as
> >>>>>>>> "update the places where this page is *used*". I don't think it
> >> makes
> >>>>>> sense
> >>>>>>>> to have separate options (at least at the UI level) for things
> like
> >>>>>> "Update
> >>>>>>>> macro calls" or "Update image includes".
> >>>>>>>> * I don't see why you would want to update the back-links but not
> >> the
> >>>>>>>> objects (or the other way around).
> >>>>>>>
> >>>>>>> Sounds good to me in general.
> >>>>>>>
> >>>>>>>> If we agree on using a single option ("Update links") then the
> next
> >>>>>>>> questions are:
> >>>>>>>>
> >>>>>>>> * Is there a better name? I think "Update links" is a good name
> for
> >>>>>> simple
> >>>>>>>> users so I would keep it. Another option is "Update references"
> but
> >> it
> >>>>>> has
> >>>>>>>> a special meaning for XWiki developers.
> >>>>>>>
> >>>>>>> Maybe "Update other pages” with a hint saying “Ensure that other
> >> pages
> >>>>>> using the renamed pages continue to work after the rename”.
> >>>>>>>
> >>>>>>> ?
> >>>>>>>
> >>>>>>>>
> >>>>>>>> * Should we update the hint for the "Update links" option? I think
> >> we
> >>>>>>>> should, but only for advanced users, since they should be aware of
> >> the
> >>>>>>>> implications of renaming a class. Simple users are not aware of
> the
> >>>>>>>> existence of objects, most probably, so I wouldn't complicate
> their
> >>>>>> lives.
> >>>>>>>
> >>>>>>> Would be nicer to find a single message that work for everyone but
> I
> >>>>>> agree it’s not easy if we wish to p

Re: [xwiki-devs] Update objects on class rename

[Marius Dumitru Florea]

On Fri, Feb 8, 2019 at 1:51 PM Vincent Massol  wrote:

>
>
> > On 8 Feb 2019, at 12:45, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
> >
> > On Fri, Feb 8, 2019 at 10:25 AM Vincent Massol 
> wrote:
> >
> >>
> >>
> >>> On 8 Feb 2019, at 09:20, Marius Dumitru Florea <
> >> mariusdumitru.flo...@xwiki.com> wrote:
> >>>
> >>> On Fri, Feb 8, 2019 at 9:52 AM Vincent Massol 
> >> wrote:
> >>>
> >>>> Hi Marius/All,
> >>>>
> >>>> See below
> >>>>
> >>>>> On 31 Jan 2019, at 11:29, Vincent Massol  wrote:
> >>>>>
> >>>>> Hi Marius/all,
> >>>>>
> >>>>>> On 30 Jan 2019, at 15:45, Marius Dumitru Florea <
> >>>> mariusdumitru.flo...@xwiki.com> wrote:
> >>>>>>
> >>>>>> Hi devs,
> >>>>>>
> >>>>>> I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need it
> >> for
> >>>>>> https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change
> the
> >>>> page
> >>>>>> rename job (from refactoring module) to update the existing objects
> >>>> when a
> >>>>>> class is renamed *if the "Update links" options is checked*.
> >>>>>>
> >>>>>> Of course, we could add a new option (e.g. "Update objects") but:
> >>>>>>
> >>>>>> * it complicates the rename UI (too many options)
> >>>>>> * I think most of the users understand the current "Update links"
> >>>> option as
> >>>>>> "update the places where this page is *used*". I don't think it
> makes
> >>>> sense
> >>>>>> to have separate options (at least at the UI level) for things like
> >>>> "Update
> >>>>>> macro calls" or "Update image includes".
> >>>>>> * I don't see why you would want to update the back-links but not
> the
> >>>>>> objects (or the other way around).
> >>>>>
> >>>>> Sounds good to me in general.
> >>>>>
> >>>>>> If we agree on using a single option ("Update links") then the next
> >>>>>> questions are:
> >>>>>>
> >>>>>> * Is there a better name? I think "Update links" is a good name for
> >>>> simple
> >>>>>> users so I would keep it. Another option is "Update references" but
> it
> >>>> has
> >>>>>> a special meaning for XWiki developers.
> >>>>>
> >>>>> Maybe "Update other pages” with a hint saying “Ensure that other
> pages
> >>>> using the renamed pages continue to work after the rename”.
> >>>>>
> >>>>> ?
> >>>>>
> >>>>>>
> >>>>>> * Should we update the hint for the "Update links" option? I think
> we
> >>>>>> should, but only for advanced users, since they should be aware of
> the
> >>>>>> implications of renaming a class. Simple users are not aware of the
> >>>>>> existence of objects, most probably, so I wouldn't complicate their
> >>>> lives.
> >>>>>
> >>>>> Would be nicer to find a single message that work for everyone but I
> >>>> agree it’s not easy if we wish to provide details.
> >>>>>
> >>>>> I feel a nicer option would be to NOT show “Update other pages” for
> >>>> simple users since that should always be checked. Only offer the
> >> ability to
> >>>> uncheck it for advanced users and this solves the hint issue too :)
> >>>>
> >>>>
> >>>
> >>>> Nobody replied to this proposal but I really find it the best by far
> and
> >>>> it solves your other questions too while making the UI simpler
> globally.
> >>>>
> >>>
> >>> The only issue I see with this option is that by hiding the "Update
> >> Links"
> >>> the simple users might not be aware of the side effects of the rename
> >>> operation: the fact that other pages will have to be updated

Re: [xwiki-devs] Update objects on class rename

[Marius Dumitru Florea]

On Fri, Feb 8, 2019 at 10:25 AM Vincent Massol  wrote:

>
>
> > On 8 Feb 2019, at 09:20, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
> >
> > On Fri, Feb 8, 2019 at 9:52 AM Vincent Massol 
> wrote:
> >
> >> Hi Marius/All,
> >>
> >> See below
> >>
> >>> On 31 Jan 2019, at 11:29, Vincent Massol  wrote:
> >>>
> >>> Hi Marius/all,
> >>>
> >>>> On 30 Jan 2019, at 15:45, Marius Dumitru Florea <
> >> mariusdumitru.flo...@xwiki.com> wrote:
> >>>>
> >>>> Hi devs,
> >>>>
> >>>> I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need it
> for
> >>>> https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change the
> >> page
> >>>> rename job (from refactoring module) to update the existing objects
> >> when a
> >>>> class is renamed *if the "Update links" options is checked*.
> >>>>
> >>>> Of course, we could add a new option (e.g. "Update objects") but:
> >>>>
> >>>> * it complicates the rename UI (too many options)
> >>>> * I think most of the users understand the current "Update links"
> >> option as
> >>>> "update the places where this page is *used*". I don't think it makes
> >> sense
> >>>> to have separate options (at least at the UI level) for things like
> >> "Update
> >>>> macro calls" or "Update image includes".
> >>>> * I don't see why you would want to update the back-links but not the
> >>>> objects (or the other way around).
> >>>
> >>> Sounds good to me in general.
> >>>
> >>>> If we agree on using a single option ("Update links") then the next
> >>>> questions are:
> >>>>
> >>>> * Is there a better name? I think "Update links" is a good name for
> >> simple
> >>>> users so I would keep it. Another option is "Update references" but it
> >> has
> >>>> a special meaning for XWiki developers.
> >>>
> >>> Maybe "Update other pages” with a hint saying “Ensure that other pages
> >> using the renamed pages continue to work after the rename”.
> >>>
> >>> ?
> >>>
> >>>>
> >>>> * Should we update the hint for the "Update links" option? I think we
> >>>> should, but only for advanced users, since they should be aware of the
> >>>> implications of renaming a class. Simple users are not aware of the
> >>>> existence of objects, most probably, so I wouldn't complicate their
> >> lives.
> >>>
> >>> Would be nicer to find a single message that work for everyone but I
> >> agree it’s not easy if we wish to provide details.
> >>>
> >>> I feel a nicer option would be to NOT show “Update other pages” for
> >> simple users since that should always be checked. Only offer the
> ability to
> >> uncheck it for advanced users and this solves the hint issue too :)
> >>
> >>
> >
> >> Nobody replied to this proposal but I really find it the best by far and
> >> it solves your other questions too while making the UI simpler globally.
> >>
> >
> > The only issue I see with this option is that by hiding the "Update
> Links"
> > the simple users might not be aware of the side effects of the rename
> > operation: the fact that other pages will have to be updated. Seeing
> that a
> > page you want to rename is referenced in many places can make you think
> > twice about the rename.
>
>

> We could keep that info, it could be useful indeed.
>

I can keep the message but then I'll probably need to display different
messages for simple and advanced users. Moreover, ideally the message
should be updated whenever the Preserve Children checkbox is clicked (e.g.
to indicate that there are more pages to update if the child pages are
preserved).


>
> I was referring to hiding the option (the checkbox). This makes the UI
> simpler to use for simple user, which is the direction we want to go and I
> cannot find tons of reasons why simple users would want to not fix links…
> Actually in the past all issues that were raised were the opposite, users
> who didn’t check the box, and then we made it checked by default.
>
> > Now, the current hint for "Update Links" doesn't indicate all the side
> > effects. For instance it indicates the number of back-links to the page
> > you're trying to rename but it *doesn't include back-links to child
> pages*
> > (when child pages are preserved). So what I said above it not really true
> > ATM either.
>
> Yes, it’s actually worse in a sense :) Right now it makes it seem as if
> it’ll work perfectly well…
>
> Thanks
> -Vincent
>
> >
> > Thanks,
> > Marius
> >
> >
> >>
> >> WDYT?
> >>
> >> Thanks
> >> -Vincent
> >>
> >> [snip]
>
>

Re: [xwiki-devs] Update objects on class rename

[Marius Dumitru Florea]

On Fri, Feb 8, 2019 at 9:52 AM Vincent Massol  wrote:

> Hi Marius/All,
>
> See below
>
> > On 31 Jan 2019, at 11:29, Vincent Massol  wrote:
> >
> > Hi Marius/all,
> >
> >> On 30 Jan 2019, at 15:45, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
> >>
> >> Hi devs,
> >>
> >> I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need it for
> >> https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change the
> page
> >> rename job (from refactoring module) to update the existing objects
> when a
> >> class is renamed *if the "Update links" options is checked*.
> >>
> >> Of course, we could add a new option (e.g. "Update objects") but:
> >>
> >> * it complicates the rename UI (too many options)
> >> * I think most of the users understand the current "Update links"
> option as
> >> "update the places where this page is *used*". I don't think it makes
> sense
> >> to have separate options (at least at the UI level) for things like
> "Update
> >> macro calls" or "Update image includes".
> >> * I don't see why you would want to update the back-links but not the
> >> objects (or the other way around).
> >
> > Sounds good to me in general.
> >
> >> If we agree on using a single option ("Update links") then the next
> >> questions are:
> >>
> >> * Is there a better name? I think "Update links" is a good name for
> simple
> >> users so I would keep it. Another option is "Update references" but it
> has
> >> a special meaning for XWiki developers.
> >
> > Maybe "Update other pages” with a hint saying “Ensure that other pages
> using the renamed pages continue to work after the rename”.
> >
> > ?
> >
> >>
> >> * Should we update the hint for the "Update links" option? I think we
> >> should, but only for advanced users, since they should be aware of the
> >> implications of renaming a class. Simple users are not aware of the
> >> existence of objects, most probably, so I wouldn't complicate their
> lives.
> >
> > Would be nicer to find a single message that work for everyone but I
> agree it’s not easy if we wish to provide details.
> >
> > I feel a nicer option would be to NOT show “Update other pages” for
> simple users since that should always be checked. Only offer the ability to
> uncheck it for advanced users and this solves the hint issue too :)
>
>

> Nobody replied to this proposal but I really find it the best by far and
> it solves your other questions too while making the UI simpler globally.
>

The only issue I see with this option is that by hiding the "Update Links"
the simple users might not be aware of the side effects of the rename
operation: the fact that other pages will have to be updated. Seeing that a
page you want to rename is referenced in many places can make you think
twice about the rename.

Now, the current hint for "Update Links" doesn't indicate all the side
effects. For instance it indicates the number of back-links to the page
you're trying to rename but it *doesn't include back-links to child pages*
(when child pages are preserved). So what I said above it not really true
ATM either.

Thanks,
Marius


>
> WDYT?
>
> Thanks
> -Vincent
>
> [snip]
>
>

Re: [xwiki-devs] [Proposal] Get rid of Activity Stream and the Watchlist

[Marius Dumitru Florea]

+1

Thanks,
Marius

On Mon, Feb 4, 2019 at 1:50 PM Guillaume Delhumeau <
guillaume.delhum...@xwiki.com> wrote:

> Dear developers,
>
> Now that we consider notifications as an achieved replacement for both
> Activity Stream and the Watchlist, I propose to stop maintaining them and
> to move them into the "attic" section.
>
> You need to know that we had a dependency on the Activity Stream API, as
> the only implementation of the Event Stream, on which the Notifications are
> based. So to get rid of this dependency (the code is not using our
> component system and is not well tested), I have written a new
> implementation of the Event Stream that I have called "Event Stream Store".
> It's fully backward compatible with the old implementation, since it is
> using the same Database schema. In practice, I re-used some pieces of
> Activity Stream that I have modified to fit into components. For more
> information, see: https://jira.xwiki.org/browse/XWIKI-16052
>
> So my proposal is this one:
> - use the new store in 11.1
> - stop bundle Watchlist and AS in 11.1
> - move Watchlist and AS into "attic" in 11.2
>
> Thanks you,
>
> --
> Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
> Research & Development Engineer at XWiki SAS
> Committer on the XWiki.org project
>

Re: [xwiki-devs] [Proposal] Do not write pure-developer release notes

[Marius Dumitru Florea]

Yes, it looks nice, but SonarQube is a different kind of product. I don't
think it's a development platform like us..

On Wed, Jan 30, 2019 at 6:41 PM Vincent Massol  wrote:

> BTW I really like the quality of the SonarQube release notes:
> * Not too much (nobody reads when there’s too much)
> * Only document important highlights and make the RN nice for them (nice
> screenshots, nice doc)
>
> https://www.sonarqube.org/sonarqube-7-6/
>
> WDYT?
>
> Thanks
> -Vincent
>
> > On 25 Jan 2019, at 09:31, Vincent Massol  wrote:
> >
> > Hi devs,
> >
> > Context
> > ===
> >
> > It’s been since we’ve deviated from the original purpose of the Release
> Notes by also adding developer-oriented release notes.
> >
> > The goal of the Release Notes was to **highlight** important novelties
> for our **users**, because looking at the JIRA list is too technical
> (otherwise we could simply use the Release feature of JIRA! :)).
> >
> > So you may ask why we do have a “Developer” Category in the RN app.
> These were not for pure developers but for XWiki users who are more
> advanced and can write scripts in wiki pages. And when it’s the case we
> **must** add examples, otherwise, it’s completely useless.
> >
> > For example this morning I saw this RN added:
> >
> https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.0/Change004/
> >
> > This is typically something that has very little value to me:
> > * It’s for pure developers (java devs)
> > * It’s not understandable by anyone except the person who coded it or
> participated to the dev mailing list discussion about it
> > * It doesn’t say more than what’s in the JIRA issue so what’s the point?
> > * There are no examples at all in it!
> > * Real developers can simply look at the reference documentation or can
> read the JIRAs. We always link the JIRA issues in the RN anyway (it was for
> this reason that we’re listing them).
> > * It takes time to write RN items and thus it needs to have high value
> >
> > Proposal
> > 
> >
> > * Go back to the original idea and only list developer RN items when
> they are for scripting users and not APIs. For example, document some new
> script service or some additions to existing script services. Of course
> Groovy would allow you to call any API so being able to use it from Groovy
> is not a good criteria. I’d say that the criteria should be whether the
> Release Note Change is useful for Velocity users.
> > * Rename “Developers” into “Scripters” or or “Advanced Users” (any
> better name?)
> > * Always put an example when writing a “developer” change and take the
> time to explain properly what it’s about.
> >
> > WDYT?
> >
> > Thanks
> > -Vincent
> >
>
>

Re: [xwiki-devs] Update objects on class rename

[Marius Dumitru Florea]

On Wed, Jan 30, 2019 at 6:04 PM Guillaume Delhumeau <
guillaume.delhum...@xwiki.com> wrote:

> Why can't we introduce an "Update objects" field, but only when the page
> actually hold an XClass? It's not the main use-case. It's even quite rare a
> end-user rename such a page. That would not complicate the UI that much 99%
> of the times.
>

Renaming directly a page that defines a class might be rare but renaming a
page that has a child page that defines a class is definitely not rare. So
you're suggesting to always update the objects when renaming the parent of
a class (with "Preserve child pages" on) but to allow the (advanced) users
to decide not to update the objects when renaming directly the class? Or
are you suggesting to use the "Update links" option when renaming the
parent of a class and the "Update objects" option when renaming directly
the class? I find both ways too complicated.


>
> A warning could also be displayed, saying that it might break some
> application (even when updating the XObjects, because the Velocity scripts
> are not magically updated as well).
>
> Le mer. 30 janv. 2019 à 16:55, Simon Urli  a écrit :
>
> > Hi Marius,
> >
> > On 30/01/2019 15:45, Marius Dumitru Florea wrote:
> > > Hi devs,
> > >
> > > I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need it for
> > > https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change the
> > page
> > > rename job (from refactoring module) to update the existing objects
> when
> > a
> > > class is renamed *if the "Update links" options is checked*.
> > >
> > > Of course, we could add a new option (e.g. "Update objects") but:
> > >
> > > * it complicates the rename UI (too many options)
> > > * I think most of the users understand the current "Update links"
> option
> > as
> > > "update the places where this page is *used*". I don't think it makes
> > sense
> > > to have separate options (at least at the UI level) for things like
> > "Update
> > > macro calls" or "Update image includes".
> > > * I don't see why you would want to update the back-links but not the
> > > objects (or the other way around).
> > >
> >
> > I agree that the UI for final users should remain simple. Now on a dev
> > user point of view maybe it might worth it to distinguish the two
> > options in the RenameRequest.
> >
> > > If we agree on using a single option ("Update links") then the next
> > > questions are:
> > >
> > > * Is there a better name? I think "Update links" is a good name for
> > simple
> > > users so I would keep it. Another option is "Update references" but it
> > has
> > > a special meaning for XWiki developers.
> > >
> > > * Should we update the hint for the "Update links" option? I think we
> > > should, but only for advanced users, since they should be aware of the
> > > implications of renaming a class. Simple users are not aware of the
> > > existence of objects, most probably, so I wouldn't complicate their
> > lives.
> > >
> > > The final question is whether we should keep the rename job question
> > about
> > > classes. I think we should. The reason we added it is because renaming
> a
> > > class is currently dangerous. Updating the objects makes it a bit less
> > > dangerous because the data is preserved, but classes are often used in
> > > scripts (e.g. a live table) and those scripts are not updated so
> there's
> > a
> > > high chance that something will not work correctly after the class
> > rename.
> > >
> > > WDYT?
> >
> > I agree that the question should remain if we cannot guarantee that all
> > mentions of the classes are not renamed.
> >
> > Simon
> > >
> > > Thanks,
> > > Marius
> > >
> >
> > --
> > Simon Urli
> > Software Engineer at XWiki SAS
> > simon.u...@xwiki.com
> > More about us at http://www.xwiki.com
> >
>
>
> --
> Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
> Research & Development Engineer at XWiki SAS
> Committer on the XWiki.org project
>

[xwiki-devs] Update objects on class rename

[Marius Dumitru Florea]

Hi devs,

I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need it for
https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change the page
rename job (from refactoring module) to update the existing objects when a
class is renamed *if the "Update links" options is checked*.

Of course, we could add a new option (e.g. "Update objects") but:

* it complicates the rename UI (too many options)
* I think most of the users understand the current "Update links" option as
"update the places where this page is *used*". I don't think it makes sense
to have separate options (at least at the UI level) for things like "Update
macro calls" or "Update image includes".
* I don't see why you would want to update the back-links but not the
objects (or the other way around).

If we agree on using a single option ("Update links") then the next
questions are:

* Is there a better name? I think "Update links" is a good name for simple
users so I would keep it. Another option is "Update references" but it has
a special meaning for XWiki developers.

* Should we update the hint for the "Update links" option? I think we
should, but only for advanced users, since they should be aware of the
implications of renaming a class. Simple users are not aware of the
existence of objects, most probably, so I wouldn't complicate their lives.

The final question is whether we should keep the rename job question about
classes. I think we should. The reason we added it is because renaming a
class is currently dangerous. Updating the objects makes it a bit less
dangerous because the data is preserved, but classes are often used in
scripts (e.g. a live table) and those scripts are not updated so there's a
high chance that something will not work correctly after the class rename.

WDYT?

Thanks,
Marius

Re: [xwiki-devs] [Proposal] Do not write pure-developer release notes

[Marius Dumitru Florea]

I agree with Caty, but by "Developers" I understand "Extension Developers",
who might be interested in new Java APIs (e.g. related to writing
Java-based rendering macros).
Of course, we should provide examples in the RN.

Thanks,
Marius

On Wed, Jan 30, 2019 at 12:41 PM Ecaterina Moraru (Valica) <
vali...@gmail.com> wrote:

> I would also keep the term "Developers". Not sure why we would change that
> name. XWiki is a development platform, we have users that are developers.
>
> Thanks,
> Caty
>
> On Wed, Jan 30, 2019 at 12:37 PM Simon Urli  wrote:
>
> > Hi Vincent,
> >
> > On 30/01/2019 09:05, Vincent Massol wrote:
> > > Hi guys,
> > >
> > > No opinions ?
> > >
> > > Thanks
> > > -Vincent
> > >
> > >> On 25 Jan 2019, at 09:31, Vincent Massol  wrote:
> > >>
> > >> Hi devs,
> > >>
> > >> Context
> > >> ===
> > >>
> > >> It’s been since we’ve deviated from the original purpose of the
> Release
> > Notes by also adding developer-oriented release notes.
> > >>
> > >> The goal of the Release Notes was to **highlight** important novelties
> > for our **users**, because looking at the JIRA list is too technical
> > (otherwise we could simply use the Release feature of JIRA! :)).
> > >>
> > >> So you may ask why we do have a “Developer” Category in the RN app.
> > These were not for pure developers but for XWiki users who are more
> > advanced and can write scripts in wiki pages. And when it’s the case we
> > **must** add examples, otherwise, it’s completely useless.
> > >>
> > >> For example this morning I saw this RN added:
> > >>
> >
> https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.0/Change004/
> > >>
> > >> This is typically something that has very little value to me:
> > >> * It’s for pure developers (java devs)
> > >> * It’s not understandable by anyone except the person who coded it or
> > participated to the dev mailing list discussion about it
> > >> * It doesn’t say more than what’s in the JIRA issue so what’s the
> point?
> > >> * There are no examples at all in it!
> > >> * Real developers can simply look at the reference documentation or
> can
> > read the JIRAs. We always link the JIRA issues in the RN anyway (it was
> for
> > this reason that we’re listing them).
> > >> * It takes time to write RN items and thus it needs to have high value
> > >>
> > >> Proposal
> > >> 
> > >>
> > >> * Go back to the original idea and only list developer RN items when
> > they are for scripting users and not APIs. For example, document some new
> > script service or some additions to existing script services. Of course
> > Groovy would allow you to call any API so being able to use it from
> Groovy
> > is not a good criteria. I’d say that the criteria should be whether the
> > Release Note Change is useful for Velocity users.
> > >> * Rename “Developers” into “Scripters” or or “Advanced Users” (any
> > better name?)
> > >> * Always put an example when writing a “developer” change and take the
> > time to explain properly what it’s about.
> > >>
> > >> WDYT?
> >
> > Actually reading the examples you give, I'm a bit mixed: I agreed that
> > for the first one "the PropertyDisplayType" an example might be given:
> > can be good to actually have the "example" box in the RN form.
> >
> > For the second one about legacy profile activated, actually I don't
> > really know what's the impact for the users, and if he could change
> > something about it. So I don't see how we could provide an example.
> >
> > So I have the feeling that the first one could be indeed adressed to
> > Scripters (and even there, it's not a new scripting API, they could only
> > use it in groovy scripts). And that the second one can be important for
> > some administrators, but not for Scripters on the contrary.
> >
> > I might be wrong here but "Scripters" does not fit IMO and trying to
> > find a new name might lead to create new categories actually.
> > To be a bit more constructive I'd say that maybe for those changes we
> > should not focus on a role but just say "Advanced changes".
> >
> > My 2 cents,
> > Simon
> > >>
> > >> Thanks
> > >> -Vincent
> > >>
> > >
> >
> > --
> > Simon Urli
> > Software Engineer at XWiki SAS
> > simon.u...@xwiki.com
> > More about us at http://www.xwiki.com
> >
>

Re: [xwiki-devs] [Proposal] Document picker in include and display macros

[Marius Dumitru Florea]

On Wed, Jan 23, 2019 at 3:08 PM Adel Atallah  wrote:

> On Wed, Jan 23, 2019 at 11:31 AM Marius Dumitru Florea
>  wrote:
> > It's not that simple.. If the reference parameter already has a value
> that
> > is not a document reference then by showing the document picker that
> value
> > will be parsed / resolved as a document reference and thus displayed as
> if
> > a document has been selected. This can confuse the users. For instance,
> if
> > someone writes in wiki syntax:
> >
> > {{include reference="path.to.p...@file.txt" type="ATTACHMENT"/}}
> >
> > and then edit the page with the WYSIWYG editor, he will see "txt" as
> > selected value when editing the macro...
>
>
> I just tried with `{{display reference="sandbox.webh...@xwikilogo.png"
> type="ATTACHMENT"/}}` and the element was displayed as is in the
> WYSIWYG editor.
> I think this is because the picker uses the search REST API
> (/wikis/{wikiName}/search) which doesn't seems to use a reference
> resolver.
> So one issue is that you won't have autocompletion if you use a prefix
> on a document reference.
>
>

> Also one think I don't currently like is that you cannot edit the
> selected item in the picker, which means, for instance, that if you
> made a typo in "sandbo.webh...@xwikilogo.png" then you'll have to
> delete this element and rewrite the whole reference.
>

I think you can copy the text, delete the option and paste the copied text.
It's not a big issue for me.


>
> I'll make a PR and show you some screenshots or videos so you can see
> what we could currently have.
>

Re: [xwiki-devs] [Proposal] Document picker in include and display macros

[Marius Dumitru Florea]

On Wed, Jan 23, 2019 at 12:36 PM Vincent Massol  wrote:

>
>
> > On 23 Jan 2019, at 11:30, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
> >
> > On Mon, Jan 21, 2019 at 4:10 PM Adel Atallah 
> wrote:
> >
> >> To sum up, here is what I can do:
> >>
> >> On XWiki Commons:
> >> * Introduce a PropertyDisplayType annotation that we can use to
> >> specify with which type the macro parameter should be rendered.
> >> * Add the *display type* in the property descriptor (use the existing
> >> *property type* as default)
> >>
> >> On XWiki Rendering:
> >> * Add the *display type* in the parameter descriptor (use the existing
> >> *property type* as default)
> >>
> >> On XWiki Platform:
> >> * Use the PropertyDisplayType annotation, on reference macro
> >> parameters, with the EntityReference type (for the include and display
> >> macro)
> >>
> >
> >
> >> * Display a document picker for the EntityReference type and make sure
> >> free text is enabled (so that we can enter a reference manually)
> >>
> >
> > It's not that simple.. If the reference parameter already has a value
> that
> > is not a document reference then by showing the document picker that
> value
> > will be parsed / resolved as a document reference and thus displayed as
> if
> > a document has been selected. This can confuse the users. For instance,
> if
> > someone writes in wiki syntax:
> >
> > {{include reference="path.to.p...@file.txt" type="ATTACHMENT"/}}
> >
> > and then edit the page with the WYSIWYG editor, he will see "txt" as
> > selected value when editing the macro…
>
>

> Yes, I agree, this is what I was mentioning by "However if the user has
> used the macro in wiki mode, we’ll need to only display the
> DocumentReference picker if the type is Document.”.
>

The issue is that this part "*display the DocumentReference picker if the
type is Document*" is not easy to express through the macro descriptor.
That is: display the picker P for parameter X if another parameter Y has
the value V. Plus, the picker would need to change if the value of the
other parameter changes. The WYSIWYG editor doesn't have custom code for a
specific macro. It just looks at the macro descriptor and does whatever is
specified there, for any macro. ATM it sees two separate parameters,
reference and type, each with its own "picker" (a plain text input field
for now). It doesn't know it needs to reload the picker for reference when
the value of type changes. A possible solution is to be able to associate a
picker to a parameter group (reference+type).

Thanks,
Marius


>
> Thanks
> -Vincent
>
> >
> >>
> >> On the CKeditor application:
> >> * Use the *display type* instead of the *property type* when using the
> >> html displayer.
> >>
> >> I'll create the Jira issues and make the related PRs if we agree on
> this.
> >>
> >> On Mon, Jan 21, 2019 at 9:30 AM Adel Atallah 
> >> wrote:
> >>>
> >>> On Sat, Jan 19, 2019 at 11:33 AM Vincent Massol 
> >> wrote:
> >>>>
> >>>> Hi Adel,
> >>>>
> >>>>> On 18 Jan 2019, at 11:59, Adel Atallah 
> >> wrote:
> >>>>>
> >>>>> On Fri, Jan 18, 2019 at 11:27 AM Vincent Massol 
> >> wrote:
> >>>>>>
> >>>>>> Hi Adel,
> >>>>>>
> >>>>>>> On 17 Jan 2019, at 11:05, Adel Atallah 
> >> wrote:
> >>>>>>>
> >>>>>>> Hi devs,
> >>>>>>>
> >>>>>>> After discussing with Marius and Thomas, we thought it might be a
> >> good
> >>>>>>> idea to do the following to have a document picker in the include
> >> and
> >>>>>>> display maros:
> >>>>>>> * Remove the deprecation of the document parameter (only for the
> >> include macro).
> >>>>>>
> >>>>>> I don’t understand this part. Sounds counter-intuitive to me since
> >> we want users to use the “reference” one. Could you explain?
> >>>>>
> >>>>> We currently only have a document picker that we can use for
> >>>>> DocumentReferences. To have auto-suggestion on the "reference"
> >>>>> parameter, we would need to make another pick

Re: [xwiki-devs] [Proposal] Document picker in include and display macros

[Marius Dumitru Florea]

On Mon, Jan 21, 2019 at 4:10 PM Adel Atallah  wrote:

> To sum up, here is what I can do:
>
> On XWiki Commons:
> * Introduce a PropertyDisplayType annotation that we can use to
> specify with which type the macro parameter should be rendered.
> * Add the *display type* in the property descriptor (use the existing
> *property type* as default)
>
> On XWiki Rendering:
> * Add the *display type* in the parameter descriptor (use the existing
> *property type* as default)
>
> On XWiki Platform:
> * Use the PropertyDisplayType annotation, on reference macro
> parameters, with the EntityReference type (for the include and display
> macro)
>


> * Display a document picker for the EntityReference type and make sure
> free text is enabled (so that we can enter a reference manually)
>

It's not that simple.. If the reference parameter already has a value that
is not a document reference then by showing the document picker that value
will be parsed / resolved as a document reference and thus displayed as if
a document has been selected. This can confuse the users. For instance, if
someone writes in wiki syntax:

{{include reference="path.to.p...@file.txt" type="ATTACHMENT"/}}

and then edit the page with the WYSIWYG editor, he will see "txt" as
selected value when editing the macro...


>
> On the CKeditor application:
> * Use the *display type* instead of the *property type* when using the
> html displayer.
>
> I'll create the Jira issues and make the related PRs if we agree on this.
>
> On Mon, Jan 21, 2019 at 9:30 AM Adel Atallah 
> wrote:
> >
> > On Sat, Jan 19, 2019 at 11:33 AM Vincent Massol 
> wrote:
> > >
> > > Hi Adel,
> > >
> > > > On 18 Jan 2019, at 11:59, Adel Atallah 
> wrote:
> > > >
> > > > On Fri, Jan 18, 2019 at 11:27 AM Vincent Massol 
> wrote:
> > > >>
> > > >> Hi Adel,
> > > >>
> > > >>> On 17 Jan 2019, at 11:05, Adel Atallah 
> wrote:
> > > >>>
> > > >>> Hi devs,
> > > >>>
> > > >>> After discussing with Marius and Thomas, we thought it might be a
> good
> > > >>> idea to do the following to have a document picker in the include
> and
> > > >>> display maros:
> > > >>> * Remove the deprecation of the document parameter (only for the
> include macro).
> > > >>
> > > >> I don’t understand this part. Sounds counter-intuitive to me since
> we want users to use the “reference” one. Could you explain?
> > > >
> > > > We currently only have a document picker that we can use for
> > > > DocumentReferences. To have auto-suggestion on the "reference"
> > > > parameter, we would need to make another picker for all type of
> > > > references, not just document.
> > >
> > > Ok I understand.
> > >
> > > But I don’t think it’s a good idea to remove the deprecation on
> “document”. This is deprecated for a good reason. And if we undeprecate it
> then we’ll need to redeprecate it soon enough and it also means
> “deprecating" “reference” so that it’s moved to the advanced section. It’s
> also bad for users who’ve been told to not use the “document” parameter.
> Without mentioning that the document parameter is only available in the
> legacy module and thus without legacy modules it wouldn’t work. Raises
> plenty of problems.
> > >
> > > Other Ideas instead:
> > > 1) Use the DocumentReference picker when the Type is Document and when
> the type is changed to something else, let the user type the reference.
> > > 2) Improve the picker to support picking any type of references:
> documents, spaces, wiki, attachments, objects, properties.
> > > 3) Now in practice the include macro only supports including Documents
> so we could also simply do an override as you suggested (but on the
> “reference” field), that would be used only for the WYSIWYG (when in wiki
> mode you’d be able to enter only Document references). However if the user
> has used the macro in wiki mode, we’ll need to only display the
> DocumentReference picker if the type is Document.
> >
> > I think 3) is the simplest solution for now. We could always show the
> > document picker on the "reference" field but allow free text so that
> > other references can be manually entered.
> >
> > >
> > > 
> > > I don’t think there are really good user use-cases for using something
> else than the Document type since it’ll always translate into a Document in
> the end so the user can always pick that doc instead of letting the macro
> resolve it for him.
> > > 
> > >
> > > Note: If 1) or 2) or 3) are too hard for 11.0 (and it seems we’re too
> late already since we’re releasing RC Monday!) then we could push that one
> for later for the include/display macros and instead support other and
> simpler well known macros in 11.0, from
> https://design.xwiki.org/xwiki/bin/view/Proposal/AutocompleteOnReference#HWYIWYGMacros,
> like DocumentTree macro.
> > >
> > > What I’d like is to have at least one macro that can use the picker in
> 11.0, mostly to prove that it works and to have something to report for
> users in the release notes and to show progress.
> > >
> > > Than

Re: [xwiki-devs] [Proposl] Improve JIRA resolution and introduce a "Solved by" resolution

[Marius Dumitru Florea]

On Thu, Jan 10, 2019 at 12:43 PM Vincent Massol  wrote:

> Hi devs,
>
> Right now we often use “duplicate” when we have an issue that is solved by
> another issue (usually a more specific one). This is not semantically
> correct.
>
> Proposal:
> * Add a new jira resolution named “Solved by”
> * Best practice: when using “solved by”, also use the “depends on” link
>
> WDYT?
>

+0

We could also close the "duplicate" issue as Fixed (so no new resolution)
and add instead a "Fixed by" relation / link type. The users will see the
issue as Fixed and the developers will see the link to the actual fix.

Thanks,
Marius


>
> Thanks
> -Vincent

Re: [xwiki-devs] [Proposal] Change of XS Cycle strategy to account for Christmas

[Marius Dumitru Florea]

+1

Thanks,
Marius

On Sun, Dec 9, 2018 at 5:07 PM Vincent Massol  wrote:

> Ok, summarizing again after feedback from Simon, Caty and Marius, here’s
> the proposal;
>
> * Duration: 11 minor releases (e.g. N.0 till N.10), one each month, from
> January to November.
> * The last month of the year, December sees 2 bug fix releases, to
> stabilize the cycle: N.10.1 and N.10.2. The releases are supposed to
> contain mostly bug fixes.
> ** Note that the N.10.2 release can happen on the first days of January to
> account for end of year holidays but it should not go beyond the 3rd of
> January.
> ** Work for N+1.0 starts once N.10.2 has been released.
> * When N.10.2 is released we announce it:
> ** Send mail mentioning that the cycle is over and encourage users to
> start using N.10.2
> ** In that mail, explain all the major features that were implemented
> during that release cycle (make a special Release Notes for a Cycle)
> * We announce the new LTS (N.10.x) once N+1.0 is released. Rationale:
> ** We need to have feedback on a release before it can be considered super
> stable and thus we usually need a few bug fix releases before a version can
> be considered a good LTS. This gives us one month to release additional
> bugfix releases for N.10.x in case it’s needed.
> ** This also allows us to always support 3 branches:
> *** LTS branch
> *** Stable branch
> *** master (latest SNAPSHOT)
>
> Note that I hesitated to announce the LTS when we released N.10.2 but
> after thinking about it, I think it’s better to continue announcing it only
> when N+1.0 is released (i.e. at end of January).
>
> I have modified
> https://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractices?viewer=changes&rev1=14.1&rev2=15.1
> already.
>
> Once I have the final validation this is ok, I’m redo the screenshot at
>
> https://dev.xwiki.org/xwiki/bin/download/Community/VersioningAndReleasePractices/releasecycle.png
>
> Thanks
> -Vincent
>
> > On 19 Nov 2018, at 17:13, Vincent Massol  wrote:
> >
> > Hi devs,
> >
> > Some devs mentioned it’s too hard to release the N.11 release since it
> happens around Christmas every year.
> >
> > Here’s a proposal:
> >
> > * Shorten the cycle to 11 releases instead of 12.
> > * Release N.9 at end of Nov
> > * Release N.10 at end of first week of Jan. Note: N.10RC1 would be
> released mid December (about 17th of Dec to have 3 weeks of RC).
> > * Release N+1.0 at end of February. Start of N+1.0 work
> >
> > Pros:
> > * No release during Christmas, yeah :)
> > * More time to prepare the first LTS bugfix release, i.e. N.10.1, which
> can be done during the month of January.
> > * More time for the first released of N+1 (i.e. N+1.0). This is
> important since that’s the release where we can do heavy refactoring and
> it’s not bad to get some more time.
> >
> > Cons:
> > * One less release
> >
> > WDYT? Do you see other cons?
> >
> > Thanks
> > -Vincent
> >
>
>

Re: [xwiki-devs] [Proposal] Let contrib committers be JIRA administrators for contrib projects?

[Marius Dumitru Florea]

+1

Thanks,
Marius

On Thu, Dec 6, 2018 at 1:49 PM Vincent Massol  wrote:

> Hi devs,
>
> Stephane Lauriere was asking us to have admin rights for the chartjs
> contrib project so that he could do a release.
>
> Right now only the owner + global jira admins have admin rights.
>
> I’m proposing to change the current Administrator role for JIRA Contrib
> Projets from:
> * jira-administrators
>
> to:
>
> * jira-administrators
> * contrib-committers
> * xwiki-committers
>
> WDYT?
>
> Thanks
> -Vincent
>
>

Re: [xwiki-devs] [Proposal] Change of XS Cycle strategy to account for Christmas

[Marius Dumitru Florea]

On Thu, Dec 6, 2018 at 12:54 PM Simon Urli  wrote:

> Hi all,
>
> I'm ok with the first proposal to reduce at 11 releases instead of 12.
> I think it allows indeed to better polish the latest release and avoid
> lot of stress at the end of the year.
>
> Now on the implem I'd agree more on your last mail, ie:
>
>  > stopping the dev at end of November (i.e. N.10) and then do a first
> bugfix release (N.10.1) for mid December and a last bugfix release
> (N.10.2) from Mid December to early January (2nd or 3rd of Jan).
>
> than with your first one:
>
>  > * Release N.9 at end of Nov
>  > * Release N.10 at end of first week of Jan. Note: N.10RC1 would be >
> released mid December (about 17th of Dec to have 3 weeks of RC).
>  > * Release N+1.0 at end of February. Start of N+1.0 work
>
>

> So +1 for 11 releases, the 11th released at the end of november and then
> december is completely used for bugfixing releases.
>

+1 as well.

Thanks,
Marius


>
> My 2 cents,
> Simon
>
> On 06/12/2018 11:17, Vincent Massol wrote:
> > Hi Edy,
> >
> >> On 19 Nov 2018, at 19:15, Eduard Moraru  wrote:
> >>
> >> Hi, Vincent.
> >>
> >> +1 for the general goal of avoiding needless holiday stress.
> >>
> >> Now, on the details, there is something I'm struggling to understand:
> >> * I see that we have 2 options for finishing N.11:
> >> A) In the middle of December (i.e. 10.11RC on 10th of Dec -2w- and 10.11
> >> Final on 17 Dec -1w-), similar to what we did for 9.11.x (9.11RC1 was on
> >> 11th of Dec 2017 and 9.11 Final was on 18th of Dec 2017)
> >
> >> B) At the beginning of January (i.e. 10.11RC on 17th of Dec -3w- and
> 10.11
> >> Final on the 7th of Jan 2019 -3w-)
> >> ** I would personally prefer A) in order to "close the books" before the
> >> holiday season and start fresh in January. Anyone working during the
> >> Holidays can start on N+1.0 or work on bugfixes for N.11.1.
> >> * In both cases, N+1.0 should be same at the end of January, not
> February.
> >> ** Why would it have to be end of February, and thus lose a release, as
> >> mentioned in your "Cons" section?
> >> ** I get it if it comes as a new proposal to double the length of N.0
> to 2m
> >> instead of 1 (for which I'd be +0, since I prefer less exceptions, if
> >> possible), but I don't get it if we see it as a consequence of how we
> >> handle holidays.
> >>
> >> Side note: While trying to understand how all of this works, I can't but
> >> help to notice how the week-based calculations don't add up, since a
> month
> >> is 4.3(3) weeks long and everything planned around weeks is bound to be
> >> distorted when you look at it by months. IMO, it would make more sense
> to
> >> reason in terms of months (synchronized with our 12 releases cycle) and
> say
> >> things like "last Monday of December". Not sure how easy it would be to
> >> work with... just food for thought.
> >
> > Some comments:
> >
> > 1) We already work by months, see
> https://www.xwiki.org/xwiki/bin/view/Roadmaps/#HXWiki10.xCycle. When we
> plan a given release we adjust (a bit more days or a bit less days) so that
> it’s released before the end of the month.
> >
> > 2) If I sum up your proposal A) it’s about saying that the last release
> would be shorter than the other ones. Say half a month vs one month (we
> can’t guarantee 3 weeks vs 1 month IMO since there can be delays for the
> previous release, people on early holidays, etc).
> >
> > Pros and cons of option A vs option B:
> >
> > * More logical, feel nice to have 12 releases for 12 months and to
> “fully” finish the N cycle before new year starts (in practice it’s false,
> see below).
> > * More stressful, little margin for error and less time for the last
> release
> > * No time at all planned for the bug fix release we need to do for the
> LTS. That’s the biggest issue for option A and what we saw in practice over
> the past years: we start the new cycle at beginning of Jan and at the same
> time we have to do the bug fix release for the LTS. In practice this
> usually means that N+1.0 has little progress in it.
> >
> > Note that what we did in the past was slightly different:
> > * We planned for 11 releases (and not 12).
> > * We said that the end of the year (last month) was 2 stabilization
> releases of 2 weeks each (no RCs).
> >
> > IMO if we want to fully finish by end of year we need to include at
> least one bugfix release for the LTS before the end of the year, which
> means stopping the dev at end of November (i.e. N.10) and then do a first
> bugfix release (N.10.1) for mid December and a last bugfix release (N.10.2)
> from Mid December to early January (2nd or 3rd of Jan).
> >
> > I am under the impression that option B) (the one I proposed) would be
> less stressful. It comes at the expense of 1 release less but I’m not sure
> that this would be a huge issue.
> >
> > @Devs: what would you prefer?
> >
> > Thanks
> > -Vincent
> >
> > PS: We need to hurry to decide if we want to put this in place in the
> coming days… Might be 

Re: [xwiki-devs] [Proposal] WCAG exception: consecutive line breaks

[Marius Dumitru Florea]

On Thu, Nov 22, 2018 at 11:22 AM Thomas Mortagne 
wrote:

> On Thu, Nov 22, 2018 at 9:57 AM Vincent Massol  wrote:
> >
> >
> >
> > > On 21 Nov 2018, at 17:46, Adel Atallah  wrote:
> > >
> > > Hello,
> > >
> > > On Wed, Nov 21, 2018 at 5:36 PM Simon Urli 
> wrote:
> > >>
> > >> Hi everyone,
> > >>
> > >> one of the most validation error we have with WCAG is about
> consecutive
> > >> line breaks: basically a  presents in a page.
> > >>
> > >> This happens mostly in our translation pages since the linebreaks in
> > >> plain syntax are translated in  tags.
> > >> Caty provided a lot of details about this error on the related issue:
> > >> https://jira.xwiki.org/browse/XWIKI-15666.
> > >>
> > >> Currently we have around 140 validations failure because of this.
> > >>
> > >> Different proposal have been made in order to fix it, that I will try
> to
> > >> sum-up here:
> > >>
> > >>   A. Remove completely this validation check
> > >
> > > -0, I think the validation can be useful at least to keep good
> practices.
> > >
> > >>   B. Add an exception for the translation pages
> > >
> > > +1, simplest one.
> >
> > Note that the question is not so much about being simple (we can just
> remove WCAG for that and it’s the simplest ;)) but about being the right
> thing to do for people with disabilities.
> >
> > For me we have the following options:
> >
> > A) We don’t think that this check is useful, ie that it brings
> advantages for people with disabilities and then we can remove it. No need
> to add exceptions.
> >
> > B) We think the check is useful for people with disabilities and we
> should keep it, even for translations pages since I don’t see why people
> with disabilities shouldn’t be able to use translation pages. There are
> some ideas to fix this: I listed some in the jira issue and Thomas
> mentioned one too (it’s option D).
> >
>
> > C) Now I’m fine if we say the following: for technical reasons it’s
> already hard to ensure that we pass WCAG for user pages and thus FTM we
> focus only on those ones and we agree that we don’t pass WCAG for
> developer-oriented features, with the goal of improving on that aspect in
> the future. And thus we disable WCAG checks on technical pages (hidden
> pages) for now.
>
>

> Excluding hidden page for now is indeed something that would make a
> lot of sense.
>

I agree. The issue is that we can have hidden pages that:

* are not displayed by default (I'm thinking panels)
* are included / displayed dynamically with JavaScript so they won't appear
in the HTML downloaded by our WCAG tests (I'm thinking of async panels and
modals for instance)

So they won't be covered.


>
> >
> > Thanks
> > -Vincent
> >
> > >
> > >>   C. Triggers the error only if more than 2 consecutive breaks is
> > >> encountered
> > >
> > > -1, it doesn't really makes sense to do that, it's like B. but badly
> done.
> > >
> > >>   D. Create a rendering syntax dedicated to translation pages
> > >
> > > +1, could be a good idea but might be complicated.
> > >
> > >>
> > >>
> > >> A. Remove completely the validation check
> > >>
> > >> pros:
> > >>   * the easiest one
> > >>   * apparently the rule is not checked in other accessibility test, so
> > >> its real purpose for accessibility is unclear
> > >>
> > >> cons:
> > >>   * IMO this rule is useful for checking the good practice of not
> using
> > >> 
> > >>
> > >> B. Add an exception for the translation pages
> > >>
> > >> pros:
> > >>   * same as for A
> > >>
> > >> cons:
> > >>   * ?
> > >>
> > >> C. Triggers the error only if more than 2 consecutive breaks is
> encountered
> > >>
> > >> pros:
> > >>   * ?
> > >>
> > >> cons:
> > >>   * we would miss some consecutive  that are used only for style
> > >> and we would catch some others in translations if we do 3 linebreaks
> > >> instead of 2. IMO it's only moving the problem
> > >>
> > >> D. Create a rendering syntax dedicated to translation pages
> > >>
> > >> pros:
> > >>   * remove completely the problem of consecutive  in
> translations
> > >>   * can maybe be used to present them in another way?
> > >>
> > >> cons:
> > >>   * need to develop/test/maintain a new rendering syntax
> > >>
> > >> I'd personnaly vote like this:
> > >> A: +0
> > >> B: +1
> > >> C: -1
> > >> D: +0
> > >>
> > >> WDYT?
> > >>
> > >> Simon
> > >> --
> > >> Simon Urli
> > >> Software Engineer at XWiki SAS
> > >> simon.u...@xwiki.com
> > >> More about us at http://www.xwiki.com
> >
>
>
> --
> Thomas Mortagne
>

Re: [xwiki-devs] [Proposal] Always add a link to the reference doc in the RN items

[Marius Dumitru Florea]

+1

On Sun, Nov 18, 2018 at 3:56 PM Vincent Massol  wrote:

> Hi devs,
>
> This is something I mentioned a few times (just did on IRC/matrix an hour
> ago too) but I don’t know if we have an agreement about to, so I’m making a
> proposal.
>
> The idea is that I think it would be nice for users to be able to the read
> the RN and for each item to be able to navigate to the reference
> documentation to know more about the topic.
>
> Thus the proposal is to always add a link to the reference doc in RN items.
>
> For example I added a link here:
>
> https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/10.10RC1/#HAllowwikimacrostoindicatethetypeofparameters
>
> When I created the RN app I had hesitate to have a field for that but I
> thought it be nicer if the links were in the text (better flow) and it
> would take less visual space (if we have a field we’ll need to add the info
> somewhere which will take more space). The downside is that everyone is
> forgetting to do it and it's not enforceable automatically.
>
> WDYT?
>
> Thanks
> -Vincent
>
>

Re: [xwiki-devs] [Need proposal] How to show "conflicting" macro parameters

[Marius Dumitru Florea]

On Thu, Nov 15, 2018 at 10:51 AM Thomas Mortagne 
wrote:

> I'm also really not a fan of having to implement a component just to
> indicate that two groups of properties are conflicting.
>
> +1 for making @Group support a hierarchy, that's indeed nice.
>
> For for conflicting we need a dedicated annotation IMO.
>
> So starting from your previous example I would expect something like:
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
> @PropertyGroup("target")
> @PropertyFeature("reference")
> page
>
> @PropertyGroup({"target", "entityReference"})
> @PropertyFeature("reference")
> reference
>
> @PropertyGroup({"target", "entityReference"})
> type
>
> @PropertyGroup("target")
> @PropertyFeature("reference")
> document
>
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>

I don't think this is complete. The following doesn't make sense:

{{include page="..." type="..."/}}

and neither this:

{{include document="..." type="..." /}}

So it's not the reference parameter alone that provides the "reference"
feature. The pair / group of parameters (reference and type) are providing
the "reference" feature. This is why I think there is the need to specify
the "feature" on the sub group "entityReference" not on the parameter. And
to do this we need another class..

>
>
> or
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
> @PropertyGroup("target", features = "reference")
> page
>
> @PropertyGroup({"target", "entityReference"}, features = "reference")
> reference
>
> @PropertyGroup({"target", "entityReference"})
> type
>
> @PropertyGroup("target", features = "reference")
> document
>
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
>

> * PropertyGroup define the hierarchy (also proposed a String[] instead
> of String based value to show all possible ways to pass the hierarchy
> value)
>

+1 for this


> * PropertyFeature (name is negotiable :)) or PropertyGroup "features"
> field associate the group with a set of unique "features". This is the
> same logic than for extensions where several groups with with a shared
> feature are in conflict
>

You're not associating the feature to the group. That is the problem IMO.
You are associating the feature to the parameter.  For instance:

@PropertyGroup("foo", features = "input")
one

@PropertyGroup("foo", features = "output")
two

Is the "input" and "output" feature associate to the "foo" group or to the
parameters one and two respectively?

Thanks,
Marius


>
> We could also decide to support only one feature per group right now
> since we don't yet have the need for several but it felt more natural
> like this.
>
> On Thu, Nov 15, 2018 at 8:04 AM Vincent Massol  wrote:
> >
> >
> >
> > > On 15 Nov 2018, at 08:02, Vincent Massol  wrote:
> > >
> > >
> > >
> > >> On 15 Nov 2018, at 06:29, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
> > >>
> > >> On Wed, Nov 14, 2018 at 5:12 PM Vincent Massol 
> wrote:
> > >>
> > >>> I thought about something like this but I discarded it as I find this
> > >>> complicated for something that should be relatively simple.
> > >>
> > >>
> > >> I don't think it's that complicated because:
> > >>
> > >> * Conflicting parameters should be an exception, not the rule. What
> other
> > >> macros, besides include / display, need this?
> > >> * If you just want to group macro parameters for display then you
> only need
> > >> to use the @Group annotation. You don't need to implement a
> ParameterGroup.
> > >> The ParameterGroup is needed only for conflicting parameters

Re: [xwiki-devs] [Need proposal] How to show "conflicting" macro parameters

[Marius Dumitru Florea]

On Wed, Nov 14, 2018 at 5:12 PM Vincent Massol  wrote:

> I thought about something like this but I discarded it as I find this
> complicated for something that should be relatively simple.


I don't think it's that complicated because:

* Conflicting parameters should be an exception, not the rule. What other
macros, besides include / display, need this?
* If you just want to group macro parameters for display then you only need
to use the @Group annotation. You don't need to implement a ParameterGroup.
The ParameterGroup is needed only for conflicting parameters (ATM).

Thanks,
Marius


> I’d prefer to have some simple annotations if possible. In other words, if
> feels a bit of over-engineering for the need. Now I have to admit that I
> stopped following this thread after the original proposal so maybe I’m just
> completely off :)
>
> Thanks
> -Vincent
>
> > On 14 Nov 2018, at 15:51, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
> >
> > WDYT about:
> >
> > -8<- IncludeMacroParameters --
> > @Group("target")
> > page
> >
> > @Group("target/entityReference")
> > reference
> >
> > @Group("target/entityReference")
> > type
> >
> > @Group("target")
> > document
> >
> > section
> >
> > context
> > ->8---
> >
> > That is: specify *only* the group hierarchy in the macro parameter
> > descriptor. This would produce the following hierarchy:
> >
> > * 
> > ** page
> > ** 
> > *** reference
> > *** type
> > ** document
> > * section
> > * context
> >
> > Next, for the cases where we want to customize the behavior of a group,
> we
> > introduce a component role ParameterGroup. For instance, for the "target"
> > parameter group of the Include Macro we would create
> >
> > @Named("include/target")
> > public class TargetParameterGroup  implements ParameterGroup {}
> >
> > To specify that the members of a parameter group are exclusive we can
> > either use a method in the ParameterGroup interface (e.g. isExclusive())
> or
> > use an annotation on the implementation TargetParameterGroup.
> >
> > Thanks,
> > Marius
> >
> >
> > On Tue, Nov 13, 2018 at 12:03 PM Adel Atallah 
> > wrote:
> >
> >> Hello,
> >>
> >> I'd like to briefly summarize the situation so that we can make some
> >> progress.
> >>
> >> What we have:
> >> * We define "parameters" in a macro by creating a Java Bean, which
> >> provides all the getters and setters of the parameters we want.
> >> * We can use annotations on these getters/setters to define some
> >> behavior or metadata for these parameters (description, mandatory,
> >> deprecated...)
> >>
> >> What we want:
> >> * Being able to handle conflicting parameters. For instance when we
> >> deprecate a parameter and add a new one to replace it, we should be
> >> able to either use the deprecated parameter or the new one but not
> >> both.
> >> * We also want to group parameters that are related to each other.
> >>
> >> What we proposed:
> >> * Use annotations on the parameters to express the conflict.
> >> * Marius proposed to see the problem as a boolean expression such as:
> >> (page XOR (reference AND type) XOR document) OR section OR context.
> >> This would translate as: the user can use the 'section' and/or
> >> 'context' parameters (if they want), can use only one of these
> >> parameters: 'page', ('reference' and 'type') or 'document', where
> >> 'reference' and 'type' depend on each other and you can't use one
> >> without the other.
> >> * You can see on previous e-mails the kind of annotations we proposed
> >> to solve the issue.
> >>
> >> Thanks,
> >> Adel
> >>
>
>

Re: [xwiki-devs] [Need proposal] How to show "conflicting" macro parameters

[Marius Dumitru Florea]

WDYT about:

-8<- IncludeMacroParameters --
@Group("target")
page

@Group("target/entityReference")
reference

@Group("target/entityReference")
type

@Group("target")
document

section

context
->8---

That is: specify *only* the group hierarchy in the macro parameter
descriptor. This would produce the following hierarchy:

* 
** page
** 
*** reference
*** type
** document
* section
* context

Next, for the cases where we want to customize the behavior of a group, we
introduce a component role ParameterGroup. For instance, for the "target"
parameter group of the Include Macro we would create

@Named("include/target")
public class TargetParameterGroup  implements ParameterGroup {}

To specify that the members of a parameter group are exclusive we can
either use a method in the ParameterGroup interface (e.g. isExclusive()) or
use an annotation on the implementation TargetParameterGroup.

Thanks,
Marius


On Tue, Nov 13, 2018 at 12:03 PM Adel Atallah 
wrote:

> Hello,
>
> I'd like to briefly summarize the situation so that we can make some
> progress.
>
> What we have:
> * We define "parameters" in a macro by creating a Java Bean, which
> provides all the getters and setters of the parameters we want.
> * We can use annotations on these getters/setters to define some
> behavior or metadata for these parameters (description, mandatory,
> deprecated...)
>
> What we want:
> * Being able to handle conflicting parameters. For instance when we
> deprecate a parameter and add a new one to replace it, we should be
> able to either use the deprecated parameter or the new one but not
> both.
> * We also want to group parameters that are related to each other.
>
> What we proposed:
> * Use annotations on the parameters to express the conflict.
> * Marius proposed to see the problem as a boolean expression such as:
> (page XOR (reference AND type) XOR document) OR section OR context.
> This would translate as: the user can use the 'section' and/or
> 'context' parameters (if they want), can use only one of these
> parameters: 'page', ('reference' and 'type') or 'document', where
> 'reference' and 'type' depend on each other and you can't use one
> without the other.
> * You can see on previous e-mails the kind of annotations we proposed
> to solve the issue.
>
> Thanks,
> Adel
>

Re: [xwiki-devs] [Need proposal] How to show "conflicting" macro parameters

[Marius Dumitru Florea]

On Fri, Nov 9, 2018 at 4:58 PM Adel Atallah  wrote:

> On Fri, Nov 9, 2018 at 12:08 PM Marius Dumitru Florea
>  wrote:
> >
> > Try to view the macro parameters listed as a boolean expression. For the
> > include macro we would have:
> >
> > (page XOR (reference AND type) XOR document) OR section OR context
>
>

> Wouldn't it be: (page XOR (reference AND type) XOR document) *AND*
> section *AND* context ?
>

No. AND means (logically) both sides are required. You can specify the
section parameter without specifying the context parameter. So it's
definitely a *logical / boolean* OR between them.

I put AND between reference and type just to show that there might be cases
when two (or more) parameters must be specified together (i.e. either you
specify both or you specify none of them). In our case the type parameter
has a default value so you can specify only the reference. This means it's
actually OR between reference and type in the case of the include macro.


> I just feel like you can just have 2 types of "operators": one to
> exclude (XOR) and the other to include (AND) parameters.
>

I still think there can be 3 operators (if we want to cover everything). As
I said, you may want to express the fact that a parameter is mandatory only
if some other parameter is specified. We can't express this ATM so I guess
we can work only with XOR and OR.


>
> >
> > * the parentheses define the parameter groups
> > * the boolean operators specify the relation between the members of a
> group
> >
> > We then need to express this using Java annotations. In any case, this
> is a
> > **tree** structure (not a flat structure).
>
> What you describe could probably be done with what we proposed but
> maybe we can have something more explicit:
>
> public void setReference(String reference)
>
> @Depends("reference")
> public void setType(EntityType type)
>
> @Conflict("reference")
> public void setPage(String page)
>
> Could that work? We would need to write all the logic behind to build the
> tree:
> 1. All parameters are joined by an 'AND' by default => page AND
> reference AND type
> 2. Page and Reference are conflicting => (page XOR reference) AND type
> 3. Type depends on Reference => (page XOR (reference AND type))
>
> WDYT?
>

I'm not sure how @Depends and @Conflict defines the tree structure in
general. I was rather thinking of something like:

@GroupPath("target[XOR]")
page

@GroupPath("target[XOR]/entityReference")
reference

@GroupPath("target[XOR]/entityReference")
type

@GroupPath("target[XOR]")
document

If we want subgroups then we need to specify a path. The complex part is to
specify the "operator" that should be used within a subgroup.


> >
> > On Fri, Nov 9, 2018 at 12:30 PM Adel Atallah 
> wrote:
> >
> > > On Fri, Nov 9, 2018 at 11:20 AM Marius Dumitru Florea
> > >  wrote:
> > > >
> > > > On Wed, Nov 7, 2018 at 5:34 PM Adel Atallah 
> > > wrote:
> > > >
> > > > > Hello everyone,
> > > > >
> > > > > So what we thought about with Vincent for implementing the
> "concept of
> > > > > aliases or groups" would be to actually have two new annotations
> that
> > > > > we would use on macro properties.
> > > > > The first one is a "Group" annotation which is meant to indicate
> that
> > > > > some properties are part of the same group, obviously.
> > > > > The second is an "Alternative" annotation which is meant to
> indicate
> > > > > that only one property / group of properties can be used (among the
> > > > > ones that are part of the alternative).
> > > > > Here is an example:
> > > > > We want for the Include macro to be able to specify either:
> > > > > the "reference" and "type" parameters
> > > > > or
> > > > > the "page" parameter
> > > > > For that, we will change the IncludeMacroParameters java class like
> > > this:
> > > > >
> > > > > @Alternative("reference")
> > > > > @Group("entityReference")
> > > > > public void setReference(String reference)
> > > > >
> > > > > @Alternative("reference")
> > > > > @Group("entityReference")
> > > > > public void setType(EntityType type)
> > > > >
> > > > > @Alternative("reference")

Re: [xwiki-devs] [Need proposal] How to show "conflicting" macro parameters

[Marius Dumitru Florea]

Try to view the macro parameters listed as a boolean expression. For the
include macro we would have:

(page XOR (reference AND type) XOR document) OR section OR context

* the parentheses define the parameter groups
* the boolean operators specify the relation between the members of a group

We then need to express this using Java annotations. In any case, this is a
**tree** structure (not a flat structure).

On Fri, Nov 9, 2018 at 12:30 PM Adel Atallah  wrote:

> On Fri, Nov 9, 2018 at 11:20 AM Marius Dumitru Florea
>  wrote:
> >
> > On Wed, Nov 7, 2018 at 5:34 PM Adel Atallah 
> wrote:
> >
> > > Hello everyone,
> > >
> > > So what we thought about with Vincent for implementing the "concept of
> > > aliases or groups" would be to actually have two new annotations that
> > > we would use on macro properties.
> > > The first one is a "Group" annotation which is meant to indicate that
> > > some properties are part of the same group, obviously.
> > > The second is an "Alternative" annotation which is meant to indicate
> > > that only one property / group of properties can be used (among the
> > > ones that are part of the alternative).
> > > Here is an example:
> > > We want for the Include macro to be able to specify either:
> > > the "reference" and "type" parameters
> > > or
> > > the "page" parameter
> > > For that, we will change the IncludeMacroParameters java class like
> this:
> > >
> > > @Alternative("reference")
> > > @Group("entityReference")
> > > public void setReference(String reference)
> > >
> > > @Alternative("reference")
> > > @Group("entityReference")
> > > public void setType(EntityType type)
> > >
> > > @Alternative("reference")
> > > public void setPage(String page)
> > >
> > > In the WYSIWYG side, we will only be able to specify either the
> > > "reference" and the "type" or the "page" parameter.
> > >
> >
> > I think it would make more sense, at least in this case, to have the
> > alternative as an attribute of the group, because semantically the
> > "entityReference" group is an alternative to the page parameter. You
> can't
> > say that the type parameter alone is an alternative to the page
> parameter.
> >
> > The @Group annotation is clear. No doubt about it. I'm not sure about
> > the @Alternative annotation. I'm thinking that the "alternative" is also
> a
> > group, where only one item from the group can be used, which could be
> > expressed with an attribute of the @Group annotation.
>
> Thanks for the suggestion, but how can it be used? If I retake my previous
> example, will it be:
>
> @Group(name = "entityReference", alternative = "reference")
> public void setReference(String reference)
>
> @Group(name = "entityReference", alternative = "reference")
> public void setType(EntityType type)
>
> @Group(name = "page", alternative = "reference")
> public void setPage(String page)
>
> ?
> >
> >
> > >
> > > WDYT?
> > >
> > > Thanks,
> > > Adel
> > >
> > > On Tue, Sep 25, 2018 at 11:51 AM Marius Dumitru Florea
> > >  wrote:
> > > >
> > > > On Wed, Sep 19, 2018 at 4:31 PM Vincent Massol 
> > > wrote:
> > > >
> > > > >
> > > > >
> > > > > > On 19 Sep 2018, at 14:47, Adel Atallah 
> > > wrote:
> > > > > >
> > > > > > On Wed, Jul 18, 2018 at 5:00 PM Vincent Massol <
> vinc...@massol.net>
> > > > > wrote:
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>> On 5 Jul 2018, at 12:06, Vincent Massol 
> > > wrote:
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>> On 4 Jul 2018, at 12:07, Thomas Mortagne <
> > > thomas.morta...@xwiki.com>
> > > > > wrote:
> > > > > >>>>
> > > > > >>>> Here are more details on the actual use case we need to
> support:
> > > > > >>>>
> > > > > >>>> In include/Display macro either you set:
> > > > > >>>>
> 

Re: [xwiki-devs] [Need proposal] How to show "conflicting" macro parameters

[Marius Dumitru Florea]

On Fri, Nov 9, 2018 at 12:29 PM Vincent Massol  wrote:

> Hi,
>
> > On 9 Nov 2018, at 11:20, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
> >
> > On Wed, Nov 7, 2018 at 5:34 PM Adel Atallah 
> wrote:
> >
> >> Hello everyone,
> >>
> >> So what we thought about with Vincent for implementing the "concept of
> >> aliases or groups" would be to actually have two new annotations that
> >> we would use on macro properties.
> >> The first one is a "Group" annotation which is meant to indicate that
> >> some properties are part of the same group, obviously.
> >> The second is an "Alternative" annotation which is meant to indicate
> >> that only one property / group of properties can be used (among the
> >> ones that are part of the alternative).
> >> Here is an example:
> >> We want for the Include macro to be able to specify either:
> >> the "reference" and "type" parameters
> >> or
> >> the "page" parameter
> >> For that, we will change the IncludeMacroParameters java class like
> this:
> >>
> >> @Alternative("reference")
> >> @Group("entityReference")
> >> public void setReference(String reference)
> >>
> >> @Alternative("reference")
> >> @Group("entityReference")
> >> public void setType(EntityType type)
> >>
> >> @Alternative("reference")
> >> public void setPage(String page)
> >>
> >> In the WYSIWYG side, we will only be able to specify either the
> >> "reference" and the "type" or the "page" parameter.
> >>
> >
> > I think it would make more sense, at least in this case, to have the
> > alternative as an attribute of the group, because semantically the
> > "entityReference" group is an alternative to the page parameter. You
> can't
> > say that the type parameter alone is an alternative to the page
> parameter.
> >
> > The @Group annotation is clear. No doubt about it. I'm not sure about
> > the @Alternative annotation. I'm thinking that the "alternative" is also
> a
> > group, where only one item from the group can be used, which could be
> > expressed with an attribute of the @Group annotation.
>
> For me the concepts of Groups and Alternatives are separate. For example
> you could imagine defining a group of properties so that the WYSIWYG would
> display them together, one under another or with some box border around
> them.
>
>

> Alternatives don’t need to be on groups.


I did not say the alternatives must be **on** groups. I said the
alternatives **are** groups. When you have two alternative parameters then
those 2 parameters are in an alternative **group**. That's what I said.
Whether the groups is used just for display or for enforcing exclusive
usage is something that could be expressed using annotation attributes.


> You can have alternatives on individual properties or alternatives between
> 1 property and a group or alternatives between one group and another.
>
> Thanks
> -Vincent
>
> [snip]
>
>
>

Re: [xwiki-devs] [Need proposal] How to show "conflicting" macro parameters

[Marius Dumitru Florea]

On Wed, Nov 7, 2018 at 5:34 PM Adel Atallah  wrote:

> Hello everyone,
>
> So what we thought about with Vincent for implementing the "concept of
> aliases or groups" would be to actually have two new annotations that
> we would use on macro properties.
> The first one is a "Group" annotation which is meant to indicate that
> some properties are part of the same group, obviously.
> The second is an "Alternative" annotation which is meant to indicate
> that only one property / group of properties can be used (among the
> ones that are part of the alternative).
> Here is an example:
> We want for the Include macro to be able to specify either:
> the "reference" and "type" parameters
> or
> the "page" parameter
> For that, we will change the IncludeMacroParameters java class like this:
>
> @Alternative("reference")
> @Group("entityReference")
> public void setReference(String reference)
>
> @Alternative("reference")
> @Group("entityReference")
> public void setType(EntityType type)
>
> @Alternative("reference")
> public void setPage(String page)
>
> In the WYSIWYG side, we will only be able to specify either the
> "reference" and the "type" or the "page" parameter.
>

I think it would make more sense, at least in this case, to have the
alternative as an attribute of the group, because semantically the
"entityReference" group is an alternative to the page parameter. You can't
say that the type parameter alone is an alternative to the page parameter.

The @Group annotation is clear. No doubt about it. I'm not sure about
the @Alternative annotation. I'm thinking that the "alternative" is also a
group, where only one item from the group can be used, which could be
expressed with an attribute of the @Group annotation.


>
> WDYT?
>
> Thanks,
> Adel
>
> On Tue, Sep 25, 2018 at 11:51 AM Marius Dumitru Florea
>  wrote:
> >
> > On Wed, Sep 19, 2018 at 4:31 PM Vincent Massol 
> wrote:
> >
> > >
> > >
> > > > On 19 Sep 2018, at 14:47, Adel Atallah 
> wrote:
> > > >
> > > > On Wed, Jul 18, 2018 at 5:00 PM Vincent Massol 
> > > wrote:
> > > >>
> > > >>
> > > >>
> > > >>> On 5 Jul 2018, at 12:06, Vincent Massol 
> wrote:
> > > >>>
> > > >>>
> > > >>>
> > > >>>> On 4 Jul 2018, at 12:07, Thomas Mortagne <
> thomas.morta...@xwiki.com>
> > > wrote:
> > > >>>>
> > > >>>> Here are more details on the actual use case we need to support:
> > > >>>>
> > > >>>> In include/Display macro either you set:
> > > >>>>
> > > >>>> * "reference" and "type" (which default to DOCUMENT)
> > > >>>> * or you set “page"
> > > >>>
> > > >>> Globally I think we need to add 3 concepts to macro parameter
> > > descriptor:
> > > >>>
> > > >>> 1) The concept of “deprecated” parameter. For example for
> “document”
> > > in the include macro.
> > > >>> 2) The concept of aliases or groups, i.e the ability to list
> > > parameters that are mutually exclusive. Example: reference + type vs
> page
> > > for display/include macros. This would mean that in the Macro Dialog
> UI if
> > > you select one of those the other gets unselected/cleared out (you
> cannot
> > > have mutually exclusive params have values).
> > > >>> 3) The concept of Advanced parameters. For example, we should put
> > > reference + type as advanced parameters so that they are not shown to
> the
> > > user by default (and so that the page parameter is more highlighted).
> Users
> > > would need to click on Advanced to see advanced parameters. I think
> we’re
> > > doing something automatic today (I don’t remember the details) to try
> to
> > > hide some parameters but we should probably review this.
> > > >>>
> > > >>> WDYT?
> > > >>
> > > >> Ping!
> > > >>
> > > >> Do we agree about this? If we do we can then create jira issue
> about it
> > > and take it for implementation.
> > > >
> > > > +1, I can create the jira issue if it's ok.
> > >
> > > Please do :)
> > >
> > >
> >
> > > @Marius: Ok for you?
> > >
> >
> > Yes.
> >
> >
> > >
> > > thanks
> > > -Vincent
> > >
> > > [snip]
> > >
> > >
> > >
>

Re: [xwiki-devs] [Proposal] Jobs for the multiple configuration testing

[Marius Dumitru Florea]

+1 for both but we need to push for more powerful CI agents. ATM the build
is faster on my laptop.

Thanks,
Marius

On Mon, Nov 5, 2018 at 6:22 PM Vincent Massol  wrote:

> Hi devs,
>
> I’m still not sure but FTM I was thinking of having 2 pipeline jobs:
>
> 1) Job 1: Execute one functional test only (e.g. MenuIT for now) but on
> the maximum number of configurations, in order to flesh out configs that
> don’t start properly. For example XWiki on Tomcat 9.x would fail (since the
> Tomcat 9.x docker image uses java9+). The job would not send a mail on
> failure but it would update a report page (could even update a page on
> xwiki.org directly or if too complex update some page on maven.xwiki.org
> somewhere). This job would run not very often but say once per week. Note
> that one config takes 3-4 minutes to run, so 50 configs would take 3 hours
> which is acceptable.
>
> 2) Job 2: Execute all functional tests on a subset of supported configs.
> For example we don’t need to run all the tests on PostgreSQL/Jetty/Chrome
> if we already run on PostgreSQL/Tomcat/FF and MySQL/Tomcat/Chrome. This job
> will take a long time to execute. We’ll start with 3-4 configs and will go
> to about 10 configs when we add more. The tests will take roughly 2 hours
> to execute per config I think. So a total of 20 hours when we have 10
> configs. If we run those once per week it should be fine.
>
> Note: Once we have job 1 & 2, we won't need to have the smoke tests I add
> as part of the platform JenkinsFile.
>
> WDYT?
>
> Thanks
> -Vincent
>
>

Re: [xwiki-devs] [Proposal] Delete all in the recycle bin

[Marius Dumitru Florea]

On Fri, Nov 2, 2018 at 1:13 PM Ecaterina Moraru (Valica) 
wrote:

> What's the difference between C2 and D?


D is about allowing the user to select the pages to delete. This means
having a checkbox on each row to be able to select it and having a Select
All / None buttons / links to select all rows or none.

C is about all or none, no custom selection.


> For me it's the same thing. You
> just used button instead of the livetable styling for actions. In D, I'm
> showed how it would look like with multiple actions, but if you remove the
> Restore, and keep just Delete All, C2 and D it's the same thing. And I
> prefer this version.
>
> Thanks,
> Caty
>
> On Fri, Nov 2, 2018 at 1:01 PM Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
>
> > If you put it in the Actions column then you need to have space for a
> > "Restore all" button or any other bulk action that we may add later. It
> > looks OK with one button but it doesn't look good IMO with two big
> buttons.
> >
> > Thanks,
> > Marius
> >
> > On Fri, Nov 2, 2018 at 12:48 PM Simon Urli  wrote:
> >
> > > Hi all,
> > >
> > > I just edited the design page to propose two variants for the place of
> > > the button in C :
> > >
> > >
> >
> https://design.xwiki.org/xwiki/bin/view/Proposal/Deleteallfromrecyclebin#HVariants
> > >
> > > Don't hesitate to give me some feedback or to propose other design.
> > >
> > > Simon
> > >
> > > On 02/11/2018 10:10, Marius Dumitru Florea wrote:
> > > > On Wed, Oct 31, 2018 at 1:19 PM Ecaterina Moraru (Valica) <
> > > vali...@gmail.com>
> > > > wrote:
> > > >
> > > >> I don't like solution C. It will not be consistent with anything and
> > > will
> > > >> look horrible.
> > > >>
> > > >
> > > > We have a few places where we have buttons above / below the live
> > table:
> > > >
> > > > * Wiki index (Create Wiki above the live table)
> > > > * Licensed Extensions (Check for Updates below the live table)
> > > > * Users Administration section (Create User below the live table)
> > > > * Groups Administration section (Create Group below the live table)
> > > > * Data Type (Create this Class above the live table)
> > > > * Class Sheet (Create this Page above the live table)
> > > >
> > > > So I don't see the problem with option C.
> > > >
> > > > Thanks,
> > > > Marius
> > > >
> > > >
> > > >>
> > > >> On Wed, Oct 31, 2018 at 10:38 AM Simon Urli 
> > > wrote:
> > > >>
> > > >>> Hi everyone,
> > > >>>
> > > >>> thanks for your answers.
> > > >>> I'll do solution C for the next release then, we can continue
> discuss
> > > >>> about D in the dedicated issue.
> > > >>>
> > > >>> Simon
> > > >>>
> > > >>> On 29/10/2018 16:23, Guillaume Delhumeau wrote:
> > > >>>> +1 for C.
> > > >>>>
> > > >>>> D could be nice but from the user perspective, I think a big
> button
> > > >> like
> > > >>>> "clear the recycle bin" is simpler than a generic "bulk" action.
> > > >>>>
> > > >>>> Le lun. 29 oct. 2018 à 15:17, Adel Atallah <
> adel.atal...@xwiki.com>
> > a
> > > >>>> écrit :
> > > >>>>
> > > >>>>> On Mon, Oct 29, 2018 at 3:09 PM Ecaterina Moraru (Valica)
> > > >>>>>  wrote:
> > > >>>>>>
> > > >>>>>> On Mon, Oct 29, 2018 at 4:06 PM Adel Atallah <
> > > adel.atal...@xwiki.com
> > > >>>
> > > >>>>> wrote:
> > > >>>>>>
> > > >>>>>>> Hello Simon,
> > > >>>>>>>
> > > >>>>>>> On Mon, Oct 29, 2018 at 2:59 PM Simon Urli <
> simon.u...@xwiki.com
> > >
> > > >>>>> wrote:
> > > >>>>>>>>
> > > >>>>>>>> Hi everyone,
> > > >>>>>>>>
> > > >>>>>>>> I'll work this month on adding the "d

Re: [xwiki-devs] [Proposal] Delete all in the recycle bin

[Marius Dumitru Florea]

If you put it in the Actions column then you need to have space for a
"Restore all" button or any other bulk action that we may add later. It
looks OK with one button but it doesn't look good IMO with two big buttons.

Thanks,
Marius

On Fri, Nov 2, 2018 at 12:48 PM Simon Urli  wrote:

> Hi all,
>
> I just edited the design page to propose two variants for the place of
> the button in C :
>
> https://design.xwiki.org/xwiki/bin/view/Proposal/Deleteallfromrecyclebin#HVariants
>
> Don't hesitate to give me some feedback or to propose other design.
>
> Simon
>
> On 02/11/2018 10:10, Marius Dumitru Florea wrote:
> > On Wed, Oct 31, 2018 at 1:19 PM Ecaterina Moraru (Valica) <
> vali...@gmail.com>
> > wrote:
> >
> >> I don't like solution C. It will not be consistent with anything and
> will
> >> look horrible.
> >>
> >
> > We have a few places where we have buttons above / below the live table:
> >
> > * Wiki index (Create Wiki above the live table)
> > * Licensed Extensions (Check for Updates below the live table)
> > * Users Administration section (Create User below the live table)
> > * Groups Administration section (Create Group below the live table)
> > * Data Type (Create this Class above the live table)
> > * Class Sheet (Create this Page above the live table)
> >
> > So I don't see the problem with option C.
> >
> > Thanks,
> > Marius
> >
> >
> >>
> >> On Wed, Oct 31, 2018 at 10:38 AM Simon Urli 
> wrote:
> >>
> >>> Hi everyone,
> >>>
> >>> thanks for your answers.
> >>> I'll do solution C for the next release then, we can continue discuss
> >>> about D in the dedicated issue.
> >>>
> >>> Simon
> >>>
> >>> On 29/10/2018 16:23, Guillaume Delhumeau wrote:
> >>>> +1 for C.
> >>>>
> >>>> D could be nice but from the user perspective, I think a big button
> >> like
> >>>> "clear the recycle bin" is simpler than a generic "bulk" action.
> >>>>
> >>>> Le lun. 29 oct. 2018 à 15:17, Adel Atallah  a
> >>>> écrit :
> >>>>
> >>>>> On Mon, Oct 29, 2018 at 3:09 PM Ecaterina Moraru (Valica)
> >>>>>  wrote:
> >>>>>>
> >>>>>> On Mon, Oct 29, 2018 at 4:06 PM Adel Atallah <
> adel.atal...@xwiki.com
> >>>
> >>>>> wrote:
> >>>>>>
> >>>>>>> Hello Simon,
> >>>>>>>
> >>>>>>> On Mon, Oct 29, 2018 at 2:59 PM Simon Urli 
> >>>>> wrote:
> >>>>>>>>
> >>>>>>>> Hi everyone,
> >>>>>>>>
> >>>>>>>> I'll work this month on adding the "delete all" functionality in
> >> the
> >>>>>>>> recycle bin.
> >>>>>>>> However I'd like to have your opinion on how it should looks like
> >> for
> >>>>>>>> the users.
> >>>>>>>> I have at least 4 proposals that I detailed there:
> >>>>>>>>
> >>>>>
> >>>
> https://design.xwiki.org/xwiki/bin/view/Proposal/Deleteallfromrecyclebin
> >>>>>>>>
> >>>>>>>> The 4 proposal are numbered as following:
> >>>>>>>>
> >>>>>>>>  A. A simple button
> >>>>>>> -1
> >>>>>>>>  B. A simple button with a checkbox to activate it
> >>>>>>> -0 as it feels a bit weird.
> >>>>>>>>  C. A button and a modal to confirm the action
> >>>>>>> +1
> >>>>>>>>  D. A generic bulk action on the livetable
> >>>>>>>
> >>>>>>
> >>>>>> +1 for D. but since it involves multiple documents, we will also
> >> need a
> >>>>>> confirmation for these actions. So the solution would be a mix
> >> between
> >>>>> D. +
> >>>>>> C.
> >>>>>> If we implement D. we will have the base for multiple other use
> >> cases,
> >>>>>> since this needs is recurrent.
> >>>>>
> >>>>> It would be great to list the possible use cases to see if the
> >>>>> development of this feature is worth the effort. For now, the only
> use
> >>>>> case that comes to my mind is for the deletion action.
> >>>>>
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Caty
> >>>>>>
> >>>>>>
> >>>>>>> +1, this is probably the best solution but also more complicated to
> >>> do.
> >>>>>>>>
> >>>>>>>> Thanks in advance for your feedbacks.
> >>>>>>>>
> >>>>>>>> Simon
> >>>>>>>> --
> >>>>>>>> Simon Urli
> >>>>>>>> Software Engineer at XWiki SAS
> >>>>>>>> simon.u...@xwiki.com
> >>>>>>>> More about us at http://www.xwiki.com
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Adel
> >>>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>> --
> >>> Simon Urli
> >>> Software Engineer at XWiki SAS
> >>> simon.u...@xwiki.com
> >>> More about us at http://www.xwiki.com
> >>>
> >>
>
> --
> Simon Urli
> Software Engineer at XWiki SAS
> simon.u...@xwiki.com
> More about us at http://www.xwiki.com
>

Re: [xwiki-devs] [Proposal] Delete all in the recycle bin

[Marius Dumitru Florea]

On Wed, Oct 31, 2018 at 1:19 PM Ecaterina Moraru (Valica) 
wrote:

> I don't like solution C. It will not be consistent with anything and will
> look horrible.
>

We have a few places where we have buttons above / below the live table:

* Wiki index (Create Wiki above the live table)
* Licensed Extensions (Check for Updates below the live table)
* Users Administration section (Create User below the live table)
* Groups Administration section (Create Group below the live table)
* Data Type (Create this Class above the live table)
* Class Sheet (Create this Page above the live table)

So I don't see the problem with option C.

Thanks,
Marius


>
> On Wed, Oct 31, 2018 at 10:38 AM Simon Urli  wrote:
>
> > Hi everyone,
> >
> > thanks for your answers.
> > I'll do solution C for the next release then, we can continue discuss
> > about D in the dedicated issue.
> >
> > Simon
> >
> > On 29/10/2018 16:23, Guillaume Delhumeau wrote:
> > > +1 for C.
> > >
> > > D could be nice but from the user perspective, I think a big button
> like
> > > "clear the recycle bin" is simpler than a generic "bulk" action.
> > >
> > > Le lun. 29 oct. 2018 à 15:17, Adel Atallah  a
> > > écrit :
> > >
> > >> On Mon, Oct 29, 2018 at 3:09 PM Ecaterina Moraru (Valica)
> > >>  wrote:
> > >>>
> > >>> On Mon, Oct 29, 2018 at 4:06 PM Adel Atallah  >
> > >> wrote:
> > >>>
> >  Hello Simon,
> > 
> >  On Mon, Oct 29, 2018 at 2:59 PM Simon Urli 
> > >> wrote:
> > >
> > > Hi everyone,
> > >
> > > I'll work this month on adding the "delete all" functionality in
> the
> > > recycle bin.
> > > However I'd like to have your opinion on how it should looks like
> for
> > > the users.
> > > I have at least 4 proposals that I detailed there:
> > >
> > >>
> > https://design.xwiki.org/xwiki/bin/view/Proposal/Deleteallfromrecyclebin
> > >
> > > The 4 proposal are numbered as following:
> > >
> > > A. A simple button
> >  -1
> > > B. A simple button with a checkbox to activate it
> >  -0 as it feels a bit weird.
> > > C. A button and a modal to confirm the action
> >  +1
> > > D. A generic bulk action on the livetable
> > 
> > >>>
> > >>> +1 for D. but since it involves multiple documents, we will also
> need a
> > >>> confirmation for these actions. So the solution would be a mix
> between
> > >> D. +
> > >>> C.
> > >>> If we implement D. we will have the base for multiple other use
> cases,
> > >>> since this needs is recurrent.
> > >>
> > >> It would be great to list the possible use cases to see if the
> > >> development of this feature is worth the effort. For now, the only use
> > >> case that comes to my mind is for the deletion action.
> > >>
> > >>>
> > >>> Thanks,
> > >>> Caty
> > >>>
> > >>>
> >  +1, this is probably the best solution but also more complicated to
> > do.
> > >
> > > Thanks in advance for your feedbacks.
> > >
> > > Simon
> > > --
> > > Simon Urli
> > > Software Engineer at XWiki SAS
> > > simon.u...@xwiki.com
> > > More about us at http://www.xwiki.com
> > 
> >  Thanks,
> >  Adel
> > 
> > >>
> > >
> > >
> >
> > --
> > Simon Urli
> > Software Engineer at XWiki SAS
> > simon.u...@xwiki.com
> > More about us at http://www.xwiki.com
> >
>

Re: [xwiki-devs] [Proposal] Update servlet container support strategy

[Marius Dumitru Florea]

+1

Thanks,
Marius

On Wed, Oct 31, 2018 at 11:04 AM Vincent Massol  wrote:

> Hi devs,
>
> We now have
> https://dev.xwiki.org/xwiki/bin/view/Community/ServletContainerSupportStrategy/
> but it’s not precise enough.
>
> I’m proposing the following:
>
> * Mention the supported version cycle and mention that we support the
> latest version of the cycle.
> * For Tomcat, I propose to say we support Tomcat 8.x (which means Tomcat
> 8.5.34 as of today, see “latest” tag on https://hub.docker.com/_/tomcat/)
> * For Jetty (standalone packaging or standard), I propose to say we
> support Jetty 9.x (which means Jetty 9.4.12 as of today, see “latest” tag
> on https://hub.docker.com/_/jetty/)
>
> WDYT?
>
> Thanks
> -Vincent
>
>
>

[xwiki-devs] [ANN] XWiki 10.9 released

[Marius Dumitru Florea]

The XWiki development team is proud to announce the availability of XWiki
10.9.

Starting with this release the Activity Stream Application is fully
replaced by the Notifications Application. The list of followed users is
back in the user profile and the Page Index can be sorted by page title.
The Users and Groups administrations sections have been improved and
there's a new Page Picker Velocity macro that can be used by developers.

You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download

Make sure to review the release notes:
https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/10.9/

Thanks for your support
-The XWiki dev team

Re: [xwiki-devs] [Proposal] Delete all in the recycle bin

[Marius Dumitru Florea]

I would start with C. We can do D later.

On Mon, Oct 29, 2018 at 3:59 PM Simon Urli  wrote:

> Hi everyone,
>
> I'll work this month on adding the "delete all" functionality in the
> recycle bin.
> However I'd like to have your opinion on how it should looks like for
> the users.
> I have at least 4 proposals that I detailed there:
> https://design.xwiki.org/xwiki/bin/view/Proposal/Deleteallfromrecyclebin
>
> The 4 proposal are numbered as following:
>
>A. A simple button
>B. A simple button with a checkbox to activate it
>C. A button and a modal to confirm the action
>D. A generic bulk action on the livetable
>
> Thanks in advance for your feedbacks.
>
> Simon
> --
> Simon Urli
> Software Engineer at XWiki SAS
> simon.u...@xwiki.com
> More about us at http://www.xwiki.com
>

Re: [xwiki-devs] [Proposal] Move Doxia-based syntaxes in contrib

[Marius Dumitru Florea]

+0

Thanks,
Marius

On Sat, Oct 27, 2018 at 3:01 PM Vincent Massol  wrote:

> Hi,
>
> In the direction of keeping in commons/rendering/platform only modules
> that are used in the XS distribution, I’m proposing to move Doxia-based
> syntaxes to contrib (APT, Docbook & TWiki), in a single doxia github
> repository (doxia-common, doxia-twiki, doxia-docbook, doxia-twiki).
>
> WDYT?
>
> Thanks
> -Vincent
>
>

Re: [xwiki-devs] [release] 10.9RC1 skipped

[Marius Dumitru Florea]

On Thu, Oct 25, 2018 at 12:23 PM Vincent Massol  wrote:

> Ok, thanks Marius.
>
> Consequences:
> * the "@since 10.9RC1" need to be modified in the source code.
>

Done.


> * the jira version 10.9RC1 needs to be deleted and issues moved too
>

Done.


> * the RN page for 10.9RC1 and the RP one need to be moved/deleted/recreated
>

Done.


> * more?
>

I created the stable-10.9.x branches. Master is now 10.10-SNAPSHOT.


>
> Thanks
> -Vincent
>
>
> > On 25 Oct 2018, at 10:56, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
> >
> > Hi devs,
> >
> > It took us a lot of time to stabilize the build and now we're too late to
> > release 10.9RC1 (was planned 4 days ago) so I'm going to skip 10.9RC1 and
> > release directly 10.9 instead, next Monday (29th of October).
> >
> > Thanks,
> > Marius
>
>

[xwiki-devs] [release] 10.9RC1 skipped

[Marius Dumitru Florea]

Hi devs,

It took us a lot of time to stabilize the build and now we're too late to
release 10.9RC1 (was planned 4 days ago) so I'm going to skip 10.9RC1 and
release directly 10.9 instead, next Monday (29th of October).

Thanks,
Marius

Re: [xwiki-devs] What do we do with Watchlist and Activity Stream

[Marius Dumitru Florea]

On Mon, Oct 22, 2018 at 4:14 PM Guillaume Delhumeau <
guillaume.delhum...@xwiki.com> wrote:

> Hi.
>
> For 10.9RC1, my objective was to stop bundling the Activity Stream UI in
> the default flavor. Several months before, I did the same with the
> Watchlist. Now both of them are replaced by Notifications.
>
> Even if they are not bundled anymore by default, I have let the modules in
> the "platform" repository. The idea was to maintain them until 11.x is
> started (while we stabilize notifications), and to move them in "attic" at
> the beginning of next year.
>
> Recently, while removing Activity Stream calls in our wiki pages, I
> discovered some code in the User Profile that was handling both Activity
> Stream and the Watchlist. I removed it, since it was handling deprecated
> code. But maybe I should have not, since the modules are not moved into the
> "attic" repository yet. Anyway, it is not clean to have special code for AS
> and Watchlist in the User Profile module, we need to create a proper
> mechanism to inject code into the user profile (see:
> https://jira.xwiki.org/browse/XWIKI-12639).
>
> The removing of the code has broken some functional tests in the watchlist
> module, that were precisely testing this code. So now, we have several
> options:
>
>

> A - Put back the code I have removed, until Activity Stream UI and
> Watchlist are moved outside the "platform" repository. So the build would
> be fixed.
>

+1 to do this for 10.9RC1 and we can continue the discussion afterwards
(decide between A+B or C for 10.10).

Thanks,
Marius


> B - Remove the failing functional test since it is testing a code we have
> been removed. So the build would be fixed.
> C - Put back the code I have removed, but inside the Watchlist module and
> injected into the User profile via a clean injection system (again:
> https://jira.xwiki.org/browse/XWIKI-12639). The build would be fixed but
> it
> requires more time to develop, and we risk to miss 10.9RC1.
>
> The release of 10.9RC1 is already late, so what do you think is the best
> option?
>
> Thanks,
>
> --
> Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
> Research & Development Engineer at XWiki SAS
> Committer on the XWiki.org project
>

Re: [xwiki-devs] [Best Practice] Use lowercase for JIRA labels

[Marius Dumitru Florea]

+0, I would have preferred camel case for composite names (like
bugfixingday)

On Mon, Oct 22, 2018 at 4:17 PM Vincent Massol  wrote:

> Hi,
>
> I’d like to propose to use a consistent naming scheme for jira labels and
> use lowercase (and fix all the upper case we can find).
>
> Ok for everyone?
>
> Thanks
> -Vincent
>
>

Re: [xwiki-devs] [UX][Proposal] Distribution Wizard: Never Button

[Marius Dumitru Florea]

Both VAR1 and VAR2 look good to me.

Thanks,
Marius

On Wed, Oct 17, 2018 at 5:49 PM Ecaterina Moraru (Valica) 
wrote:

> Hi devs,
>
> This is an improvements proposal for the "Never" button from Distribution
> Wizard.
> https://design.xwiki.org/xwiki/bin/view/Proposal/Upgrade/DWNeverButton/
>
> I've listed several variants of fixing the usability issue, let me know
> which one is your favorite.
>
> My +1 goes to VAR2: Confirmation; with minimum we can do being VAR1:
> Location.
>
> Thanks,
> Caty
>

Re: [xwiki-devs] [Proposal] Change ObservationManager behaviour with CancelableEvents

[Marius Dumitru Florea]

An use case is to be able to log all the events that happen in XWiki. It
would be stupid to not be able to log an event because there's another
event listener that cancels the event before.

On Wed, Oct 17, 2018 at 3:21 PM Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> -0. I would be OK to stop the event propagation if the list of event
> listeners were *ordered* but AFAIK there's no order between event
> listeners ATM. It should always be possible to catch an event, even if that
> event is going to be canceled by some other listener:
>
> * either by registering an event listener with higher priority than the
> one canceling the event
> * or by not stopping the event propagation and letting each listener
> decide what to do based on the canceled state of the event
>
> For instance, DOM events have this
> https://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow-capture
>
> If the capturing EventListener
>> <https://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventListener>
>> wishes to prevent further processing of the event from occurring it may
>> call the stopProgagation method of the Event
>> <https://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Event>
>> interface. This will prevent further dispatch of the event, although
>> additional EventListeners
>> <https://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventListener>
>> registered at the same hierarchy level will still receive the event.
>>
>
> So you can always catch the DOM event by registering the event listener on
> the element that triggers the event (rather than on one of its parents).
>
> Thanks,
> Marius
>
>
> On Tue, Oct 16, 2018 at 7:07 PM Simon Urli  wrote:
>
>> Hi everyone,
>>
>> the current behaviour of the ObservationManager is to always triggers
>> the listeners if it matches the events.
>> Now regarding the CancelableEvents, the match is only done on the type
>> of the event and some given filter rules, but never with its cancel
>> status: if an event is cancelled, the matching listeners are always
>> triggered.
>>
>> I propose to change that behaviour, to trigger listeners only if the
>> CancelableEvents are not canceled: basically, a cancelled event wouldn't
>> match any listener.
>>
>> My primary reason for wanting that change is that the current behaviour
>> led to a bad UX: if an event triggers multiple questions, no matter if
>> one is cancelled, all questions will be asked to the user.
>>
>> Do you know if the current behaviour is required at some places?
>> Else do you agree on changing it?
>>
>> Simon
>> --
>> Simon Urli
>> Software Engineer at XWiki SAS
>> simon.u...@xwiki.com
>> More about us at http://www.xwiki.com
>>
>

Re: [xwiki-devs] [Proposal] Change ObservationManager behaviour with CancelableEvents

[Marius Dumitru Florea]

-0. I would be OK to stop the event propagation if the list of event
listeners were *ordered* but AFAIK there's no order between event listeners
ATM. It should always be possible to catch an event, even if that event is
going to be canceled by some other listener:

* either by registering an event listener with higher priority than the one
canceling the event
* or by not stopping the event propagation and letting each listener decide
what to do based on the canceled state of the event

For instance, DOM events have this
https://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow-capture

If the capturing EventListener
> 
> wishes to prevent further processing of the event from occurring it may
> call the stopProgagation method of the Event
> 
> interface. This will prevent further dispatch of the event, although
> additional EventListeners
> 
> registered at the same hierarchy level will still receive the event.
>

So you can always catch the DOM event by registering the event listener on
the element that triggers the event (rather than on one of its parents).

Thanks,
Marius


On Tue, Oct 16, 2018 at 7:07 PM Simon Urli  wrote:

> Hi everyone,
>
> the current behaviour of the ObservationManager is to always triggers
> the listeners if it matches the events.
> Now regarding the CancelableEvents, the match is only done on the type
> of the event and some given filter rules, but never with its cancel
> status: if an event is cancelled, the matching listeners are always
> triggered.
>
> I propose to change that behaviour, to trigger listeners only if the
> CancelableEvents are not canceled: basically, a cancelled event wouldn't
> match any listener.
>
> My primary reason for wanting that change is that the current behaviour
> led to a bad UX: if an event triggers multiple questions, no matter if
> one is cancelled, all questions will be asked to the user.
>
> Do you know if the current behaviour is required at some places?
> Else do you agree on changing it?
>
> Simon
> --
> Simon Urli
> Software Engineer at XWiki SAS
> simon.u...@xwiki.com
> More about us at http://www.xwiki.com
>

Re: [xwiki-devs] Proposal for Macro inline edition

[Marius Dumitru Florea]

On Tue, Oct 9, 2018 at 3:22 PM Thomas Mortagne 
wrote:

> On Tue, Oct 9, 2018 at 1:53 PM Marius Dumitru Florea
>  wrote:
> >
> > On Mon, Oct 8, 2018 at 11:20 AM Thomas Mortagne <
> thomas.morta...@xwiki.com>
> > wrote:
> >
> > > On Fri, Oct 5, 2018 at 6:05 PM Marius Dumitru Florea
> > >  wrote:
> > > >
> > > > Thomas, I'm looking at how the editor can save the macro content
> edited
> > > > in-line and there are two options I think:
> > > >
> > > > (1) The editor does a separate request to a dedicated service to
> convert
> > > > the macro content from HTML, before the entire page content is saved
> > > > (2) The editor marks the macro calls that need to be converted and
> the
> > > > conversion is done when the entire page content is converted
> > > >
> > > > I think the second option makes more sense. We already convert the
> page
> > > > content from HTML to wiki syntax. We could also convert the macro
> content
> > > > in the same flow, if needed.
> > > >
> > > > Note that we can't do the conversion of the macro content every time
> the
> > > > page content is converted. We need to convert the macro content from
> HTML
> > > > only if the editor says that is has been edited in-line. There are at
> > > least
> > > > 2 cases when the conversion is not needed:
> > > >
> > > > * when your insert a gadget in the dashboard (it uses the same Macro
> > > Insert
> > > > wizard from CKEditor)
> > > > * when the macro outputs in-line content, since the CKEditor doesn't
> > > > properly support editing in-line widgets in-place (see my other mail)
> > > >
> > > > So we need away to mark the macro calls that need conversion. The
> macro
> > > > marker supports only macro name, parameters and content. One idea is
> to
> > > use
> > > > some "reserved" parameter, such as "__requiresHTMLConversion".
> > > >
> > > > WDYT?
> > >
> > > Yes +1 for (2), that's the safest and what makes the most sense anyway.
> > >
> > > For the marker I'm not a big fan of the parameter but hard to find a
> > > retro compatible syntax otherwise (we should have put keywords in the
> > > initial annotation syntax instead of just the ordered values...).
> > >
> > >
> >
> > > Now a marker is not enough, you also need to indicate the target
> > > syntax (the html parser might now know it) in which it needs to be
> > > converted.
> >
> >
> > I was thinking that the parser (or some filter before the parser is
> called)
> > could use the SyntaxDescriptor component from
> > https://github.com/xwiki/xwiki-rendering/pull/145/files to determine the
> > target syntax for the macro content based on the macro parameters.
> > Indicating the syntax in the macro call is OK as long as the syntax is
> > static and the editor gets it from the meta data attributes. But if the
> > content syntax depends on the macro parameters then the editor needs to
> > make a request to compute the syntax each time the macro parameters are
> > modified.
>
> SyntaxDescriptor is useless, knowing the macro won't give you the
> syntax in many cases since you need the current syntax in a given
> context. But yes for very standard macros this could be found in the
> context and previous metadata blocks (provided the user did not
> removed a metadata block by mistake, I guess the WYSIWYG could have
> some protection against that).
>
> My point was more about future custom inline editors we talked about
> for which it would be much easier if they can explicitly give the
> information if there is a transformation need.
>
> >
> > Also we need something which support parameters conversion
> > > too since it's planned.
> >
> >
> > I agree.
> >
> >
> > > Finally I think I would prefer something even
> > > more collision proof.
> > >
> > > For example:
> > >
> > > [[convert:__content]]=xwiki/2.1
> > > param1="toto" [[convert:param1]]="xwiki/2.1"
> > >
> > > or
> > >
> > > [[convert:xwiki/2.1:__content]]="" ("" is just ignored, probably
> > > better to make the html parser support not having a value at all which
> > > might already be the case, I don't remember)
> > > [[conve

Re: [xwiki-devs] Proposal for Macro inline edition

[Marius Dumitru Florea]

On Mon, Oct 8, 2018 at 11:20 AM Thomas Mortagne 
wrote:

> On Fri, Oct 5, 2018 at 6:05 PM Marius Dumitru Florea
>  wrote:
> >
> > Thomas, I'm looking at how the editor can save the macro content edited
> > in-line and there are two options I think:
> >
> > (1) The editor does a separate request to a dedicated service to convert
> > the macro content from HTML, before the entire page content is saved
> > (2) The editor marks the macro calls that need to be converted and the
> > conversion is done when the entire page content is converted
> >
> > I think the second option makes more sense. We already convert the page
> > content from HTML to wiki syntax. We could also convert the macro content
> > in the same flow, if needed.
> >
> > Note that we can't do the conversion of the macro content every time the
> > page content is converted. We need to convert the macro content from HTML
> > only if the editor says that is has been edited in-line. There are at
> least
> > 2 cases when the conversion is not needed:
> >
> > * when your insert a gadget in the dashboard (it uses the same Macro
> Insert
> > wizard from CKEditor)
> > * when the macro outputs in-line content, since the CKEditor doesn't
> > properly support editing in-line widgets in-place (see my other mail)
> >
> > So we need away to mark the macro calls that need conversion. The macro
> > marker supports only macro name, parameters and content. One idea is to
> use
> > some "reserved" parameter, such as "__requiresHTMLConversion".
> >
> > WDYT?
>
> Yes +1 for (2), that's the safest and what makes the most sense anyway.
>
> For the marker I'm not a big fan of the parameter but hard to find a
> retro compatible syntax otherwise (we should have put keywords in the
> initial annotation syntax instead of just the ordered values...).
>
>

> Now a marker is not enough, you also need to indicate the target
> syntax (the html parser might now know it) in which it needs to be
> converted.


I was thinking that the parser (or some filter before the parser is called)
could use the SyntaxDescriptor component from
https://github.com/xwiki/xwiki-rendering/pull/145/files to determine the
target syntax for the macro content based on the macro parameters.
Indicating the syntax in the macro call is OK as long as the syntax is
static and the editor gets it from the meta data attributes. But if the
content syntax depends on the macro parameters then the editor needs to
make a request to compute the syntax each time the macro parameters are
modified.

Also we need something which support parameters conversion
> too since it's planned.


I agree.


> Finally I think I would prefer something even
> more collision proof.
>
> For example:
>
> [[convert:__content]]=xwiki/2.1
> param1="toto" [[convert:param1]]="xwiki/2.1"
>
> or
>
> [[convert:xwiki/2.1:__content]]="" ("" is just ignored, probably
> better to make the html parser support not having a value at all which
> might already be the case, I don't remember)
> [[convert:xwiki/2.1:param1]]="toto"
>

Both look fine (with a slightly preference towards the first option) but
I'm not convinced we need to specify the syntax. The parser has the macro
call so it knows the macro and the parameter values so it could determine
the syntax.


>
> >
> > On Wed, Oct 3, 2018 at 6:42 PM Marius Dumitru Florea <
> > mariusdumitru.flo...@xwiki.com> wrote:
> >
> > > Hi everyone,
> > >
> > > I've started implementing this on the WYSIWYG editor side and there are
> > > two constraints that we need to be aware:
> > >
> > >
> > > (1) Macro#supportsInlineMode() must be false
> > >
> > > The CKEditor handles macros as widgets
> > > <
> https://ckeditor.com/docs/ckeditor4/latest/guide/widget_sdk_intro.html>
> > > and widgets can have nested editable parts, which is great, BUT these
> > > nested editable parts must have a block-level element as parent. The
> list
> > > of elements that are accepted as in place editing hosts can be found
> here
> > >
> https://ckeditor.com/docs/ckeditor4/latest/api/CKEDITOR_dtd.html#property-S-editable
> > > . This means that only block-level widgets can be edited in place. As a
> > > consequence, only block-level macros can be edited in place. There's an
> > > open issue about this
> https://github.com/ckeditor/ckeditor-dev/issues/1091
> > > but I can't tell if it's going to be fixed soon or not.
> > >
> &g

Re: [xwiki-devs] Proposal for Macro inline edition

[Marius Dumitru Florea]

Thomas, I'm looking at how the editor can save the macro content edited
in-line and there are two options I think:

(1) The editor does a separate request to a dedicated service to convert
the macro content from HTML, before the entire page content is saved
(2) The editor marks the macro calls that need to be converted and the
conversion is done when the entire page content is converted

I think the second option makes more sense. We already convert the page
content from HTML to wiki syntax. We could also convert the macro content
in the same flow, if needed.

Note that we can't do the conversion of the macro content every time the
page content is converted. We need to convert the macro content from HTML
only if the editor says that is has been edited in-line. There are at least
2 cases when the conversion is not needed:

* when your insert a gadget in the dashboard (it uses the same Macro Insert
wizard from CKEditor)
* when the macro outputs in-line content, since the CKEditor doesn't
properly support editing in-line widgets in-place (see my other mail)

So we need away to mark the macro calls that need conversion. The macro
marker supports only macro name, parameters and content. One idea is to use
some "reserved" parameter, such as "__requiresHTMLConversion".

WDYT?

On Wed, Oct 3, 2018 at 6:42 PM Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> Hi everyone,
>
> I've started implementing this on the WYSIWYG editor side and there are
> two constraints that we need to be aware:
>
>
> (1) Macro#supportsInlineMode() must be false
>
> The CKEditor handles macros as widgets
> <https://ckeditor.com/docs/ckeditor4/latest/guide/widget_sdk_intro.html>
> and widgets can have nested editable parts, which is great, BUT these
> nested editable parts must have a block-level element as parent. The list
> of elements that are accepted as in place editing hosts can be found here
> https://ckeditor.com/docs/ckeditor4/latest/api/CKEDITOR_dtd.html#property-S-editable
> . This means that only block-level widgets can be edited in place. As a
> consequence, only block-level macros can be edited in place. There's an
> open issue about this https://github.com/ckeditor/ckeditor-dev/issues/1091
> but I can't tell if it's going to be fixed soon or not.
>
> What options do we have?
>
> (a) enable in place editing only for macros that have supportsInlineMode
> false; that's the easiest but it excludes from the start macros such as
> info, error, warning, which is a pity.
> (b) activate in place editing only when the macro generates block level
> content; this means that the users will be able to edit in place a warning
> macro that is standalone, such as:
>
> -8<-
> before
>
> {{warning}}message{{/warning}}
>
> after
> ->8-
>
> but not a warning macro that is inside some paragraph text, such as:
>
> -8<-
> before {{warning}}message{{/warning}} after
> ->8-
>
> The issue is that we don't always know if the macro output is block-level
> until we render the macro so hiding the macro content text area when
> inserting a macro is not easy.
>
> (c) Try to implement https://github.com/ckeditor/ckeditor-dev/issues/1091
> ourselves, but I don't think it's easy
> (d) Don't use widgets to support macros and implement something custom. I
> think this is crazy.
>
>
> (2) The second constraint is that the macro content must not be mandatory.
>
> ATM both {{info/}} and {{info}}{{/info}} generate "The required content is
> missing." and so do the other macros I've tested. So it seems there's no
> distinction between empty content and no content at the implementation
> level. Thus, if we want to hide the macro content text area when inserting
> a macro such as {{info}} then we need to make the macro content optional.
> Either by changing the macro descriptor or by changing the implementation
> to differentiate the empty content from no content specified.
>
> Thanks,
> Marius
>
>
> On Mon, Sep 10, 2018 at 2:05 PM Simon Urli  wrote:
>
>> Hi everyone,
>>
>> I'm working on the roadmap issues related to the inline edition with
>> WYSIWYG editor for macro content and macro parameters.
>>
>> The first step is to add a flag to allow user specify that a content or
>> a parameter can be edited inline with the WYSIWYG editor.
>>
>> The second step is to allow the CKEditor to detect where the content
>> and/or parameters should be edited.
>> Let's take the exampe of a simple macro without any parameter, which
>> currently produces this code:
>>
>> 
>>
>>  
>>  some ti

Re: [xwiki-devs] Proposal for Macro inline edition

[Marius Dumitru Florea]

Hi everyone,

I've started implementing this on the WYSIWYG editor side and there are two
constraints that we need to be aware:


(1) Macro#supportsInlineMode() must be false

The CKEditor handles macros as widgets

and widgets can have nested editable parts, which is great, BUT these
nested editable parts must have a block-level element as parent. The list
of elements that are accepted as in place editing hosts can be found here
https://ckeditor.com/docs/ckeditor4/latest/api/CKEDITOR_dtd.html#property-S-editable
. This means that only block-level widgets can be edited in place. As a
consequence, only block-level macros can be edited in place. There's an
open issue about this https://github.com/ckeditor/ckeditor-dev/issues/1091
but I can't tell if it's going to be fixed soon or not.

What options do we have?

(a) enable in place editing only for macros that have supportsInlineMode
false; that's the easiest but it excludes from the start macros such as
info, error, warning, which is a pity.
(b) activate in place editing only when the macro generates block level
content; this means that the users will be able to edit in place a warning
macro that is standalone, such as:

-8<-
before

{{warning}}message{{/warning}}

after
->8-

but not a warning macro that is inside some paragraph text, such as:

-8<-
before {{warning}}message{{/warning}} after
->8-

The issue is that we don't always know if the macro output is block-level
until we render the macro so hiding the macro content text area when
inserting a macro is not easy.

(c) Try to implement https://github.com/ckeditor/ckeditor-dev/issues/1091
ourselves, but I don't think it's easy
(d) Don't use widgets to support macros and implement something custom. I
think this is crazy.


(2) The second constraint is that the macro content must not be mandatory.

ATM both {{info/}} and {{info}}{{/info}} generate "The required content is
missing." and so do the other macros I've tested. So it seems there's no
distinction between empty content and no content at the implementation
level. Thus, if we want to hide the macro content text area when inserting
a macro such as {{info}} then we need to make the macro content optional.
Either by changing the macro descriptor or by changing the implementation
to differentiate the empty content from no content specified.

Thanks,
Marius


On Mon, Sep 10, 2018 at 2:05 PM Simon Urli  wrote:

> Hi everyone,
>
> I'm working on the roadmap issues related to the inline edition with
> WYSIWYG editor for macro content and macro parameters.
>
> The first step is to add a flag to allow user specify that a content or
> a parameter can be edited inline with the WYSIWYG editor.
>
> The second step is to allow the CKEditor to detect where the content
> and/or parameters should be edited.
> Let's take the exampe of a simple macro without any parameter, which
> currently produces this code:
>
> 
>
>  
>  some title
>
>Some content
> 
>
> We propose (me & Marius) to ask users to add a wrapper with a specific
> class around the content to tell the editor it should only allow editing
> this content, e.g.:
>
> 
>
>  
>  some title
>
>Some content
> 
>
> About parameters, our idea was to define a new metadata attribute and to
> ask users to use it for specifying the content is editable, such as for
> a parameter named foo:
>
> my foo parameter
> value
>
> However I don't know right now how the editor would manage cases such as:
> Some content with  class="editable-content" data-parameter="myparameter">a
> parameter
>
> So:
>1. Do you agree on the usage of a class named "editable-content"
> which would be used as a tag to allow inline edition?
>2. WDYT about using a data-parameter and this class for inline
> editing of parameters?
>
> Thanks,
> Simon
> --
> Simon Urli
> Software Engineer at XWiki SAS
> simon.u...@xwiki.com
> More about us at http://www.xwiki.com
>

Re: [xwiki-devs] [Proposal] Improve our Test Coverage strategy (TAKE 2)

[Marius Dumitru Florea]

Sounds good. +1

Thanks,
Marius

On Wed, Oct 3, 2018 at 11:56 AM Vincent Massol  wrote:

> Hi devs,
>
> We started discussing a first global test coverage strategy in
> https://markmail.org/message/grphwta63pp5p4l7
>
> I’d like to propose some updates and tuning now that we have a Clover
> Jenkins pipeline working (brainstormed with Simon):
>
> Here’s the new proposal:
>
> * We run the Clover Jenkins pipeline every night (between 11PM-8AM)
> * The pipeline sends an email whenever the new report has modules lowering
> the global TPC score compared to the baseline report (negative contribution
> per module)
> * The baseline report is the report generated just after each XS release.
> This means that we keep the same baseline during a XS release
> ** Technically it means that the pipeline will update the latest.txt file
> (which contains the clover report timestamp) when it notices a version
> change
> * We add a step in the Release Plan Template to have the report passing
> before we can release.
> * The RM is in charge of a release from day 1 to the release day (already
> the case), and is also in charge of making sure that the global coverage
> job failures get addressed before the release day so that we’re ready on
> the release day.
>
> Options:
> * Make it easier and only fail the pipeline job when the global TPC value
> is lower than the baseline (vs failing whenever a module has negative
> contribution)
>
> WDYT?
>
> Thanks
> -Vincent
>
>

Re: [xwiki-devs] [Brainstorming] "Code" subspace for apps

[Marius Dumitru Florea]

+1 to not require the Code space if the application doesn't have pages that
are meant to be accessed directly. For instance, I don't see the need for
the Code space on an application that:

* has all its pages hidden (all are technical pages)
* the application defines a macro that is listed on the macro index and on
the WYSIWYG editor
* the application defines an administration section available in the wiki
administration
* the application extends the XWIki UI through an extension point
* etc.

I really don't see why I would need to put the CKEditor code in
CKEditor.Code when there's no page in the CKEditor Integration application
that is meant to be accessed by the users.

Thanks,
Marius

On Thu, Sep 27, 2018 at 5:04 PM Vincent Massol  wrote:

> Hi devs,
>
> I’ve just had a quick chat with Edy and I found that we had a difference
> of opinion on the Code subspace practice.
>
> On
> https://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPractices
> we say:
> "Technical pages must be put in a subspace named Code”
>
> Now Edy says that this should be done only for data-generating apps.
>
> It’s not my recollection that this rule was only for this case and this is
> what I’d like to discuss here.
>
> For example, I’ve noticed that ActiveInstalls has all technical pages
> under ActiveInstalls, see
>
> https://github.com/xwiki/xwiki-platform/tree/053f0a2757cea18a5916632a58c6046ba61954cd/xwiki-platform-core/xwiki-platform-activeinstalls/xwiki-platform-activeinstalls-server/xwiki-platform-activeinstalls-server-ui/src/main/resources/ActiveInstalls
>
> I would fix it to have only the WebHome remain under ActiveInstalls and
> move all the technical pages under ActiveInstalls.Code.
>
> The only case where it could make sense to not have a Code subspace would
> be when the app has no UI at all. Even in this case, you might argue that
> we should always have a home to provide a description about the content of
> the space.
>
> So right now I’m personally in favor of continuing the rule we defined in
> the best practices:
> "Technical pages must be put in a subspace named Code”
>
> WDYT?
>
> Thanks
> -Vincent
>
>

Re: [xwiki-devs] [Need proposal] How to show "conflicting" macro parameters

[Marius Dumitru Florea]

On Wed, Sep 19, 2018 at 4:31 PM Vincent Massol  wrote:

>
>
> > On 19 Sep 2018, at 14:47, Adel Atallah  wrote:
> >
> > On Wed, Jul 18, 2018 at 5:00 PM Vincent Massol 
> wrote:
> >>
> >>
> >>
> >>> On 5 Jul 2018, at 12:06, Vincent Massol  wrote:
> >>>
> >>>
> >>>
>  On 4 Jul 2018, at 12:07, Thomas Mortagne 
> wrote:
> 
>  Here are more details on the actual use case we need to support:
> 
>  In include/Display macro either you set:
> 
>  * "reference" and "type" (which default to DOCUMENT)
>  * or you set “page"
> >>>
> >>> Globally I think we need to add 3 concepts to macro parameter
> descriptor:
> >>>
> >>> 1) The concept of “deprecated” parameter. For example for “document”
> in the include macro.
> >>> 2) The concept of aliases or groups, i.e the ability to list
> parameters that are mutually exclusive. Example: reference + type vs page
> for display/include macros. This would mean that in the Macro Dialog UI if
> you select one of those the other gets unselected/cleared out (you cannot
> have mutually exclusive params have values).
> >>> 3) The concept of Advanced parameters. For example, we should put
> reference + type as advanced parameters so that they are not shown to the
> user by default (and so that the page parameter is more highlighted). Users
> would need to click on Advanced to see advanced parameters. I think we’re
> doing something automatic today (I don’t remember the details) to try to
> hide some parameters but we should probably review this.
> >>>
> >>> WDYT?
> >>
> >> Ping!
> >>
> >> Do we agree about this? If we do we can then create jira issue about it
> and take it for implementation.
> >
> > +1, I can create the jira issue if it's ok.
>
> Please do :)
>
>

> @Marius: Ok for you?
>

Yes.


>
> thanks
> -Vincent
>
> [snip]
>
>
>

Re: [xwiki-devs] [Proposal] Prevent users from renaming/move pages with XClass definition

[Marius Dumitru Florea]

On Sun, Sep 23, 2018 at 11:12 AM Vincent Massol  wrote:

> Hi Simon,
>
> > On 21 Sep 2018, at 16:58, Simon Urli  wrote:
> >
> >
> >
> > On 9/21/18 4:53 PM, Adel Atallah wrote:
> >> +1 for the warning, but I would not forbid simple users from renaming
> >> or moving pages but instead just hide the action (from the page menu).
> >
> > OK I should have written it: by "forbid" I meant:
> >
> >  1. Hide the action from the menu
> >  2. Return an error message if the user try to access the
> renaming/moving page (using forged URL)
> >
> > So you suggest we shouldn't do 2?
>
> So +1 to prevent/warn the user when doing a move/renaming



> AND copy pages containing XClass definitions


FTR, copying a single page having an XClass definition is not dangerous (it
won't break the application that owns the page), as it only creates a new
class definition. Copying an entire application is not dangerous either.
The copy won't work like the original application (this justifies a warning
as it may fail the user expectations), but the original application will
still work. Renaming or moving an application is dangerous as it breaks the
application.


> (the message should list all such pages).
>
> -1 to hide the action from the menu (if you’re talking about the
> “Move/Rename” and “Copy" actions) because:
> 1) you get to choose whether you move/rename/copy children after you click
> the action
> 2) even when the current page has an XClass, the user wouldn't understand
> why he cannot see/click on the action. It’s better that he can do it but
> get an error message, explaining why and telling him that to contact an
> advanced users if he really needs to do it.
>
> Thanks
> -Vincent
>
> >
> >> On Fri, Sep 21, 2018 at 4:44 PM Simon Urli 
> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> users might currently break their AWM application by renaming/moving
> >>> pages containing XClass definition.
> >>>
> >>> We need a proper refactoring operation to be able to properly do such
> >>> move/rename. But this feature might take a while to be completely
> >>> available.
> >>>
> >>> In the meantime I propose that we prevent users from renaming/moving
> >>> pages containing XClass.
> >>>
> >>> What I propose is the following:
> >>>   - Forbid completely *simple users* to rename/move pages containing
> XClass
> >>>   - Display a warning to *advanced users* when they perform such
> >>> operation: the same kind of warning we already have when performing
> edit
> >>> on XWiki pages
> >>>
> >>> WDYT?
> >>>
> >>> Simon
> >>>
> >>> --
> >>> Simon Urli
> >>> Software Engineer at XWiki SAS
> >>> simon.u...@xwiki.com
> >>> More about us at http://www.xwiki.com
> >
> > --
> > Simon Urli
> > Software Engineer at XWiki SAS
> > simon.u...@xwiki.com
> > More about us at http://www.xwiki.com
>
>

Re: [xwiki-devs] [UX] XClass Picker

[Marius Dumitru Florea]

Looks good.

You have some screen shots with Add Class title and Add button while others
have Select Class title and Select button. I assume you propose the later,
because "Add Class" doesn't make sense in this context.

We'll need a Deprecated category at some point.

Thanks,
Marius

On Fri, Sep 14, 2018 at 7:18 PM, Ecaterina Moraru (Valica) <
vali...@gmail.com> wrote:

> Hi devs,
>
> This is an improvement proposal for the XClass Picker found in the objects
> editor:
> https://design.xwiki.org/xwiki/bin/download/Proposal/XClassPicker/O2.png
>
> Read the whole proposal at:
> https://design.xwiki.org/xwiki/bin/view/Proposal/XClassPicker
>
> Let me know what you think.
> Thanks,
> Caty
>

Re: [xwiki-devs] Proposal for Macro inline edition

[Marius Dumitru Florea]

On Wed, Sep 12, 2018 at 6:30 PM, Thomas Mortagne 
wrote:

> On Wed, Sep 12, 2018 at 5:27 PM Marius Dumitru Florea
>  wrote:
> >
> > On Wed, Sep 12, 2018 at 6:20 PM, Thomas Mortagne <
> thomas.morta...@xwiki.com>
> > wrote:
> >
> > > On Wed, Sep 12, 2018 at 5:16 PM Marius Dumitru Florea
> > >  wrote:
> > > >
> > > > On Wed, Sep 12, 2018 at 6:02 PM, Marius Dumitru Florea <
> > > > mariusdumitru.flo...@xwiki.com> wrote:
> > > >
> > > > > On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli 
> > > wrote:
> > > > >
> > > > >> Hello everyone,
> > > > >>
> > > > >> as a follow up of this proposal and the discussion we had, I just
> > > created
> > > > >> the following design proposal:
> > > > >>
> > > > >> https://design.xwiki.org/xwiki/bin/view/Main/
> > > MacroInlineEditingContent/
> > > > >>
> > > > >> Let me know what you think about it.
> > > > >>
> > > > >
> > > > > Regarding the Content Descriptor, which Syntax(es) will activate
> the
> > > > > inline editing of the macro content? I'm asking because the Syntax
> of
> > > the
> > > > > content is not the most important part. The most important part
> for the
> > > > > WYSIWYG editor is to know if the macro code outputs the macro
> content
> > > > > without transforming it. Without this it cannot enable inline
> editing.
> > > If
> > > > > the macro output is rendered without modifications then the WYSIWYG
> > > editor
> > > > > can enable inline editing but it needs to know in which Syntax to
> > > convert
> > > > > the HTML produced while editing inline. So to summarize:
> > > > >
> > > > > * First the WYSIWYG editor needs to know if the macro content is
> > > rendered
> > > > > without modifications
> > > > > * then the WYSIWYG editor needs to know the target Syntax to which
> to
> > > > > convert the HTML
> > > > >
> > > >
> > > > Let me try to make this even more clear.  The WYSIWYG editor needs to
> > > take
> > > > the following decisions:
> > > >
> > > > [OPTIONAL] "Should I display the macro content (plain) text area on
> the
> > > > Macro Edit dialog?"
> > > >
> > > > If the macro content can be edited inline within the editing area
> then it
> > > > probably make sense to not display the text area on the Macro Edit
> > > dialog.
> > > > But for this we need some *static* information in the macro
> descriptor to
> > > > indicate that the macro content can be edited inline.
> > > >
> > > > [MANDATORY] "Should I enable inline editing for this macro?"
> > > >
> > > > The WYSIWYG editor can scan the macro output DOM (HTML) for some
> special
> > > > markers (attributes) to determine if the macro content can be edited
> > > inline
> > > >
> > >
> > >
> > > > [MANDATORY] "To which syntax do I need to convert the HTML from the
> macro
> > > > content?"
> > > >
> > > > When saving the page the editor needs to convert the macro content
> from
> > > > HTML to some syntax. The target syntax needs to be specified either
> in
> > > the
> > > > macro output DOM (HTML) using some attributes or in the macro
> descriptor.
> > >
> > >
> >
> > > That's only if the syntax is different from the current syntax (which
> > > is not the case for most inline edited macros containing wiki
> > > content).
> > >
> >
> > Exactly! The macros we target with this feature use the current syntax
> (of
> > the page where the macro is called) for their content.
>
>

> My point is that the WYSIWYG know the syntax already you don't need
> each macro to provide it as metadata.
>

I fully agree with you.


>
> >
> >
> > >
> > > >
> > > > Hope this helps,
> > > > Marius
> > > >
> > > >
> > > > >
> > > > >
> > > > >>
> > > > >> Thanks,
> > > > >> Simon
> > > > >>
> > > > >>
> > >

Re: [xwiki-devs] Proposal for Macro inline edition

[Marius Dumitru Florea]

On Wed, Sep 12, 2018 at 6:20 PM, Thomas Mortagne 
wrote:

> On Wed, Sep 12, 2018 at 5:16 PM Marius Dumitru Florea
>  wrote:
> >
> > On Wed, Sep 12, 2018 at 6:02 PM, Marius Dumitru Florea <
> > mariusdumitru.flo...@xwiki.com> wrote:
> >
> > > On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli 
> wrote:
> > >
> > >> Hello everyone,
> > >>
> > >> as a follow up of this proposal and the discussion we had, I just
> created
> > >> the following design proposal:
> > >>
> > >> https://design.xwiki.org/xwiki/bin/view/Main/
> MacroInlineEditingContent/
> > >>
> > >> Let me know what you think about it.
> > >>
> > >
> > > Regarding the Content Descriptor, which Syntax(es) will activate the
> > > inline editing of the macro content? I'm asking because the Syntax of
> the
> > > content is not the most important part. The most important part for the
> > > WYSIWYG editor is to know if the macro code outputs the macro content
> > > without transforming it. Without this it cannot enable inline editing.
> If
> > > the macro output is rendered without modifications then the WYSIWYG
> editor
> > > can enable inline editing but it needs to know in which Syntax to
> convert
> > > the HTML produced while editing inline. So to summarize:
> > >
> > > * First the WYSIWYG editor needs to know if the macro content is
> rendered
> > > without modifications
> > > * then the WYSIWYG editor needs to know the target Syntax to which to
> > > convert the HTML
> > >
> >
> > Let me try to make this even more clear.  The WYSIWYG editor needs to
> take
> > the following decisions:
> >
> > [OPTIONAL] "Should I display the macro content (plain) text area on the
> > Macro Edit dialog?"
> >
> > If the macro content can be edited inline within the editing area then it
> > probably make sense to not display the text area on the Macro Edit
> dialog.
> > But for this we need some *static* information in the macro descriptor to
> > indicate that the macro content can be edited inline.
> >
> > [MANDATORY] "Should I enable inline editing for this macro?"
> >
> > The WYSIWYG editor can scan the macro output DOM (HTML) for some special
> > markers (attributes) to determine if the macro content can be edited
> inline
> >
>
>
> > [MANDATORY] "To which syntax do I need to convert the HTML from the macro
> > content?"
> >
> > When saving the page the editor needs to convert the macro content from
> > HTML to some syntax. The target syntax needs to be specified either in
> the
> > macro output DOM (HTML) using some attributes or in the macro descriptor.
>
>

> That's only if the syntax is different from the current syntax (which
> is not the case for most inline edited macros containing wiki
> content).
>

Exactly! The macros we target with this feature use the current syntax (of
the page where the macro is called) for their content.


>
> >
> > Hope this helps,
> > Marius
> >
> >
> > >
> > >
> > >>
> > >> Thanks,
> > >> Simon
> > >>
> > >>
> > >> On 9/10/18 6:46 PM, Thomas Mortagne wrote:
> > >>
> > >>> On Mon, Sep 10, 2018 at 3:47 PM Simon Urli 
> wrote:
> > >>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 9/10/18 3:24 PM, Marius Dumitru Florea wrote:
> > >>>>
> > >>>>> On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <
> > >>>>> thomas.morta...@xwiki.com>
> > >>>>> wrote:
> > >>>>>
> > >>>>> On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
> > >>>>>>  wrote:
> > >>>>>>
> > >>>>>>>
> > >>>>>>> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
> > >>>>>>>
> > >>>>>> thomas.morta...@xwiki.com>
> > >>>>>>
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli  >
> > >>>>>>>>
> > >>>>>>> wrote:
> > >>>>>>
> > >>>>>>>
> > >>>>>>>>>
> > >>&g

Re: [xwiki-devs] Proposal for Macro inline edition

[Marius Dumitru Florea]

On Wed, Sep 12, 2018 at 6:02 PM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli  wrote:
>
>> Hello everyone,
>>
>> as a follow up of this proposal and the discussion we had, I just created
>> the following design proposal:
>>
>> https://design.xwiki.org/xwiki/bin/view/Main/MacroInlineEditingContent/
>>
>> Let me know what you think about it.
>>
>
> Regarding the Content Descriptor, which Syntax(es) will activate the
> inline editing of the macro content? I'm asking because the Syntax of the
> content is not the most important part. The most important part for the
> WYSIWYG editor is to know if the macro code outputs the macro content
> without transforming it. Without this it cannot enable inline editing. If
> the macro output is rendered without modifications then the WYSIWYG editor
> can enable inline editing but it needs to know in which Syntax to convert
> the HTML produced while editing inline. So to summarize:
>
> * First the WYSIWYG editor needs to know if the macro content is rendered
> without modifications
> * then the WYSIWYG editor needs to know the target Syntax to which to
> convert the HTML
>

Let me try to make this even more clear.  The WYSIWYG editor needs to take
the following decisions:

[OPTIONAL] "Should I display the macro content (plain) text area on the
Macro Edit dialog?"

If the macro content can be edited inline within the editing area then it
probably make sense to not display the text area on the Macro Edit dialog.
But for this we need some *static* information in the macro descriptor to
indicate that the macro content can be edited inline.

[MANDATORY] "Should I enable inline editing for this macro?"

The WYSIWYG editor can scan the macro output DOM (HTML) for some special
markers (attributes) to determine if the macro content can be edited inline

[MANDATORY] "To which syntax do I need to convert the HTML from the macro
content?"

When saving the page the editor needs to convert the macro content from
HTML to some syntax. The target syntax needs to be specified either in the
macro output DOM (HTML) using some attributes or in the macro descriptor.

Hope this helps,
Marius


>
>
>>
>> Thanks,
>> Simon
>>
>>
>> On 9/10/18 6:46 PM, Thomas Mortagne wrote:
>>
>>> On Mon, Sep 10, 2018 at 3:47 PM Simon Urli  wrote:
>>>
>>>>
>>>>
>>>>
>>>> On 9/10/18 3:24 PM, Marius Dumitru Florea wrote:
>>>>
>>>>> On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <
>>>>> thomas.morta...@xwiki.com>
>>>>> wrote:
>>>>>
>>>>> On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
>>>>>>  wrote:
>>>>>>
>>>>>>>
>>>>>>> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
>>>>>>>
>>>>>> thomas.morta...@xwiki.com>
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli 
>>>>>>>>
>>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 9/10/18 1:35 PM, Vincent Massol wrote:
>>>>>>>>>
>>>>>>>>>> Hi Simon,
>>>>>>>>>>
>>>>>>>>>> On 10 Sep 2018, at 13:05, Simon Urli 
>>>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>>>>> Hi everyone,
>>>>>>>>>>>
>>>>>>>>>>> I'm working on the roadmap issues related to the inline edition
>>>>>>>>>>>
>>>>>>>>>> with
>>>>>>
>>>>>>> WYSIWYG editor for macro content and macro parameters.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Cool :) We've been waiting for a long time about this feature! See
>>>>>>>>>>
>>>>>>>>> below.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> The first step is to add a flag to allow user specify that a
>>>>>>>>>>>
>>>>>>>>>> content
>>>>>>

Re: [xwiki-devs] Proposal for Macro inline edition

[Marius Dumitru Florea]

On Wed, Sep 12, 2018 at 5:18 PM, Simon Urli  wrote:

> Hello everyone,
>
> as a follow up of this proposal and the discussion we had, I just created
> the following design proposal:
>
> https://design.xwiki.org/xwiki/bin/view/Main/MacroInlineEditingContent/
>
> Let me know what you think about it.
>

Regarding the Content Descriptor, which Syntax(es) will activate the inline
editing of the macro content? I'm asking because the Syntax of the content
is not the most important part. The most important part for the WYSIWYG
editor is to know if the macro code outputs the macro content without
transforming it. Without this it cannot enable inline editing. If the macro
output is rendered without modifications then the WYSIWYG editor can enable
inline editing but it needs to know in which Syntax to convert the HTML
produced while editing inline. So to summarize:

* First the WYSIWYG editor needs to know if the macro content is rendered
without modifications
* then the WYSIWYG editor needs to know the target Syntax to which to
convert the HTML


>
> Thanks,
> Simon
>
>
> On 9/10/18 6:46 PM, Thomas Mortagne wrote:
>
>> On Mon, Sep 10, 2018 at 3:47 PM Simon Urli  wrote:
>>
>>>
>>>
>>>
>>> On 9/10/18 3:24 PM, Marius Dumitru Florea wrote:
>>>
>>>> On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne <
>>>> thomas.morta...@xwiki.com>
>>>> wrote:
>>>>
>>>> On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
>>>>>  wrote:
>>>>>
>>>>>>
>>>>>> On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
>>>>>>
>>>>> thomas.morta...@xwiki.com>
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli 
>>>>>>>
>>>>>> wrote:
>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 9/10/18 1:35 PM, Vincent Massol wrote:
>>>>>>>>
>>>>>>>>> Hi Simon,
>>>>>>>>>
>>>>>>>>> On 10 Sep 2018, at 13:05, Simon Urli 
>>>>>>>>>>
>>>>>>>>> wrote:
>>>>>
>>>>>>
>>>>>>>>>> Hi everyone,
>>>>>>>>>>
>>>>>>>>>> I'm working on the roadmap issues related to the inline edition
>>>>>>>>>>
>>>>>>>>> with
>>>>>
>>>>>> WYSIWYG editor for macro content and macro parameters.
>>>>>>>
>>>>>>>>
>>>>>>>>> Cool :) We've been waiting for a long time about this feature! See
>>>>>>>>>
>>>>>>>> below.
>>>>>>>
>>>>>>>>
>>>>>>>>> The first step is to add a flag to allow user specify that a
>>>>>>>>>>
>>>>>>>>> content
>>>>>
>>>>>> or a parameter can be edited inline with the WYSIWYG editor.
>>>>>>>
>>>>>>>> The second step is to allow the CKEditor to detect where the
>>>>>>>>>>
>>>>>>>>> content
>>>>>
>>>>>> and/or parameters should be edited.
>>>>>>>
>>>>>>>> Let's take the exampe of a simple macro without any parameter,
>>>>>>>>>>
>>>>>>>>> which
>>>>>
>>>>>> currently produces this code:
>>>>>>>
>>>>>>>>
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>   
>>>>>>>>>>   some title
>>>>>>>>>> 
>>>>>>>>>> Some content
>>>>>>>>>> 
>>>>>>>>>>
>>>>>>>>>> We propose (me & Marius) to ask users to add a wrapper with a
>>>>>>>>>>
>>>>>>>>> specific class around the content to tell the editor it should only
>>>>>>>
>>>>>> allow
>>>>>
>>>>>> editing this content, e.g.:
>>>>>>>
>>>>>>>

Re: [xwiki-devs] Proposal for Macro inline edition

[Marius Dumitru Florea]

On Mon, Sep 10, 2018 at 4:07 PM, Thomas Mortagne 
wrote:

> On Mon, Sep 10, 2018 at 2:56 PM Marius Dumitru Florea
>  wrote:
> >
> > On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne <
> thomas.morta...@xwiki.com>
> > wrote:
> >
> > > On Mon, Sep 10, 2018 at 2:13 PM Simon Urli 
> wrote:
> > > >
> > > >
> > > >
> > > > On 9/10/18 1:35 PM, Vincent Massol wrote:
> > > > > Hi Simon,
> > > > >
> > > > >> On 10 Sep 2018, at 13:05, Simon Urli 
> wrote:
> > > > >>
> > > > >> Hi everyone,
> > > > >>
> > > > >> I'm working on the roadmap issues related to the inline edition
> with
> > > WYSIWYG editor for macro content and macro parameters.
> > > > >
> > > > > Cool :) We've been waiting for a long time about this feature! See
> > > below.
> > > > >
> > > > >> The first step is to add a flag to allow user specify that a
> content
> > > or a parameter can be edited inline with the WYSIWYG editor.
> > > > >> The second step is to allow the CKEditor to detect where the
> content
> > > and/or parameters should be edited.
> > > > >> Let's take the exampe of a simple macro without any parameter,
> which
> > > currently produces this code:
> > > > >>
> > > > >> 
> > > > >>   
> > > > >> 
> > > > >> some title
> > > > >>   
> > > > >>   Some content
> > > > >> 
> > > > >>
> > > > >> We propose (me & Marius) to ask users to add a wrapper with a
> > > specific class around the content to tell the editor it should only
> allow
> > > editing this content, e.g.:
> > > > >>
> > > > >> 
> > > > >>   
> > > > >> 
> > > > >> some title
> > > > >>   
> > > > >>   Some content
> > > > >> 
> > > > >
> > > > > By “users”, I guess you mean macro developers?
> > > >
> > > > Here yes it's the macro developer. I'll try to be more specific in my
> > > > answers.
> > > >
> > > > >
> > > > > So if I understand you well, you’re not planning to add a
> > > getter/setters to the Macro descriptor, to tell that the macro content
> > > contains wiki markup and that it should be editable in the WYSIWYG
> editor?
> > > >
> > > > Actually we're planning to add the getter/setter **and** the specific
> > > > markup for the editor. The getter/setter (which I called the flag
> > > > above), is here to specify that the macro will contain inline
> editable
> > > > content in WYSIWYG. The markup will specify *where* exactly is this
> > > > content, and what shouldn't be changed.
> > >
> > > About that "flag", you seems to plan a boolean but I feel something
> > > more generic that we want to introduce since a long time would be
> > > better: make the content descriptor return a type like parameters
> > > descriptors do. The kind of inline editing you have in mind right now
> > > would then be associated to the type List for example (or
> > > CompositeBlock
> >
> >
> >
> > > or some another type if we want to differentiate
> > > between wiki content modified by the macro and wiki content not
> > > modified by the macro
> >
> >
> > We need this differentiation.
>
> Sure but as I said you can differentiate using types too and we need
> content types for other use cases so it's a good occasion. Also when
> you use the type you can differentiate between wiki content and HTML
> content and support inline editing of HTML macro in the same system
> for example.
>

I'm not against your proposal. It's a bit more work though, to define the
types, but I suppose it's worth the effort.


>
> >
> >
> > > ). The other types would be used in other use
> > > cases (syntax coloring for scripts, json editor, etc.). The idea of
> > > using Java type is to be consistent with parameters and reuse existing
> > > the displayers in the macro modal window for example but it can cover
> > > this need too.
> > >
> > > >
> > > > I guess that if the flag is set a

Re: [xwiki-devs] Proposal for Macro inline edition

[Marius Dumitru Florea]

On Mon, Sep 10, 2018 at 3:42 PM, Thomas Mortagne 
wrote:

> On Mon, Sep 10, 2018 at 2:13 PM Simon Urli  wrote:
> >
> >
> >
> > On 9/10/18 1:35 PM, Vincent Massol wrote:
> > > Hi Simon,
> > >
> > >> On 10 Sep 2018, at 13:05, Simon Urli  wrote:
> > >>
> > >> Hi everyone,
> > >>
> > >> I'm working on the roadmap issues related to the inline edition with
> WYSIWYG editor for macro content and macro parameters.
> > >
> > > Cool :) We've been waiting for a long time about this feature! See
> below.
> > >
> > >> The first step is to add a flag to allow user specify that a content
> or a parameter can be edited inline with the WYSIWYG editor.
> > >> The second step is to allow the CKEditor to detect where the content
> and/or parameters should be edited.
> > >> Let's take the exampe of a simple macro without any parameter, which
> currently produces this code:
> > >>
> > >> 
> > >>   
> > >> 
> > >> some title
> > >>   
> > >>   Some content
> > >> 
> > >>
> > >> We propose (me & Marius) to ask users to add a wrapper with a
> specific class around the content to tell the editor it should only allow
> editing this content, e.g.:
> > >>
> > >> 
> > >>   
> > >> 
> > >> some title
> > >>   
> > >>   Some content
> > >> 
> > >
> > > By “users”, I guess you mean macro developers?
> >
> > Here yes it's the macro developer. I'll try to be more specific in my
> > answers.
> >
> > >
> > > So if I understand you well, you’re not planning to add a
> getter/setters to the Macro descriptor, to tell that the macro content
> contains wiki markup and that it should be editable in the WYSIWYG editor?
> >
> > Actually we're planning to add the getter/setter **and** the specific
> > markup for the editor. The getter/setter (which I called the flag
> > above), is here to specify that the macro will contain inline editable
> > content in WYSIWYG. The markup will specify *where* exactly is this
> > content, and what shouldn't be changed.
>
> About that "flag", you seems to plan a boolean but I feel something
> more generic that we want to introduce since a long time would be
> better: make the content descriptor return a type like parameters
> descriptors do. The kind of inline editing you have in mind right now
> would then be associated to the type List for example (or
> CompositeBlock



> or some another type if we want to differentiate
> between wiki content modified by the macro and wiki content not
> modified by the macro


We need this differentiation.


> ). The other types would be used in other use
> cases (syntax coloring for scripts, json editor, etc.). The idea of
> using Java type is to be consistent with parameters and reuse existing
> the displayers in the macro modal window for example but it can cover
> this need too.
>
> >
> > I guess that if the flag is set and the markup is not present, then the
> > entire content is considered as editable.
> >
> > >
> > > Is that because you want to be finer-grained and have macro content
> which can have parts editable with the WYSIWYG while having other parts of
> the content not editable (for example)?
> >
> > It's exactly why yes. On my example, the macro user won't be able to
> > change the content of the title.
> >
> > >
> > > Technically Macros don’t generate HTML, only XDOM. So in order to make
> it easier for java macro developers, I’d suggest to introduce some new
> wrapping Block to indicate this information. We might need something
> similar for wiki macros too, to make it more reusable and typed.
> >
> > I'd need to look more on wrapping block but after a quick overlook it
> > seems to make sense indeed.
> >
> > >
> > >> About parameters, our idea was to define a new metadata attribute and
> to ask users to use it for specifying the content is editable, such as for
> a parameter named foo:
> > >>
> > >> my foo parameter
> value
> > >
> > > What’s your idea for editing parameters requiring WYSIWYG? How do you
> present them in the UI? Do you have any mockup?
> >
> > I don't have any mockup right now. FTM I see it like this:
> >   - when creating the macro, the current text input are improved with
> > the CKEditor for the editable content/parameters
> >   - when editing the macro, you stay in the main editor UI, but the
> > content is now editable instead of opening back the macro UI
> >
> > >
> > >> However I don't know right now how the editor would manage cases such
> as:
> > >> Some content with  class="editable-content" data-parameter="myparameter">a
> parameter
> > >>
> > >> So:
> > >>   1. Do you agree on the usage of a class named "editable-content"
> which would be used as a tag to allow inline edition?
> > >
> > > Small details, there’s already the “contenteditable” notion that
> exists (see https://developer.mozilla.org/fr/docs/Web/HTML/Attributs_
> universels/contenteditable) so “editable-content” is quite close. Maybe
> we should have something more xwiki-specific? or more WYSIWYG-specific?
> Like “editable-wysiwyg” or “wysiwyg-editable”.
>

Re: [xwiki-devs] Proposal for Macro inline edition

[Marius Dumitru Florea]

On Mon, Sep 10, 2018 at 2:35 PM, Vincent Massol  wrote:

> Hi Simon,
>
> > On 10 Sep 2018, at 13:05, Simon Urli  wrote:
> >
> > Hi everyone,
> >
> > I'm working on the roadmap issues related to the inline edition with
> WYSIWYG editor for macro content and macro parameters.
>
> Cool :) We've been waiting for a long time about this feature! See below.
>
> > The first step is to add a flag to allow user specify that a content or
> a parameter can be edited inline with the WYSIWYG editor.
> > The second step is to allow the CKEditor to detect where the content
> and/or parameters should be edited.
> > Let's take the exampe of a simple macro without any parameter, which
> currently produces this code:
> >
> > 
> >  
> >
> >some title
> >  
> >  Some content
> > 
> >
> > We propose (me & Marius) to ask users to add a wrapper with a specific
> class around the content to tell the editor it should only allow editing
> this content, e.g.:
> >
> > 
> >  
> >
> >some title
> >  
> >  Some content
> > 
>
> By “users”, I guess you mean macro developers?
>
> So if I understand you well, you’re not planning to add a getter/setters
> to the Macro descriptor, to tell that the macro content contains wiki
> markup and that it should be editable in the WYSIWYG editor?
>
> Is that because you want to be finer-grained and have macro content which
> can have parts editable with the WYSIWYG while having other parts of the
> content not editable (for example)?
>
>

> Technically Macros don’t generate HTML, only XDOM. So in order to make it
> easier for java macro developers, I’d suggest to introduce some new
> wrapping Block to indicate this information. We might need something
> similar for wiki macros too, to make it more reusable and typed.
>

+1. We should avoid duplicating the markup that makes the content editable
in every macro that allows it.


>
> > About parameters, our idea was to define a new metadata attribute and to
> ask users to use it for specifying the content is editable, such as for a
> parameter named foo:
> >
> > my foo parameter
> value
>
> What’s your idea for editing parameters requiring WYSIWYG? How do you
> present them in the UI? Do you have any mockup?
>
> > However I don't know right now how the editor would manage cases such as:
> > Some content with  class="editable-content" data-parameter="myparameter">a
> parameter
> >
> > So:
> >  1. Do you agree on the usage of a class named "editable-content" which
> would be used as a tag to allow inline edition?
>
> Small details, there’s already the “contenteditable” notion that exists
> (see https://developer.mozilla.org/fr/docs/Web/HTML/Attributs_
> universels/contenteditable) so “editable-content” is quite close. Maybe
> we should have something more xwiki-specific? or more WYSIWYG-specific?
> Like “editable-wysiwyg” or “wysiwyg-editable”.
>

We should probably also prefix it with "macro" or "wikimacro". So something
like "wikimacro-wysiwyg-editable" (although I think we can find a better
naming).


>
> My main comment is what I put above: how do we make it easy for macro
> developers to specify this information.
>
> >  2. WDYT about using a data-parameter and this class for inline editing
> of parameters?
>
> Before answering that part, I would need to understand what’s the proposal
> in term of UI.
>
>

> Note that the main use case is for content but it’s nice if you can also
> support parameters. Now, accepting markup in parameters is not really a
> great use case IMO and is usually a design issue so I’m not sure we should
> spend that much time in supporting that. WDYT?
>

Even if it's plain text it would still be nice to allow the user to edit
the parameter inline if the parameter appears as is in the macro output. Of
course, this won't apply to all macro parameters, but even if it's just one
parameter, it would still be useful.


>
> The only macro parameter I know ATM that supports markup is the “title”
> param of the {{box}} macro and I think it’s badly designed. Note: if you
> check the recent {{figure}} macro, I implemented this need by having a
> {{figureCaption}} nested macro.
>

That's OK when the macro parameter is optional and the position in the
macro output is not fixed. But if you want the title to be mandatory or if
you want the title to always be displayed before the message then you can't
allow the user to edit freely the macro content.


>
> BTW this raises a question, will you support WYSIWYG editing of nested
> macros?
>
> Thanks
> -Vincent
>
> > Thanks,
> > Simon
>
> [snip]
>
>

Re: [xwiki-devs] [Brainstorming] Auto-suggestion on space, wiki and attachment xproperties

[Marius Dumitru Florea]

On Thu, Sep 6, 2018 at 3:57 PM, Adel Atallah  wrote:

> Hi devs,
>
> Working on the auto-suggestion feature [1], I've been integrating it
> in xproperties holding a reference to a page. Those xproperties are of
> type String and have been changed to the Page type so that the page
> displayer is used and shows the auto-suggestion when needed.
>
> I now need to implement an auto-suggestion on xproperties holding a
> reference to a space (e.g [2]), a wiki (e.g [2]) and an attachment
> (e.g. [3]).
>


> I think the best would be to create an Attachment and Wiki xproperty
> type and create new displayers exactly like the Page type.
>

+1


>
> I don't think we can create a Space xproperty because it's not meant
> to be visible by the end user.
>


> Maybe we could use the Page xproperty type and have a parameter inside
> to select only spaces.
>

+1, that's actually useful for enforcing the selection of non-terminal
pages. That's useful for instance when you want to select the location
where to create some pages: the selected page should not be terminal.

Thanks,
Marius


>
> WDYT?
>
> Thanks,
> Adel
>
> 
> [1] https://design.xwiki.org/xwiki/bin/view/Proposal/
> AutocompleteOnReference
> [2] https://design.xwiki.org/xwiki/bin/view/Proposal/
> AutocompleteOnReference#HClass:XWiki.WatchListClass
> [3] https://design.xwiki.org/xwiki/bin/view/Proposal/
> AutocompleteOnReference#HClass:XWiki.XWikiUsers
>

Re: [xwiki-devs] [contrib] Page Preview Popover extension request

[Marius Dumitru Florea]

On Fri, Aug 31, 2018 at 12:01 PM, Eduard Moraru 
wrote:

> Hi, Stephane.
>
> On Tue, Aug 28, 2018 at 10:49 AM Stéphane Laurière 
> wrote:
>
> > Vincent Massol:
> > > Hi Stephane,
> > >
> > >> On 28 Aug 2018, at 08:55, Stéphane Laurière 
> > wrote:
> > >>
> > >> Hi all,
> > >>
> > >> I would like to contribute an extension that will display page preview
> > popovers when hovering wiki links, similarly to what MediaWiki offers:
> > >>
> > >>   https://www.mediawiki.org/wiki/Page_Previews
> > >>   https://blog.wikimedia.org/2018/05/09/page-previews-documentation/
>
>
> Sounds like a nice extension!
>
> However, how are you going to extract the "summary" of a page? In
> Wikipedia, pages have a certain structure and, at the beginning of each
> page, you have at least the first paragraph that is describing the
> resource. Even the Wikipedia API allows you to get the "extract"
> (summary/topic) of a page and that is what the Wikipedia feature is using
> as text content to display in that preview popup.
>
> In XWiki, the usecases are not defined and you could have anything inside a
> page. Do you plan to show the entire page content inside that preview? Do
> you plan to have an empirical approach in order to get some sort of summary
> by e.g. displaying just the first paragraph as well? What's the approach?
>
>
> >
> > >
> > > Sounds nice. Do you plan to implement it as a Rendering Transformation
> > (similar to what the Glossary app do) or as Javascript code?
> >
>
>

> Definitely  JavaScript + REST API would be the way to go here, to avoid
> rendering, at display time, all the linked pages on the server side. Each
> preview should be obtained when the user asks for it, i.e. when displaying
> the preview. Optimisations could be done to prefetch the data, but that
> would also increase the network traffic and server load, while improving
> the user experience (i.e. not having to wait for the preview popup to load
> its content).
>

The rendering transformation could simply add a CSS class name on the link
and pull the required JavaScript. It doesn't have to render the linked
page. The real problem is that you can't specify which transformation to
execute per request and that you need to restart the server to enable a new
transformation.


>
>
> > Actually I had not considered the rendering transformation option. At
> > first glance, plain JavaScript code seems more lightweight to me without
> > any downside but if you see pros for using a transformation, please let
> me
> > know. There's one issue with plain JavaScript at the moment though: the
> > Bootstrap popover feature in version 3.x adds a div next to the clicked
> > element. In our case, this means adding a div to the surrounding
> > span.wikilink, which is not allowed in HTML5. However, Bootstrap 4
> popovers
> > work differently: they're added as direct childs of the body:
> > https://getbootstrap.com/docs/4.0/components/popovers/ so the issue will
> > be fixed once we migrate. What do you think? Can we live with a div in a
> > span for now?
> >
>
> I'm not really sure what you mean. When the popover is displayed, a div is
> indeed created with javascript and added as sibling to the popover trigger
> element. If you make the "span" element the trigger instead of the link,
> then you would get perfectly valid HTML. Example with Bootstrap 3:
> http://jsfiddle.net/vqT5f/1322/
>
> Thanks,
> Eduard
>
>
> >
> > >> Its name could be 'application-page-preview-popover' - what do you
> > think? As discussed with Caty yesterday, the extension will use the
> > Bootstrap popovers. Should you have any need or suggestion, please let me
> > know.
> > >
> > > So it depends on the technology you wish to use. If it’s a
> > transformation, I would name it "transformation-preview”. If it’s
> > JS/webjar, I guess you’ll need a JSX object to load it so I guess
> > "application-page-preview” would be fine.
> >
> > I see, but in any case, with or without a transformation, I think we will
> > need some JS + CSS code anyway, won't we? As far as I can see, the
> glossary
> > extension is an application containing a transformation, so we could go
> for
> > "application-page-preview" as well, with or without transformation, what
> do
> > you think?
> >
> > Stéphane
> >
> >
> > > Thanks
> > > -Vincent
> > >
> > >> If the name is ok, can I ask you for the creation of a repository and
> > JIRA project?
> > >>
> > >> Stéphane
> > >>
> > >>
> > >> --
> > >> Stéphane Laurière
> > >> XWiki www.xwiki.com
> > >> @slauriere
> > >>
> > >
> >
> >
> > --
> > Stéphane Laurière
> > XWiki www.xwiki.com
> > @slauriere
> >
> >
>

Re: [xwiki-devs] [ANN] New committer Adel Atallah

[Marius Dumitru Florea]

Congrats!

On Mon, Aug 27, 2018 at 12:31 PM, Thomas Mortagne  wrote:

> Hi everyone,
>
> I'm please to welcome Adel in the XWiki core committers family !
>
> Congrats, you will now be able to break stuff without having to hide
> it in big pull requests ;)
>
> Don't worry it does not mean you are on your own now, you can still
> ask for review of a feature branch when you are not sure but you
> earned the right to be trusted :)
>
> Make sure you take a look at
> http://dev.xwiki.org/xwiki/bin/view/Community/Committership :)
>
> You will also have the pleasure to do XWiki releases (if you want) !
>
> Thanks,
> --
> Thomas Mortagne
>

Re: [xwiki-devs] [Brainstorming] Servlet Container support strategy

[Marius Dumitru Florea]

+1 to add the page.

On Tue, Aug 21, 2018 at 5:00 PM, Vincent Massol  wrote:

> Hi devs,
>
> Right now we have:
> * Supported browsers: https://dev.xwiki.org/xwiki/bin/view/Community/
> BrowserSupportStrategy
> * Supported DBs: https://dev.xwiki.org/xwiki/bin/view/Community/
> DatabaseSupportStrategy
>
> But we don’t have a list of supported Servlet Containers.
>
> I think the reason is that we considered that XWiki would work on all of
> them. While this is true, in practice it means testing and finding the
> right configuration for XWiki to work on the various contrainers. Thus it
> requires time and testing, thus support.
>
> For example right now lots of users have trouble making XWiki work on
> Wildfly or Glassfish. In the past I had worked on those and documented how
> to make XWiki work on them but new version have come up and XWiki has
> changed too and seems work is needed to document. I also added some
> jboss-reated config files in our distribution to make it easy and work OOB
> for JBoss. We might need to do that for other containers or udpate those
> files.
>
> So IMO we should list a subset of Servlet Containers that we official
> support (ie. that we actively tests and update documentation, fix code when
> needed). Same as for DBs and browsers, the community is welcome to provide
> support for more ofc.
>
> For me the supported list should be for now:
> * Jetty
> * Tomcat
>
> I’m hesitating with Wildfly and Glassfish since they’re quite popular too.
> It would be nice to have them but I don’t think we have the manpower ATM so
> I would leave them to the community for now, as a best effort.
>
> WDYT?
>
> Thanks
> -Vincent
>
>

[xwiki-devs] Users and Groups properties are stored as LargeStringProperty. Why?

[Marius Dumitru Florea]

Hi devs,

As you probably know, UsersClass and GroupsClass overwrite the newProperty
implementation from ListClass and hard code the usage of
LargeStringProperty. The implementation from ListClass takes into account
the relational storage and multiple selection meta properties while
UsersClass and GroupsClass are completely ignoring them. Do you have any
idea why? It's been like this for more than 11 years..

The hard coded LargeStringProperty was introduced in
https://github.com/xwiki/xwiki-platform/commit/e4800bd2ebf97d2e12282ab56ff58750df1571b6
even though at that point ListClass#newProperty was already taking into
account relational storage.

As for the hard coded StringProperty that was before it, it is since the
start of the XWiki history I can access on GitHub, same as the
ListClass#newProperty implementation that take into account relational
storage.

So I have no idea why we had to overwrite ListClass#newProperty in
UsersClass and GroupsClass.

The big problem is that in the current state the Users and Groups
properties cannot be filtered in Oracle because they are stored as CLOB.
See http://jira.xwiki.org/browse/XWIKI-14634 and
https://jira.xwiki.org/browse/XWIKI-15500 .

Fixing this by removing UsersClass#newProperty and GroupsClass#newProperty
requires a migrator and breaks existing queries that join the
LargeStringProperty table to get the users and groups values. Is it
acceptable to break those queries? I'm afraid there are quite a lot of
them, especially since we have examples of such queries on
https://extensions.xwiki.org/xwiki/bin/view/Extension/Query+Module .

WDYT?

Thanks,
Marius

Re: [xwiki-devs] [VOTE] Restrict Menu Application to the main wiki

[Marius Dumitru Florea]

Indeed, the farm use case is important, I propose to focus on implementing
the fall-back from GLOBAL to WIKI visibility for translations and leave the
Menu Application open to subwikis.

On Tue, Aug 7, 2018 at 4:15 PM, Denis Gervalle  wrote:

> Hi Costi,
>
> This is closely related with the discussion we had on XWIKI-12736.
> Applying the same mecanism used for macro scope to translations is
> definitely the best way to mitigate this issue, but not the simplest one.
> Hope it helps.
>
> --
> Denis Gervalle
> SOFTEC sa - CEO
> On 7 Aug 2018, 14:29 +0200, Ecaterina Moraru (Valica) ,
> wrote:
> > We also have the FARM use case, where menus in theory should be able to
> be
> > defined in subwikis and be independent of the main wiki.
> >
> >
> > On Tue, Aug 7, 2018 at 2:49 PM Marius Dumitru Florea <
> > mariusdumitru.flo...@xwiki.com> wrote:
> >
> > > Note that XS has the Menu Application installed only on the main wiki
> ATM.
> > > Also, the reason I used GLOBAL visibility for the Menu macro is
> because I
> > > wanted to support global menus (defined on the main wiki and visible
> > > everywhere). Installing the Menu Application both on the main wiki and
> on a
> > > subwiki can lead to unexpected results so I would not recommend it. The
> > > question is whether installing the Menu Application only on the
> subwiki is
> > > a valid use case or not.
> > >
> > > We could also restrict the installation to the main wiki *only until*
> we
> > > add support for GLOBAL to WIKI visibility fallback for translations.
> +1 for
> > > this.
> > >
> > > Thanks,
> > > Marius
> > >
> > > On Tue, Aug 7, 2018 at 2:31 PM, Costi Listar 
> > > wrote:
> > >
> > > > While working on https://jira.xwiki.org/browse/XWIKI-14037, I
> noticed
> > > > that the Menu Macro has GLOBAL visibility. This implies that Menu
> > > > Translations should have GLOBAL visibility as well. But this will
> cause
> > > > issues if you install the Menu Application on a sub-wiki because
> there is
> > > > no fallback yet from GLOBAL visibility to WIKI in case of
> translations.
> > > > In order to avoid this problem, I propose to restrict the
> installation
> > > of
> > > > the Menu Application to the main wiki.
> > > >
> > > > I am +1 for this.
> > > >
> > > > Thanks,
> > > > Costi
> > > >
> > >
>

Re: [xwiki-devs] [VOTE] Restrict Menu Application to the main wiki

[Marius Dumitru Florea]

Note that XS has the Menu Application installed only on the main wiki ATM.
Also, the reason I used GLOBAL visibility for the Menu macro is because I
wanted to support global menus (defined on the main wiki and visible
everywhere). Installing the Menu Application both on the main wiki and on a
subwiki can lead to unexpected results so I would not recommend it. The
question is whether installing the Menu Application only on the subwiki is
a valid use case or not.

We could also restrict the installation to the main wiki *only until* we
add support for GLOBAL to WIKI visibility fallback for translations. +1 for
this.

Thanks,
Marius

On Tue, Aug 7, 2018 at 2:31 PM, Costi Listar  wrote:

>   While working on https://jira.xwiki.org/browse/XWIKI-14037, I noticed
> that the Menu Macro has GLOBAL visibility. This implies that Menu
> Translations should have GLOBAL visibility as well. But this will cause
> issues if you install the Menu Application on a sub-wiki because there is
> no fallback yet from GLOBAL visibility to WIKI in case of translations.
>   In order to avoid this problem, I propose to restrict the installation of
> the Menu Application to the main wiki.
>
>   I am +1 for this.
>
> Thanks,
> Costi
>

Re: [xwiki-devs] [Proposal] Velocity Test Coverage strategy

[Marius Dumitru Florea]

+1

Thanks,
Marius

On Sun, Jul 29, 2018 at 6:56 PM, Vincent Massol  wrote:

> Hi devs,
>
> During XWiki SAS’s hackathon last week, Simon and me worked on
> implementing test coverage computation for velocity code and more precisely
> to measure the code coverage we get in XWiki XML pages when running our
> tests.
>
> The rationale is that we know what’s our java test coverage but we have no
> clue about the velocity one. And we have a lot of code in velocity scripts
> in wiki pages. Thus we need a strategy for this too if we wish to increase
> our global code quality.
>
> So we have currently developed 2 mojos (xar:instrument and
> xar:reportCoverage) in the XAR plugin code and created a JIRA issue, see
> XCOMMONS-1448.
>
> Here’s the proposal I’d like your opinion on:
> * Finish working on this to stabilize it and commit/push it
> * Apply the same strategy we have with Jacoco for java test coverage, i.e.
> introduce a new xar:coverageCheck mojo that will fail the build if we get a
> global TPC under the threshold mentioned in the POM
>
> Consequences:
> * It will mean that whenever we add new velocity scripts (especially when
> there are branches such as #if) we will need to improve or add XAR page
> tests. This can be done in 2 ways:
> ** by writing/improving a functional UI test
> ** by writing/improving a XAR unit test
> * We will find places that have 0% coverage and these will be good
> candidates to add tests for
>
> My POV:
> * We should have the minimum # of functional UI tests since they take very
> long to execute. We need them but we shouldn’t test the various branches
> with them IMO. Only one path.
> * Instead we should focus on have more of XAR unit tests since they
> execute fast and are better suited (with mocks) to test the various branches
> * The XAR unit test framework we have is still pretty new and it’s
> probably not to easy to write unit tests for wiki pages in some cases, we
> will need to work on that as we discover them. I’m happy to help on that.
>
> WDYT?
>
> Personally I’m ok to try it and see what happens.
>
> Thanks
> -Vincent

Re: [xwiki-devs] [VOTE] Update the xar plugin and stop committing XML wiki page date fields

[Marius Dumitru Florea]

+1

Thanks,
Marius

On Tue, Jul 31, 2018 at 7:43 PM, Eduard Moraru  wrote:

> Hi, devs.
>
> We have had 2 previous discussions on this topic:
> * July 2016 (discussion): https://markmail.org/thread/oodciq7pv6pj7eic
> * Jan 2018 (proposal): https://markmail.org/thread/ymwsebvr3k7voy3p
>
> And we have at least 2 issues on this topic:
> * Oct 2011: XWIKI-7058 : Page
> creation date should be the date of the installation
> * Feb 2015: XCOMMONS-1447 :
> XAR plugin should replace the dates with a common number
>
> TL;DR: It's causing confusion for our users to install pages that are
> created in 2005/2009/etc. so we should avoid committing dates on git that
> users might end up installing.
>
> Reminder: Importing a document with empty dates will:
> * Use the current date if the document is new (i.e. does not exist in the
> wiki)
> * Use the existing dates if the document already exists in the wiki, if
> using backup import
> * Use the current user and current date for the document update date, if
> imported using non-backup import of EM extension install
>
> Adel and myself have extended the xar:verify and xar:format goals of the
> xar plugin to check for the existence of date fields in the XML wiki pages
> and to remove them. The fields are:
> * date
> * contentUpdateDate
> * creationDate
> * attachment/date
>
> See the PR https://github.com/xwiki/xwiki-commons/pull/44/
>
> This check (on both verify and format goals) is skippable entirely with the
> "xar.dates.skip property" (default to false) or
> "xar.dates.skip.documentList" for individual documents (list of doc
> references).
>
> I need your vote for accepting the existing PR and for removing the
> document dates (e.g. https://github.com/xwiki/xwiki-platform/pull/792) and
> your feedback in case you know of any problems that this might create.
>
> Also, please mention if you would prefer for this behavior to be skipped by
> default (and explicitly enabled on XWiki Standard, so that 3rd party code
> is not impacted by this change).
>
> Here's my +1 (enabled by default and skippable if needed).
>
> Thanks,
> Eduard
>

[xwiki-devs] [ANN] XWiki 10.6RC1 released

[Marius Dumitru Florea]

The XWiki development team is proud to announce the availability of XWiki
10.6RC1.
This release adds a RSS view to the Notifications macro and improves the
user picker with compact display and in-line selection. The developers
should check the new Page API and the improvements to the existing Icon
API. In addition there have been 23 bugs fixed and a couple of small
improvements done.

You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download

Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/10.6RC1/

Thanks for your support
-The XWiki dev team

Re: [xwiki-devs] First batch of the new experimental Page oriented APIs

[Marius Dumitru Florea]

On Sat, Jul 7, 2018 at 8:55 PM, Eduard Moraru  wrote:

> Great to hear you're progressing on this topic, Thomas!
>
> My only note was also (as Vincent pointed out) on the link syntax. If we
> went with "/" instead of "." was because people were more accustomed to the
> URL syntax and also that they would be more tempted to copy the URL as a
> wiki link, instead of converting "/" to ".".
>
>

> Now, why don't we apply the same logic to parameter separators (i.e.
> instead of ";" to use "&" and, hopefully, instead of "?" as the parameters
> separator).
>

You are mixing the query string with the URL path parameters
https://doriantaylor.com/policy/http-url-path-parameter-syntax . The query
string is for the entire URL/path while each path segment can have its
parameters. In our case each entity reference from the chain can have its
own parameters.


>
> Also, are we considering anchors as well (i.e. using "#MyHeading" instead
> of "|anchor='HMyHeading'")?
>
> Ideally, it would be awesome if we could say that copy/pasting the exact
> URL, right after the action part, would be supported when adding a wiki
> link.
>
> Slightly off-topic, but related to that last part, so it might not be a bad
> idea to talk about it:
> This actually gets me realising that we don't have a way to link in pure
> wiki syntax to a page in a specified mode/action (i.e. not only view, but
> also edit/create/delete/etc.). Sure, we have the "path:" type, but that's
> not exactly designed for that, but for whatever else we might need, and it
> require either writing, by hand, technical details or to use velocity (i.e.
> $xwiki.getURL($doc, 'mode')).
>
> Thanks,
> Eduard
>
> On Fri, Jun 29, 2018 at 7:20 PM, Thomas Mortagne <
> thomas.morta...@xwiki.com>
> wrote:
>
> > On Fri, Jun 29, 2018 at 3:10 PM, Vincent Massol 
> > wrote:
> > > Hi Thomas,
> > >
> > > Good work!
> > >
> > > See below
> > >
> > >> On 29 Jun 2018, at 14:29, Thomas Mortagne 
> > wrote:
> > >>
> > >> Hi xwikiers,
> > >>
> > >> Some of us discussed that for a while and created/improved
> > >> http://design.xwiki.org/xwiki/bin/view/Proposal/
> > DeprecatingSpaceAndSpaceReference
> > >> and I finally started working on it.
> > >>
> > >> So here is what I pushed on master already:
> > >>
> > >> = PAGE EntityType and Page*Reference classes
> > >>
> > >> First thing first we now have a few new type in EntityType and the
> > >> corresponding typed Page*Reference helpers. One for each of the
> > >> element you can have in a page:
> > >> * PAGE
> > >> * PAGE_ATTACHMENT
> > >> * PAGE_OBJECT
> > >> * PAGE_OBJECT_PROPERTY
> > >> * PAGE_CLASS_PROPERTY
> > >>
> > >> = Corresponding resolvers/serializer/providers
> > >>
> > >> Each of the already existing DOCUMENT oriented resolvers and
> > >> serializers have their PAGE oriented implementation.
> > >>
> > >> = Conversion from DOCUMENT to PAGE world
> > >>
> > >> The entity resolvers automatically convert from/to DOCUMENT from/to
> > >> PAGE world references. Do yes using a resolver is the official way to
> > >> do that conversion.
> > >>
> > >> = Model script service
> > >>
> > >> The $services.model API also got his own new helpers to manipulate
> pages
> > >>
> > >> = New syntax
> > >>
> > >> Last but not least: pages reference have a very different syntax.
> > >>
> > >> To summarize it's a filesystem path syntax with support for
> parameters.
> > >>
> > >> Here is are a few examples:
> > >>
> > >>wiki:page1/page2;param1=value1;param2=value2;en_US
> > >>
> > >>wiki:page1/page2/attachment
> > >>
> > >>../siblingpage
> > >>
> > >> * separator: "/" between all elements except WIKI which is still ":"
> > >> * escaping: still "\"
> > >> * current, parent support: like in a filesystem you can refer to the
> > >> current page or parent page/wiki using "." and ".."
> > >> * parameters: we now have syntax to express the parameters of an
> > >> EntityReference. Each parameter is separated by a ";" at the end of
> > >> the entity name
> > >
> > > Should we use “?” as the delimiter between reference and parameters to
> > be closer to URI/URL syntax?
> >
> > This was my initial proposal but it was decided that ? was too common.
> >
> > >
> > > 
> > > Maybe we could even have a Page Reference be implemented as a
> > hierarchical URI? (the wiki would be the scheme, the authority would be
> > empty and fragments would be empty).
> > >
> > > In practice it would be hard since we need to have PageReference
> extends
> > EntityReference. But if we were starting from scratch we would maybe use
> a
> > URI or extend it.
> > >
> > > Sill it might make sense to at least be closer on the syntax aspect and
> > thus use “?” for the delimiter.
> > > 
> > >
> > >> * default parameter: the syntax have the concept of default parameter
> > >> which mean a parameter for which you don't need to indicate the name.
> > >> For example PAGE reference default parameter is “locale"
> > >
> > > "a parameter for which you don't need to indicate the name” —> does

Re: [xwiki-devs] [Need proposal] How to show "conflicting" macro parameters

[Marius Dumitru Florea]

For groups of parameters we could use tabs:

--8<--
Param 1
[input]

Param 2 | Param 3 | Param 4 <--- a group of 3 parameters displayed using
tabs (we take into account only the value of the parameter from the active
tab)
[input for param 2]

Param 5
[input]
-->8--

But if you want to support subgroups of parameters also then it becomes
more complicated.

Thanks,
Marius

On Mon, Jul 2, 2018 at 11:52 AM, Thomas Mortagne 
wrote:

> Hi xwikiers,
>
> In the contact of bringing new Page concept (OK 7.4 is starting to get
> old) to the API and macros too we decided (1) to introduce a "page"
> shortcut property (even if we keep the reference/type for other
> types).
>
> While it's nicer for wiki syntax, one issue is that on WYSIWYG macros
> UI side, which display all properties, it means ending up with
> conflicting parameters that needs to be displayed as such.
>
> I don't really have much clue on how best to display this so I'm
> searching for ideas :)
>
> Then I will add in the macro descriptor what's required for whatever
> UI we want to build (group and sub groups of properties, etc.).
>
> 1: http://design.xwiki.org/xwiki/bin/view/Proposal/
> DeprecatingSpaceAndSpaceReference#HMacros
>
> Thanks,
> --
> Thomas Mortagnes
>

Re: [xwiki-devs] [UX][Idea] Left Panels

[Marius Dumitru Florea]

On Wed, Jun 20, 2018 at 12:31 PM, Ecaterina Moraru (Valica) <
vali...@gmail.com> wrote:

> On Wed, Jun 20, 2018 at 12:09 PM, Vincent Massol 
> wrote:
>
> > Hi Caty,
> >
> > > On 19 Jun 2018, at 17:29, Ecaterina Moraru (Valica)  >
> > wrote:
> > >
> > > Hi devs,
> > >
> > > Some ideas that could be applied to left panels area:
> > >
> > > * Mark "More applications" as expandable
> >
> > Seems good
> >
> > > * Provide a "Customize" panel button on hover
> >
> > I agree with the general idea.
> >
> > Some details:
> > * For admins only right?
> > * What does it do? We don’t have the concept of Panel administration ATM.
> > What would work is edit the panel page but then we may want to go further
> > than that. Editing  needs to be an option but some panel may provide an
> > admin UI too such as the Navigation Panel or the Applications Panel.
> Maybe
> > it’s time to update the Panel XClass and add an xproperty for the
> > administration of panels, which would be used if not empty.
> >
> >
> In theory only for Admins, since they have access to Administration.
> Currently we have dedicated customizations for AppBar and Navigation, so
> having that button would help the discoverability. Being able to have it at
> the Panel class, could be nice, but I think it's interesting to have it at
> least as individual customizations for these 2 panels that are on the Left.
>
>
> > > * Some styling changes
> >
> > Sounds good
> >
> > > * Demo: show sticky left panels would behave
> >
>
> I made the sticky demo mostly as an experiment. I even don't know if I like
> it. It's problematic for the current skin, since the logo disappears on
> scrolling.
> I made the demo since we discussed once on the IRC about independent
> containers and wanted to see how it looks like. From an implementation POV
> it's a single "position: sticky" in CSS, but it's not supported in IE11. So
> this could be an option just for a newer skin or have JS to have the
> behavior.
>
>
> >
> > I’m also not yet 100% sure about the sticky panels but why not, we should
> > discuss the details. What I don’t like are for cases when you have panels
> > that span more than a screenful vertically.
> >
> > It’s possible there’s not a single valid choice depending how you want to
> > implement your website and thus maybe the only option is to have this
> > configurable in the general Panel Admin UI (fixed panels or sticky
> panels).
> > That’s what would make the most sense to me. Once we have this, the
> default
> > should be what looks best with the default content we provide for XS.
> >
> >
>


> Yeap, for KB having a sticky TOC or Navigation panel would look great


Only if the panel content fits the window height. Both the ToC and the
Navigation Panel can take a lot of vertical space (e.g. if you have a large
wiki and you expand the navigation tree). What will be the behavior if the
panels content is larger than the window height?


> , but
> it's not the case for all the Flavors. So having it customizable would be
> preferred.
>
> Thanks,
> Caty
>
>
> > I like those ideas! :)
> >
> > Thanks
> > -Vincent
> >
> > >
> > > See the prototype in action:
> > > http://design.xwiki.org/xwiki/bin/download/Proposal/
> > IdeaExpandableAppBar/AppBar.gif
> > >
> > > The full proposal at:
> > > http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaExpandableAppBar
> > >
> > > Let me know what you think.
> > > Thanks,
> > > Caty
> >
> >
>

Re: [xwiki-devs] [Proposal] Add a new method in the icon API

[Marius Dumitru Florea]

On Fri, Jun 15, 2018 at 12:18 PM, Adel Atallah 
wrote:

> Another idea would be to add a 'getMetaData()' method to the API
> (instead of renderJSON) which would take the same arguments as
> 'render()' and 'renderHTML()' methods and would return a map with some
> metadata, particularly the url of the image or the css class depending
> of the chosen iconset. This way, we won't even need to parse a string
> to know if the icon should be rendered as an image or with a css
> class, we will just need to check for the presence of some key in the
> map. We will also be able add other useful information in the future
> as well.
>

+1


>
> We will still need the '$services.icon.use()' methods as described by
> Marius to pull the necessary resources.
>
> Thanks,
> Adel
>
>
> On Thu, Jun 14, 2018 at 1:24 PM, Marius Dumitru Florea
>  wrote:
> > +1 obviously.
> >
> > I encountered this need multiple times. One such example is the Document
> > Tree which uses the jstree library which accepts as node icon an URL, a
> > path or a CSS class name. I believe it is common in the JavaScript world
> to
> > be able to specify an icon either as an URL/path or as a CSS icon. The
> > reason Adel proposed "renderJSON" is because this method is needed mainly
> > when you generate JSON and the client that receives the JSON wants to
> have
> > 100% control over the HTML that is generated (so injecting the HTML we
> get
> > from renderHTML is not an option).
> >
> > Note that besides renderJSON we would also need a method to pull the
> > resources required by the icon set. I propose something like:
> >
> > $services.icon.use() <--- pull the resources for the configured icon set
> > $services.icon.use('someIconSet') <--- pull the resources for the
> specified
> > icon set
> >
> > These methods will call ssx, jsx, etc. under the hood. This is done
> already
> > when you call render() and renderHTML() but it obviously doesn't work if
> > you call render* on an AJAX request that returns JSON.
> >
> > Thanks,
> > Marius
> >
> >
> > On Thu, Jun 14, 2018 at 12:56 PM, Adel Atallah 
> > wrote:
> >
> >> Hi devs,
> >>
> >> I'm making a rest resource to get a list of pages and, for a query, I
> >> want to specify an icon (as a metadata) for each pages in the resulted
> >> json.
> >> The problem is that the icon APIs (and more specifically the
> >> IconManager class) only allow us to render the icon in HTML or
> >> velocity and this shouldn't be put inside a json response.
> >> Also we can't hardcode the icon class or image URL to be used as it
> >> depends on the iconset configured for the wiki. Another possibility
> >> would be to render the icon using javascript but it will not be very
> >> efficient.
> >>
> >> As discussed with Marius, our proposal would be to add a new method to
> >> the IconManager to get either the icon URL (e.g.
> >> http://xwiki.org/xwiki/resources/icons/silk/page.png) or the icon
> >> class (e.g. fa fa-page) depending of the specified iconset.
> >> We could then have this new property to the icon theme definition:
> >>
> >> ## Silk
> >> xwiki.iconset.render.json=$xwiki.getSkinFile("icons/silk/${icon}.png")
> >> ## FontAwesome
> >> xwiki.iconset.render.json=fa fa-$icon
> >>
> >> We could name the new method renderJSON or something more generic (if
> >> you have any idea).
> >>
> >>
> >> WDYT?
> >>
> >> Thanks,
> >> Adel
> >>
>

Re: [xwiki-devs] [Proposal] Add a new method in the icon API

[Marius Dumitru Florea]

+1 obviously.

I encountered this need multiple times. One such example is the Document
Tree which uses the jstree library which accepts as node icon an URL, a
path or a CSS class name. I believe it is common in the JavaScript world to
be able to specify an icon either as an URL/path or as a CSS icon. The
reason Adel proposed "renderJSON" is because this method is needed mainly
when you generate JSON and the client that receives the JSON wants to have
100% control over the HTML that is generated (so injecting the HTML we get
from renderHTML is not an option).

Note that besides renderJSON we would also need a method to pull the
resources required by the icon set. I propose something like:

$services.icon.use() <--- pull the resources for the configured icon set
$services.icon.use('someIconSet') <--- pull the resources for the specified
icon set

These methods will call ssx, jsx, etc. under the hood. This is done already
when you call render() and renderHTML() but it obviously doesn't work if
you call render* on an AJAX request that returns JSON.

Thanks,
Marius


On Thu, Jun 14, 2018 at 12:56 PM, Adel Atallah 
wrote:

> Hi devs,
>
> I'm making a rest resource to get a list of pages and, for a query, I
> want to specify an icon (as a metadata) for each pages in the resulted
> json.
> The problem is that the icon APIs (and more specifically the
> IconManager class) only allow us to render the icon in HTML or
> velocity and this shouldn't be put inside a json response.
> Also we can't hardcode the icon class or image URL to be used as it
> depends on the iconset configured for the wiki. Another possibility
> would be to render the icon using javascript but it will not be very
> efficient.
>
> As discussed with Marius, our proposal would be to add a new method to
> the IconManager to get either the icon URL (e.g.
> http://xwiki.org/xwiki/resources/icons/silk/page.png) or the icon
> class (e.g. fa fa-page) depending of the specified iconset.
> We could then have this new property to the icon theme definition:
>
> ## Silk
> xwiki.iconset.render.json=$xwiki.getSkinFile("icons/silk/${icon}.png")
> ## FontAwesome
> xwiki.iconset.render.json=fa fa-$icon
>
> We could name the new method renderJSON or something more generic (if
> you have any idea).
>
>
> WDYT?
>
> Thanks,
> Adel
>

Re: [xwiki-devs] [Brainstorming] Best practices on indentation for rendering macros in scripts

[Marius Dumitru Florea]

I've always used A-1 and I'd like to keep it that way.

Thanks,
Marius

On Wed, Jun 6, 2018 at 12:49 PM, Vincent Massol  wrote:

> Hi,
>
> Context 1: https://jira.xwiki.org/browse/WIKIEDITOR-58
> Context 2: Fill the “velocity code style” section of
> http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle/
>
> Option A-1: No top level indentation
> =
>
> {{velocity}}
> #set ($var = …)
> #if (…)
>   …
>   #if (…)
>   #end
> #end
> {{/velocity}}
>
> Nested example:
>
> {{velocity}}
> #if ($doc.fullName != 'XWiki.AdminInlineSheet')
>   #set($formname = 'inline')
>   #set($saveaction = 'save')
>   #set($previewenabled = true)
>   #set($xnotification = $!request.getParameter('xnotification'))
>   {{html}}
>   
> 
> …
> {{/velocity}}
>
> Pros:
> * This is what we currently do which IMO means it’s the more natural way
> * Makes content more visible when editing inside xwiki since it takes less
> horizontal space
> * Less typing and less chance to make it wrong
>
> Option A-2: Top level indentation
> 
>
> {{velocity}}
>   #set ($var = …)
>   #if (…)
> …
> #if (…)
> #end
>   #end
> {{/velocity}}
>
> Nested example:
>
> {{velocity}}
>   #if ($doc.fullName != 'XWiki.AdminInlineSheet')
> #set($formname = 'inline')
> #set($saveaction = 'save')
> #set($previewenabled = true)
> #set($xnotification = $!request.getParameter('xnotification'))
> {{html}}
>   
> 
> …
> {{/velocity}}
>
> Pros:
> * More logical since a macro is a container (even though it’s different
> syntax - wiki markup vs velocity - so it’s arguable)
> * More legible?
>
> Cons
> * This means slowly changing everywhere we use scripting.
>
> WDYT?
>
> I think my preference goes to A-1 FTM since I’ve never thought to myself
> that it was an issue all these years of using it.
>
> Thanks
> -Vincent
>
>
>

Re: [xwiki-devs] [Regarding XWiki.Registration ] Hi devs@xwiki.org

[Marius Dumitru Florea]

On Fri, Jun 1, 2018 at 6:40 PM, Kwan Kim  wrote:

> Hello devs@xwiki.org
>
> I has a question for the XWiki.Registration
>
> I tried to add input validation for the registration and it seems the
> following link has the information about it.
>
> http://extensions.xwiki.org/xwiki/bin/view/Extension/
> Administration%20Application#HValidationConstraints
>
> When I read this document, there is the text like:
> Things which you may configure by editing XWiki.Registration
> However where can I find XWiki.Registration ? Is it configuration file ?
>
> I already check Registration section of the Administration Interface but I
> can not find.
>
>

> Please let me know where can I find  XWiki.Registration.
>

It's a wiki page. You access it like any other wiki page
/xwiki/bin/view/XWiki/Registration

Note that your question is more suited for http://forum.xwiki.org/ because
it is not about the development of the XWiki product itself but about its
usage and customization.

Hope this helps,
Marius


>
> Thanks
>
> Kwan
>
>

Re: [xwiki-devs] [Proposal] Display user messages in the notifications.

[Marius Dumitru Florea]

On Thu, May 31, 2018 at 12:46 PM, Guillaume Delhumeau <
guillaume.delhum...@xwiki.com> wrote:

> Notifications application is almost ready to replace the Activity Stream's
> UI. The only remaining thing is the display
> of the messages from the Message Stream in the Notifications.
>
> We have made a quick brainstorming with Caty and Vincent, and here is our
> conclusions.
>
> 1/ We think it make sense to display user messages in the notifications
> because it is typically what notifications
> are made for: pop-up important information concerning what the user cares.
> In the past, we decided to disable the
> Message Stream by default because messages were lost in the Activity
> Stream. But in the case of the notifications, users
> can chose what they want to receive so there is less chance to miss
> messages in the middle of thousand of events.
>
> 2/ Like all other types of notification, there should be a button in the
> notification settings of each user to decide to
> enable or disable these messages in the notifications. It should be enabled
> by default.
>
>

> 3/ We should add the "send message" gadget in the "alert" menu (via an UIX)
> so it's easy to find and to send messages.
>

I'm not very convinced by this. It will clutter the notification menu. An
alternative is to show just an icon/button on the notification menu, that
opens a popup (modal) with the form to send message.


>
> 4/ Provide a form to be able to reply to a personal message.
>
> 5/ Let the message stream disabled by default. Users who are used to it
> will not lose the feature but we don't make it
> visible for now until we make some other improvements.
>
> This is what I am starting to implement right now with the hope it's done
> for XWiki 10.5.
>
> In the future, we should add the following features:
>
> a/ Having a real "inbox" application (a "Message Center") to handle all
> messages.
>
> b/ Be notified when someone mention you in a content or in a comment
> (example: "@vmassol: You may want to read this
> page" will trigger a notification to Vincent Massol).
>
> c/ Handling correcty messages sent to a group if the first implementation
> do not handle it (group filtering could be a problem
> with SQL).
>
> Caty, Vincent, please reply if I've forget something.
>
> All others: if you have any recommendation or counter argument, please post
> it quickly :)
>
> Thanks for you time and have a great day,
>
> Guillaume
>
> --
> Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
> Research & Development Engineer at XWiki SAS
> Committer on the XWiki.org project
>

Re: [xwiki-devs] [Proposal] XS 10.7 roadmap on BFD+Test

[Marius Dumitru Florea]

+1

Thanks,
Marius

On Thu, May 24, 2018 at 10:34 AM, Vincent Massol  wrote:

> Hi devs,
>
> We’re having a tough time maintaining the quality of XWiki Standard these
> days (not enough people).
>
> We used to be able to contain bugs and have as many bugs closed than
> created over 1600 days. We’ve now slipped back to 330+ bugs that have been
> opened vs created over 1600 days. +116 over 500 days. +96 over 365 days.
> And +49 over 120 days. BFD days have little impact with that many bugs
> (since there are about 1-2 devs participating to XS’s BFDs).
>
> In addition I’ve measure our Test Coverage since end of 2017 and we’ve
> lost coverage compared to before which is really bad (see my other emails).
> In short this means that we’re hurrying to finish work from the roadmaps
> without taking enough time to write the proper tests. This will have an
> important impact in the future if we don’t react.
>
> Thus I’d like to propose that we spend the XS 10.7 roadmap (1 month in
> August) on bug fixing and writing more tests. It’ll probably not be enough
> but it’ll help a lot.
>
> Let me know if someone has a counter-proposal or an issue with this
> proposal.
>
> Thanks
> -Vincent