Re: [xwiki-devs] [VOTE] Use discourse for the "dev" mailing list

[Guillaume Delhumeau]

Hello Devs.

I'm doing the conclusion of this VOTE, more than 2 years after.
* Guillaume: +1
* Caty: +1
* Vincent: +0

So we can consider this VOTE as ACCEPTED.

Thanks,

Le mar. 11 juil. 2017 à 16:10, Vincent Massol  a écrit :

> Hi,
>
> > On 11 Jul 2017, at 13:21, Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com> wrote:
> >
> > Hi devs,
> >
> > I think we are now satisfied with our experimentation with the "users"
> > mailing list on discourse. I propose you to move the "dev" ML too.
>
> I’m +0 on my side even though we don’t support yet replying my email. The
> principle negative impact is the unability to reply when offline and I use
> that regularly but I could live without.
>
> When connected, I find that clicking the mail to reply isn’t that hard.
>
> It would be better if we coud finish the setup to reply by mail but 1)
> that could wait a bit for me and 2) I’m not sure how well it would work.
>
> Thanks
> -Vincent
>
> >
> > My main point is that it allows advanced formatting (which is good when
> you
> > have complex proposals), meanwhile the formatting is lost with our
> > archiving tool like markmail (it's plain text).
> >
> > Here is my +1.
> >
> > Thanks,
> >
> > --
> > Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
> > Research & Development Engineer at XWiki SAS
> > Committer on the XWiki.org project
>
>

-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

[xwiki-devs] [ANN] XWiki 10.11.9 released

[Guillaume Delhumeau]

The XWiki development team is proud to announce the availability of XWiki
10.11.9.
This is a bugfix release that cover important issues that we have
discovered since 10.11.8 has been released.

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.11.9/

Thanks for your support
-The XWiki dev team

[xwiki-devs] [ANN] XWiki 10.11.8 released

[Guillaume Delhumeau]

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

This is a bugfix release that covers important issues that we have
discovered since 10.11.7 has been released.

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

Thanks for your support
-The XWiki dev team

[xwiki-devs] [ANN] XWiki 11.1 released

[Guillaume Delhumeau]

The XWiki development team is proud to announce the availability of XWiki
11.1.
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.1/

Thanks for your support
-The XWiki dev team

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

[Guillaume Delhumeau]

Congratulations :)

Le lun. 11 févr. 2019 à 10:24, Oana-Lavinia Florean 
a écrit :

> Congratulations, Simon! Keep up the good work!
>
> Thanks,
> Lavinia
>
> On Mon, Feb 11, 2019 at 10:07 AM Simon Urli  wrote:
>
> > Hi everyone!
> >
> > Yay \o/
> >
> > Thanks for the trust! I'll try to not break everything right now ;)
> >
> > Simon
> >
> > On 11/02/2019 09:04, 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
> > >
> >
> > --
> > Simon Urli
> > Software Engineer at XWiki SAS
> > simon.u...@xwiki.com
> > More about us at http://www.xwiki.com
> >
>
>
> --
> <http://www.xwiki.com/> *Florean Oana-Lavinia*
> *Software Development Engineer Intern*
> oana.flor...@xwiki.com 
> tel: +40 75 136 7570
>


-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

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

[Guillaume Delhumeau]

Le jeu. 7 févr. 2019 à 14:40, Eduard Moraru  a écrit :

> +1 in general, but please consider migration issues, specially calls to the
> {{activity/}} macro that will be still found in wiki pages that will stop
> working if the ActivityStream (which is a macro) is removed.
>

The UI of Activity Stream (which defines the macro you mentioned) is
already removed from XWiki Standard. But the retro-compatibility is handled
by
https://extensions.xwiki.org/xwiki/bin/view/Extension/Legacy%20Notification%20Activity%20Macro/
.

It's actually a good thing you that did not realized AS was not there
anymore :)


>
> Also, for anyone using or extending the ActivityStream plugin's API
> directly, their code will fail. I doubt there were many (if any) users of
> the relatively obscure EventStream API, so the effect of the backwards
> compatible "Event Stream Store" implementation will not compensate for
> much, IMO.
>
> What I am personally concerned about is that, ideally, the upgrade to the
> new XWiki version (which no longer bundles these modules) require as less
> (preferably none) manual operations as possible.
>
> Thanks,
> Eduard
>
> On Wed, Feb 6, 2019 at 5:10 PM Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
>
> > +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
> > >
> >
>


-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

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

[Guillaume Delhumeau]

Le mar. 5 févr. 2019 à 11:33, Vincent Massol  a écrit :

> Hi Guillaume,
>
> > On 4 Feb 2019, at 12:50, 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.
>
> +1
>
> > 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
>
> Already in action! +1
>
> > - stop bundle Watchlist and AS in 11.1
>
> +1
>
> > - move Watchlist and AS into "attic" in 11.2
>
> IMO this could be done in 11.1 too since if we stop bundling Watchlist/AS
> then we don’t need to keep the modules in platform.
>

I wanted to release a new "official" version of AS before moving it to
attic, because I made a few changes on it (like moving some components that
had nothing to do in AS).


>
> Thanks
> -Vincent
>
> >
> > Thanks you,
> >
> > --
> > Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
> > Research & Development Engineer at XWiki SAS
> > Committer on the XWiki.org project
>
>

-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

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

[Guillaume Delhumeau]

Le lun. 4 févr. 2019 à 14:35, Thomas Mortagne  a
écrit :

> On Mon, Feb 4, 2019 at 12:50 PM Guillaume Delhumeau
>  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
>
> Will 11.1 version be easily installable as extension (in case some old
> extension needs it for example) ?
>

AS needs a custom property in hibernate.cfg.xml plus a special config in
xwiki.cfg (since it is a plugin), and the Watchlist needs AS to be
installed. So, in short, not easy installable.



>
> > - 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
>
>
>
> --
> Thomas Mortagne
>


-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

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

[Guillaume Delhumeau]

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] Update objects on class rename

[Guillaume Delhumeau]

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.

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

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

[Guillaume Delhumeau]

A: 0
B: +1, depends on how you detect it's a translation page
C: 0
F: +0 (if we have extra time, ok)


Le mer. 21 nov. 2018 à 17:46, Adel Atallah  a
écrit :

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


-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [ANN] XWiki 10.10-rc-1 released

[Guillaume Delhumeau]

https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/10.10RC1/#HMacrocontentcanbedeclaredtobeinlineeditable

I've not put it at the beginning of my summary since it's targeted for
developers right now. I don't want user complaining because they cannot
update a macro content with the "inline" mode. AFAIK there is no macro
right now that handle it?

Le mer. 21 nov. 2018 à 16:31, Vincent Massol  a écrit :

> Hi Guillaume,
>
> > On 21 Nov 2018, at 16:21, Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com> wrote:
> >
> > The XWiki development team is proud to announce the availability of XWiki
> > 10.10-rc-1.
>
> Thanks!
>
> > For users, this version brings a protection when a page containing an
> > XClass is moved or renamed. By default, the PDF export looks better now.
> In
> > addition, the recent auto-suggestion feature has been enabled in a few
> > places.
>
> It’s auto-suggestion of page references actually.
>
> > For developers, a new asynchronous framework has been created. It allows
> > the execution of desired parts of the rendering of a page to be executed
> > asynchronously, with an AJAX request. This makes the rendering of the
> page
> > faster, making the least important parts visible after the page is
> loaded.
> >
> > Among other things, Wiki Macros can now have typed parameters and it is
> now
> > possible to make the content of a macro editable inline with the WYSIWYG
> > editor.
>
> This is really the key highlight for users IMO. I would have put this at
> the top as the main user feature.
>
> Also and very importantly it’s missing from
> https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/10.10RC1/.
> That’s bad since it’s the main feature :) Did I miss something?
>
> Thanks
> -Vincent
>
> > To finish, more than 30 bugs have been fixed since XWiki 10.9.
> > 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.10RC1/
> >
> > Thanks for your support
> > -The XWiki dev team
>
>

-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

[xwiki-devs] [ANN] XWiki 10.10-rc-1 released

[Guillaume Delhumeau]

The XWiki development team is proud to announce the availability of XWiki
10.10-rc-1.

For users, this version brings a protection when a page containing an
XClass is moved or renamed. By default, the PDF export looks better now. In
addition, the recent auto-suggestion feature has been enabled in a few
places.

For developers, a new asynchronous framework has been created. It allows
the execution of desired parts of the rendering of a page to be executed
asynchronously, with an AJAX request. This makes the rendering of the page
faster, making the least important parts visible after the page is loaded.

Among other things, Wiki Macros can now have typed parameters and it is now
possible to make the content of a macro editable inline with the WYSIWYG
editor.

To finish, more than 30 bugs have been fixed since XWiki 10.9.
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.10RC1/

Thanks for your support
-The XWiki dev team

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

[Guillaume Delhumeau]

Since the documentation url is already filled in our jira issue, could we
associate the issue number to Release Notes change, and so the url of the
documentation is automatically pulled from jira ? This way we could also
add a link to the jira issue.

My 2 cents,

Le mar. 20 nov. 2018 à 13:12, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> a écrit :

> +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
> >
> >
>


-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

[xwiki-devs] Postpone of XWiki 10.10-rc-1

[Guillaume Delhumeau]

Hello.

To let Marius finish his work, I propose to postpone the release of XWiki
10.10-rc-1 to tomorow.

Thanks,

-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [Proposal] Update database support strategy

[Guillaume Delhumeau]

ther DBs
> > > >>
> > > >> We cannot really support every versions since supporting means
> testing
> > > too.
> > > >>
> > > >> So what I propose:
> > > >>
> > > >> Question 1: definition
> > > >>
> > > >> * We say we support the latest stable version of the databases for a
> > > given version cycle
> > > >> ** For MySQL, it’s the latest of the 5.x cycle, which is 5.7.24 as
> of
> > > today (see https://hub.docker.com/_/mysql/)
> > > >> ** For PostgreSQL,  it’s the latest of the 9.x cycle, which is
> 9.6.10
> > > as of today (see https://hub.docker.com/_/postgres/)
> > > >> ** For Oracle, it’s the latest of the 11.x cycle, which is
> 11.2.0.4.0
> > > as of today (see
> > >
> https://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.html
> > > )
> > > >>
> > > >> Question 2: review what we support
> > > >>
> > > >> * For MySQL I think we could also start supporting MySQL 8.x (ie the
> > > latest version of that cycle). We have an issue open for it currently:
> > > https://jira.xwiki.org/browse/XWIKI-15215
> > > >> * For PostgreSQL we could also start supporting versions 11.x (ie
> the
> > > latest version of that cycle)
> > > >> * For Oracle, we could also start supporting versions 12.x (ie the
> > > latest version of that cycle)
> > > >>
> > > >> Question 3: decide if we drop some support
> > > >>
> > > >> * Is there any cycle that we should support for? Right now I think
> that
> > > MySQL 5.x is still heavily used, same for postgreSQL 9.x I guess. Don’t
> > > know for Oracle.
> > > >> * Any idea?
> > > >>
> > > >> So WDYT about the 3 questions?
> > > >>
> > > >> Thanks
> > > >> -Vincent
> > > >
> > >
> > >
>
>
>
> --
> Thomas Mortagne
>


-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

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

[Guillaume Delhumeau]

Clearly, the way it looks like could be improved, but it does not dismiss
the principle.

Le mer. 31 oct. 2018 à 14:00, Ecaterina Moraru (Valica) 
a écrit :

>
>
> On Wed, Oct 31, 2018 at 1:35 PM Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com> wrote:
>
>> This is what the recycle bin of a Macintosh looks like:
>> https://image.ibb.co/nBjh8L/Recycle-Bin.png
>>
>
> The button you are referencing is not floating in the middle of the page
> or after a 10 items livetable. Its position is inside a clear toolbar.
>
>
>>
>> I think many users think this "clean" button is usefull, even if it is
>> unconsistent with what all other places look like in the Finder. Same with
>> Gmail. And I miss this feature in the Apple "Mail" application.
>>
>> Since "Recycle Bin" is a "special" place with a "special" use-case, I
>> don't think it's horrible to have a special button to make it easy to use.
>> I would hate to have to play with bulk actions for this simple use-case
>> because of "consistency".
>>
>> Le mer. 31 oct. 2018 à 12:22, Ecaterina Moraru (Valica) <
>> vali...@gmail.com> a écrit :
>>
>>> I would be even -1 for any other solution than D. Especially since, if
>>> we do it with C, I don't know when we will come back and redo the
>>> functionality.
>>>
>>>
>>> On Wed, Oct 31, 2018 at 1:18 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.
>>>>
>>>> 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
>>>>>
>>>>
>>
>> --
>> Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
>> Research & Development Engineer at XWiki SAS
>> Committer on the XWiki.org project
>>
>

-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

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

[Guillaume Delhumeau]

This is what the recycle bin of a Macintosh looks like:
https://image.ibb.co/nBjh8L/Recycle-Bin.png

I think many users think this "clean" button is usefull, even if it is
unconsistent with what all other places look like in the Finder. Same with
Gmail. And I miss this feature in the Apple "Mail" application.

Since "Recycle Bin" is a "special" place with a "special" use-case, I don't
think it's horrible to have a special button to make it easy to use. I
would hate to have to play with bulk actions for this simple use-case
because of "consistency".

Le mer. 31 oct. 2018 à 12:22, Ecaterina Moraru (Valica) 
a écrit :

> I would be even -1 for any other solution than D. Especially since, if we
> do it with C, I don't know when we will come back and redo the
> functionality.
>
>
> On Wed, Oct 31, 2018 at 1:18 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.
>>
>> 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
>>>
>>

-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

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

[Guillaume Delhumeau]

+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
> > >
>


-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

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

[Guillaume Delhumeau]

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.
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] [Proposal] Change ObservationManager behaviour with CancelableEvents

[Guillaume Delhumeau]

Le mer. 17 oct. 2018 à 10:47, Simon Urli  a écrit :

>
>
> On 10/17/18 10:35 AM, Guillaume Delhumeau wrote:
> > I'm OK.
> >
> > 
> > I'm just thinking about an other particular case:
> > Imagine you have 3 event listeners (A, B, C):
> > - A receives the event and perform some actions (saving something in the
> > database).
> > - B receives the event and cancels it
> > - C don't receive the event because it had been canceled
> >
> > However, we may want to resend some infos to listener A so it can
> rollback
> > its actions (otherwise we end up with bad info in the database).
> >
> > Do we have a strategy for this?
>
> I don't think we have a strategy for that, but we might add a new method
> in EventListener:
>
> onRollback(CancelableEvent canceledEvent, Object source, Object data)
>
> and store somewhere the list of called listener to be able to call their
> rollback method if the event has been cancelled. Should do the trick, WDYT?
>

Sounds like a good idea, indeed. Or it could be called onCanceled() instead
of onRollback, since the rollback is what we expect, not the event that is
triggered.


>
> > 
> >
> > Le mer. 17 oct. 2018 à 09:09, Thomas Mortagne 
> a
> > écrit :
> >
> >> +1 to stopping event propagation when it's cancelled
> >> On Tue, Oct 16, 2018 at 6: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
> >>
> >>
> >>
> >> --
> >> Thomas Mortagne
> >>
> >
> >
>
> --
> 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

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

[Guillaume Delhumeau]

I'm OK.


I'm just thinking about an other particular case:
Imagine you have 3 event listeners (A, B, C):
- A receives the event and perform some actions (saving something in the
database).
- B receives the event and cancels it
- C don't receive the event because it had been canceled

However, we may want to resend some infos to listener A so it can rollback
its actions (otherwise we end up with bad info in the database).

Do we have a strategy for this?


Le mer. 17 oct. 2018 à 09:09, Thomas Mortagne  a
écrit :

> +1 to stopping event propagation when it's cancelled
> On Tue, Oct 16, 2018 at 6: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
>
>
>
> --
> Thomas Mortagne
>


-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

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

[Guillaume Delhumeau]

Le jeu. 27 sept. 2018 à 16:16, Alex Cotiugă  a
écrit :

> 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.
> >
>
> This sounds to me like an exception from a rule. Time has taught us that
> nothing is unchangeable and we can expect at some point to have some
> content in a non-data-generating app.
> I would prefer to keep the current rule.
>

I agree.


>
>
> > 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
> >
> > Thanks,
> Alex
>


-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [Proposal] Turn off redirects in page move/rename

[Guillaume Delhumeau]

Le jeu. 20 sept. 2018 à 07:30, Vincent Massol  a écrit :

> Hi devs,
>
> We see more and more wikis with tons of redirects and issues to manage
> them, see https://jira.xwiki.org/browse/XWIKI-14570
>
> “
> Rationale for turning it off by default:
> - Several users have reported a usability issue about automatic redirects.
> The way they express it is the following: "I have duplicates pages in my
> wiki. I don't understand why this is happening. I'm choosing to rename
> pages and not to copy them but I still get duplicates in the Navigation
> panel".
>

Can't we hide the original page when we add the redirection so it won't be
listed anymore, instead of changing the default behavior?


> - Automatic redirects are especially useful for public wikis where users
> can have bookmark on pages and you don't want to break them. It can also be
> useful for internal wikis but it's less an issue.
> - Even for public wikis not all pages need automatic redirects. Technical
> pages don't need them for example.
> “
>
> I’ve had Ludovic report that to me too again this morning.
>
> Since we’ve been knowing about the problem for a while already and since
> it’s very easy to change the default behavior, I’d like to propose that we
> turn it off by default in XWiki 10.8 (ie right now, or if you think it’s
> really too dangerous in 10.9), and that we implement an option to configure
> the default behavior later on (https://jira.xwiki.org/browse/XWIKI-13384).
>
> WDYT?
>
> Thanks
> -Vincent
>
>
>

-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

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

[Guillaume Delhumeau]

Congratulations!

2018-08-27 11:31 GMT+02:00 Thomas Mortagne :

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



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [Brainstorm] Notifications Filters Preferences Store.

[Guillaume Delhumeau]

2018-07-25 16:14 GMT+02:00 Guillaume Delhumeau <
guillaume.delhum...@xwiki.com>:

> After more thinking and discussions with Thomas, it appears solution B
> (creating a table with Hibernate) is the only valuable option. These
> preferences are not real data that would need to be stored on the user
> page. They are "temporary" configurations for each user.
>
> In addition, it would permit to optimize the HQL query by linking elements
> of the 2 tables instead of introducing 700 "OR location = xxx". This
> optimization is actually not a nice-to-have thing, but a real requirement
> for scalability.
>

As a drawback, it means users' configurations would not be exportable in a
XAR like the rest of the content...


> 2018-07-20 21:05 GMT+03:00 Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com>:
>
>> XWIKI-15455 <http:///browse/XWIKI-15455> (that I have just created)
>> invalidates both Solution A and C since it requires to store a Date along
>> with each location, so we cannot store several locations in the same
>> Notification Filter Preferences object.
>>
>> 2018-07-19 11:03 GMT+02:00 Guillaume Delhumeau <
>> guillaume.delhum...@xwiki.com>:
>>
>>> FYI, I'll continue with the solution A, which is very close to solution
>>> C, and I'll try to use the less memory possible.
>>>
>>> 2018-07-18 11:27 GMT+02:00 Guillaume Delhumeau <
>>> guillaume.delhum...@xwiki.com>:
>>>
>>>> Corresponding JIRA issue: https://jira.xwiki.org/browse/XWIKI-15445
>>>>
>>>> 2018-07-18 11:07 GMT+02:00 Guillaume Delhumeau <
>>>> guillaume.delhum...@xwiki.com>:
>>>>
>>>>> Hi.
>>>>>
>>>>> [TL;DR]
>>>>>
>>>>> This thread is about the way we store notification filter preferences
>>>>> for each user. The constraint is there can be a lot of them (700 is a
>>>>> number a user has recently reported). So how should we store them?
>>>>>
>>>>> [Full text]
>>>>>
>>>>> = Definition =
>>>>>
>>>>> So what is a filter preference? It's a generic object that can store
>>>>> many elements, such as a page locations, application names, event types,
>>>>> etc... They describe a configuration about a given filter for a given 
>>>>> user.
>>>>> For example, a filter preference can say "for the ScopeNotificationFilter
>>>>> and the user A, include the location Main.WebHome" as it could be "for the
>>>>> UserNotificationFilter and the user A, exclude the user SPAM". It's 
>>>>> generic.
>>>>>
>>>>> The main usage is for page locations (ScopeNotificationFilter). By
>>>>> default, we have the "autowatch" mode enabled. It means every time a user
>>>>> modifies a page, a filter preference for this page and this user is
>>>>> created. So if a user modifies 700 pages, he gets 700 filter preferences.
>>>>>
>>>>> = How are they stored =
>>>>>
>>>>> Currently, we have a simple implementation. There is a generic XClass
>>>>> called "XWiki.Notifications.Code.NotificationFilterPreferenceClass".
>>>>> For each preference, we add an XObject on the user page. It's that simple.
>>>>> But it also means that if a users have 700 filter preferences, she also
>>>>> gets 700 XObjects on her page, and 700 revisions of that page. Which is a
>>>>> pain: it takes a lot of place in the document's cache, and it's heavy to
>>>>> load (lot of SQL queries needed). So we have a big problem here.
>>>>>
>>>>> = Possible solutions =
>>>>>
>>>>> == A: Minimize the number of xobjects needed for
>>>>> ScopeNotificationFilter ==
>>>>>
>>>>> Currently, one location is represented by 1 filter preference. But
>>>>> most filter preferences are very similar. They almost all say "for the
>>>>> ScopeNotificationFilter, for all event types, for all applications, the
>>>>> filter preference is enabled". The only different part is the actual
>>>>> location. But the "location" field is itself a LIST stored with the
>>>>> "relational storage" option. So we can take advantage of it and store
>>>>> similar preferences into 1 single object.
>>>>>
>>>>> 

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

[Guillaume Delhumeau]

+1

2018-08-07 10:48 GMT+02:00 Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com>:

> +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 <http://jira.xwiki.org/browse/XWIKI-7058>: Page
> > creation date should be the date of the installation
> > * Feb 2015: XCOMMONS-1447 <https://jira.xwiki.org/browse/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
> >
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [New extension released] Insta Feed Macro

[Guillaume Delhumeau]

Done.

https://jira.xwiki.org/projects/INSTA/summary

2018-07-28 9:20 GMT+03:00 Vincent Massol :

> Hi Guillaume,
>
> > On 27 Jul 2018, at 16:58, Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com> wrote:
> >
> > Hi.
> >
> > With Lavina Florean, Jean-Sébastien Dennebouy and Mohamed Boussaa, we
> have
> > worked on a wiki macro that display a user's feed from Instagram in a
> wiki
> > page.
> >
> > I've already created the github repository:
> > https://github.com/xwiki-contrib/macro-instafeed
>
> Thanks for doing this. However we have some rules for github repo + jira
> project creations. They are indicated here:
> http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HForXWikiAdmins
>
> Also, we must always create a jira project too. I can’t find it. It’s
> important since otherwise:
> * users can’t report issues
> * you cannot commit since you don’t have a jira issue to reference. So
> this probably means you committed without a jira issue ;)
> * you cannot have release notes easily in the extension page
>
> Thanks
> -Vincent
>
> >
> > The extension's page:
> > http://extensions.xwiki.org/xwiki/bin/view/Extension/
> Insta%20Feed%20Macro/
> >
> > We have also release the first version (0.1)!
> >
> > Enjoy!
>
>


-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

[xwiki-devs] [New extension released] Insta Feed Macro

[Guillaume Delhumeau]

Hi.

With Lavina Florean, Jean-Sébastien Dennebouy and Mohamed Boussaa, we have
worked on a wiki macro that display a user's feed from Instagram in a wiki
page.

I've already created the github repository:
https://github.com/xwiki-contrib/macro-instafeed

The extension's page:
http://extensions.xwiki.org/xwiki/bin/view/Extension/Insta%20Feed%20Macro/

We have also release the first version (0.1)!

Enjoy!

Re: [xwiki-devs] [Brainstorm] Notifications Filters Preferences Store.

[Guillaume Delhumeau]

After more thinking and discussions with Thomas, it appears solution B
(creating a table with Hibernate) is the only valuable option. These
preferences are not real data that would need to be stored on the user
page. They are "temporary" configurations for each user.

In addition, it would permit to optimize the HQL query by linking elements
of the 2 tables instead of introducing 700 "OR location = xxx". This
optimization is actually not a nice-to-have thing, but a real requirement
for scalability.

2018-07-20 21:05 GMT+03:00 Guillaume Delhumeau <
guillaume.delhum...@xwiki.com>:

> XWIKI-15455 <http:///browse/XWIKI-15455> (that I have just created)
> invalidates both Solution A and C since it requires to store a Date along
> with each location, so we cannot store several locations in the same
> Notification Filter Preferences object.
>
> 2018-07-19 11:03 GMT+02:00 Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com>:
>
>> FYI, I'll continue with the solution A, which is very close to solution
>> C, and I'll try to use the less memory possible.
>>
>> 2018-07-18 11:27 GMT+02:00 Guillaume Delhumeau <
>> guillaume.delhum...@xwiki.com>:
>>
>>> Corresponding JIRA issue: https://jira.xwiki.org/browse/XWIKI-15445
>>>
>>> 2018-07-18 11:07 GMT+02:00 Guillaume Delhumeau <
>>> guillaume.delhum...@xwiki.com>:
>>>
>>>> Hi.
>>>>
>>>> [TL;DR]
>>>>
>>>> This thread is about the way we store notification filter preferences
>>>> for each user. The constraint is there can be a lot of them (700 is a
>>>> number a user has recently reported). So how should we store them?
>>>>
>>>> [Full text]
>>>>
>>>> = Definition =
>>>>
>>>> So what is a filter preference? It's a generic object that can store
>>>> many elements, such as a page locations, application names, event types,
>>>> etc... They describe a configuration about a given filter for a given user.
>>>> For example, a filter preference can say "for the ScopeNotificationFilter
>>>> and the user A, include the location Main.WebHome" as it could be "for the
>>>> UserNotificationFilter and the user A, exclude the user SPAM". It's 
>>>> generic.
>>>>
>>>> The main usage is for page locations (ScopeNotificationFilter). By
>>>> default, we have the "autowatch" mode enabled. It means every time a user
>>>> modifies a page, a filter preference for this page and this user is
>>>> created. So if a user modifies 700 pages, he gets 700 filter preferences.
>>>>
>>>> = How are they stored =
>>>>
>>>> Currently, we have a simple implementation. There is a generic XClass
>>>> called "XWiki.Notifications.Code.NotificationFilterPreferenceClass".
>>>> For each preference, we add an XObject on the user page. It's that simple.
>>>> But it also means that if a users have 700 filter preferences, she also
>>>> gets 700 XObjects on her page, and 700 revisions of that page. Which is a
>>>> pain: it takes a lot of place in the document's cache, and it's heavy to
>>>> load (lot of SQL queries needed). So we have a big problem here.
>>>>
>>>> = Possible solutions =
>>>>
>>>> == A: Minimize the number of xobjects needed for
>>>> ScopeNotificationFilter ==
>>>>
>>>> Currently, one location is represented by 1 filter preference. But most
>>>> filter preferences are very similar. They almost all say "for the
>>>> ScopeNotificationFilter, for all event types, for all applications, the
>>>> filter preference is enabled". The only different part is the actual
>>>> location. But the "location" field is itself a LIST stored with the
>>>> "relational storage" option. So we can take advantage of it and store
>>>> similar preferences into 1 single object.
>>>>
>>>> 1 object with 700 locations instead of 700 objects with 1 location.
>>>>
>>>> However, it's a bit harder than this. Event if the
>>>> NotificationFilterPreferences is generic and can contains many locations,
>>>> the ScopeNotificationFilter expect it to concern only one location (and
>>>> then it perform complex operations to sort the filters preferences
>>>> according to a hierarchy). The UI in the user profile makes the same
>>>> assumption so it does not han

Re: [xwiki-devs] [ANN] XWiki 10.6 released

[Guillaume Delhumeau]

Hello.

I just discovered https://jira.xwiki.org/browse/XWIKI-15456 which is an
important bug. I have reverted https://jira.xwiki.org/browse/XWIKI-15440
which is the cause.

I won't be able to release before Sunday. If anyone would want to perform
it in the meantime, feel free!

Sorry for this,

Guillaume

2018-07-20 16:16 GMT+02:00 Alex Cotiugă :

> The XWiki development team is proud to announce the availability of XWiki
> 10.6.
> 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 24 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:
> https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/10.6/
>
>
> Thanks for your support
> -The XWiki dev team
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [Brainstorm] Notifications Filters Preferences Store.

[Guillaume Delhumeau]

XWIKI-15455  (that I have just created) invalidates
both Solution A and C since it requires to store a Date along with each
location, so we cannot store several locations in the same Notification
Filter Preferences object.

2018-07-19 11:03 GMT+02:00 Guillaume Delhumeau <
guillaume.delhum...@xwiki.com>:

> FYI, I'll continue with the solution A, which is very close to solution C,
> and I'll try to use the less memory possible.
>
> 2018-07-18 11:27 GMT+02:00 Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com>:
>
>> Corresponding JIRA issue: https://jira.xwiki.org/browse/XWIKI-15445
>>
>> 2018-07-18 11:07 GMT+02:00 Guillaume Delhumeau <
>> guillaume.delhum...@xwiki.com>:
>>
>>> Hi.
>>>
>>> [TL;DR]
>>>
>>> This thread is about the way we store notification filter preferences
>>> for each user. The constraint is there can be a lot of them (700 is a
>>> number a user has recently reported). So how should we store them?
>>>
>>> [Full text]
>>>
>>> = Definition =
>>>
>>> So what is a filter preference? It's a generic object that can store
>>> many elements, such as a page locations, application names, event types,
>>> etc... They describe a configuration about a given filter for a given user.
>>> For example, a filter preference can say "for the ScopeNotificationFilter
>>> and the user A, include the location Main.WebHome" as it could be "for the
>>> UserNotificationFilter and the user A, exclude the user SPAM". It's generic.
>>>
>>> The main usage is for page locations (ScopeNotificationFilter). By
>>> default, we have the "autowatch" mode enabled. It means every time a user
>>> modifies a page, a filter preference for this page and this user is
>>> created. So if a user modifies 700 pages, he gets 700 filter preferences.
>>>
>>> = How are they stored =
>>>
>>> Currently, we have a simple implementation. There is a generic XClass
>>> called "XWiki.Notifications.Code.NotificationFilterPreferenceClass".
>>> For each preference, we add an XObject on the user page. It's that simple.
>>> But it also means that if a users have 700 filter preferences, she also
>>> gets 700 XObjects on her page, and 700 revisions of that page. Which is a
>>> pain: it takes a lot of place in the document's cache, and it's heavy to
>>> load (lot of SQL queries needed). So we have a big problem here.
>>>
>>> = Possible solutions =
>>>
>>> == A: Minimize the number of xobjects needed for ScopeNotificationFilter
>>> ==
>>>
>>> Currently, one location is represented by 1 filter preference. But most
>>> filter preferences are very similar. They almost all say "for the
>>> ScopeNotificationFilter, for all event types, for all applications, the
>>> filter preference is enabled". The only different part is the actual
>>> location. But the "location" field is itself a LIST stored with the
>>> "relational storage" option. So we can take advantage of it and store
>>> similar preferences into 1 single object.
>>>
>>> 1 object with 700 locations instead of 700 objects with 1 location.
>>>
>>> However, it's a bit harder than this. Event if the
>>> NotificationFilterPreferences is generic and can contains many locations,
>>> the ScopeNotificationFilter expect it to concern only one location (and
>>> then it perform complex operations to sort the filters preferences
>>> according to a hierarchy). The UI in the user profile makes the same
>>> assumption so it does not handle multiple locations in the same preferences
>>> object. Refactoring this is not simple and cannot be done for 10.6.
>>>
>>> === Variation 1: store only 1 xobject, but make the API return 700
>>> preferences objects anyway ===
>>>
>>> This is the variation I am prototyping. Actually it's ok if the filters
>>> and the UI expect only 1 location into the preferences object. All we have
>>> to do is to "smash" the xobject into many NotificationFilterPreferences
>>> objects that we need internally. It would simply be the responsibility of
>>> the Store to detect similarities and to save the minimal amount of XObjects
>>> to store a bunch of preferences.
>>>
>>> But it means being very smart when loading, creating, updating and
>>> deleting a preference. Not having one xobject per filter preference
>>> introduces complexity, an

Re: [xwiki-devs] [Brainstorm] Notifications Filters Preferences Store.

[Guillaume Delhumeau]

FYI, I'll continue with the solution A, which is very close to solution C,
and I'll try to use the less memory possible.

2018-07-18 11:27 GMT+02:00 Guillaume Delhumeau <
guillaume.delhum...@xwiki.com>:

> Corresponding JIRA issue: https://jira.xwiki.org/browse/XWIKI-15445
>
> 2018-07-18 11:07 GMT+02:00 Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com>:
>
>> Hi.
>>
>> [TL;DR]
>>
>> This thread is about the way we store notification filter preferences for
>> each user. The constraint is there can be a lot of them (700 is a number a
>> user has recently reported). So how should we store them?
>>
>> [Full text]
>>
>> = Definition =
>>
>> So what is a filter preference? It's a generic object that can store many
>> elements, such as a page locations, application names, event types, etc...
>> They describe a configuration about a given filter for a given user. For
>> example, a filter preference can say "for the ScopeNotificationFilter and
>> the user A, include the location Main.WebHome" as it could be "for the
>> UserNotificationFilter and the user A, exclude the user SPAM". It's generic.
>>
>> The main usage is for page locations (ScopeNotificationFilter). By
>> default, we have the "autowatch" mode enabled. It means every time a user
>> modifies a page, a filter preference for this page and this user is
>> created. So if a user modifies 700 pages, he gets 700 filter preferences.
>>
>> = How are they stored =
>>
>> Currently, we have a simple implementation. There is a generic XClass
>> called "XWiki.Notifications.Code.NotificationFilterPreferenceClass". For
>> each preference, we add an XObject on the user page. It's that simple. But
>> it also means that if a users have 700 filter preferences, she also gets
>> 700 XObjects on her page, and 700 revisions of that page. Which is a pain:
>> it takes a lot of place in the document's cache, and it's heavy to load
>> (lot of SQL queries needed). So we have a big problem here.
>>
>> = Possible solutions =
>>
>> == A: Minimize the number of xobjects needed for ScopeNotificationFilter
>> ==
>>
>> Currently, one location is represented by 1 filter preference. But most
>> filter preferences are very similar. They almost all say "for the
>> ScopeNotificationFilter, for all event types, for all applications, the
>> filter preference is enabled". The only different part is the actual
>> location. But the "location" field is itself a LIST stored with the
>> "relational storage" option. So we can take advantage of it and store
>> similar preferences into 1 single object.
>>
>> 1 object with 700 locations instead of 700 objects with 1 location.
>>
>> However, it's a bit harder than this. Event if the
>> NotificationFilterPreferences is generic and can contains many locations,
>> the ScopeNotificationFilter expect it to concern only one location (and
>> then it perform complex operations to sort the filters preferences
>> according to a hierarchy). The UI in the user profile makes the same
>> assumption so it does not handle multiple locations in the same preferences
>> object. Refactoring this is not simple and cannot be done for 10.6.
>>
>> === Variation 1: store only 1 xobject, but make the API return 700
>> preferences objects anyway ===
>>
>> This is the variation I am prototyping. Actually it's ok if the filters
>> and the UI expect only 1 location into the preferences object. All we have
>> to do is to "smash" the xobject into many NotificationFilterPreferences
>> objects that we need internally. It would simply be the responsibility of
>> the Store to detect similarities and to save the minimal amount of XObjects
>> to store a bunch of preferences.
>>
>> But it means being very smart when loading, creating, updating and
>> deleting a preference. Not having one xobject per filter preference
>> introduces complexity, and complexity can lead to bugs. Again, according to
>> the time frame, it's hard to implement.
>>
>> === Variation 2: use custom mapping ===
>>
>> Probably the easiest solution that would help making less SQL queries.
>> The idea is to have a SQL table for notification filter preferences and
>> bind the XObjects to that table. It would still use a lot of place in the
>> document's cache but be more efficient on the database level.
>>
>> === Other Problem 1: it still creates page revisions ===
>>
>> As long as we store the filter preferences with xobjects, we crea

Re: [xwiki-devs] [Brainstorm] Notifications Filters Preferences Store.

[Guillaume Delhumeau]

Corresponding JIRA issue: https://jira.xwiki.org/browse/XWIKI-15445

2018-07-18 11:07 GMT+02:00 Guillaume Delhumeau <
guillaume.delhum...@xwiki.com>:

> Hi.
>
> [TL;DR]
>
> This thread is about the way we store notification filter preferences for
> each user. The constraint is there can be a lot of them (700 is a number a
> user has recently reported). So how should we store them?
>
> [Full text]
>
> = Definition =
>
> So what is a filter preference? It's a generic object that can store many
> elements, such as a page locations, application names, event types, etc...
> They describe a configuration about a given filter for a given user. For
> example, a filter preference can say "for the ScopeNotificationFilter and
> the user A, include the location Main.WebHome" as it could be "for the
> UserNotificationFilter and the user A, exclude the user SPAM". It's generic.
>
> The main usage is for page locations (ScopeNotificationFilter). By
> default, we have the "autowatch" mode enabled. It means every time a user
> modifies a page, a filter preference for this page and this user is
> created. So if a user modifies 700 pages, he gets 700 filter preferences.
>
> = How are they stored =
>
> Currently, we have a simple implementation. There is a generic XClass
> called "XWiki.Notifications.Code.NotificationFilterPreferenceClass". For
> each preference, we add an XObject on the user page. It's that simple. But
> it also means that if a users have 700 filter preferences, she also gets
> 700 XObjects on her page, and 700 revisions of that page. Which is a pain:
> it takes a lot of place in the document's cache, and it's heavy to load
> (lot of SQL queries needed). So we have a big problem here.
>
> = Possible solutions =
>
> == A: Minimize the number of xobjects needed for ScopeNotificationFilter ==
>
> Currently, one location is represented by 1 filter preference. But most
> filter preferences are very similar. They almost all say "for the
> ScopeNotificationFilter, for all event types, for all applications, the
> filter preference is enabled". The only different part is the actual
> location. But the "location" field is itself a LIST stored with the
> "relational storage" option. So we can take advantage of it and store
> similar preferences into 1 single object.
>
> 1 object with 700 locations instead of 700 objects with 1 location.
>
> However, it's a bit harder than this. Event if the
> NotificationFilterPreferences is generic and can contains many locations,
> the ScopeNotificationFilter expect it to concern only one location (and
> then it perform complex operations to sort the filters preferences
> according to a hierarchy). The UI in the user profile makes the same
> assumption so it does not handle multiple locations in the same preferences
> object. Refactoring this is not simple and cannot be done for 10.6.
>
> === Variation 1: store only 1 xobject, but make the API return 700
> preferences objects anyway ===
>
> This is the variation I am prototyping. Actually it's ok if the filters
> and the UI expect only 1 location into the preferences object. All we have
> to do is to "smash" the xobject into many NotificationFilterPreferences
> objects that we need internally. It would simply be the responsibility of
> the Store to detect similarities and to save the minimal amount of XObjects
> to store a bunch of preferences.
>
> But it means being very smart when loading, creating, updating and
> deleting a preference. Not having one xobject per filter preference
> introduces complexity, and complexity can lead to bugs. Again, according to
> the time frame, it's hard to implement.
>
> === Variation 2: use custom mapping ===
>
> Probably the easiest solution that would help making less SQL queries. The
> idea is to have a SQL table for notification filter preferences and bind
> the XObjects to that table. It would still use a lot of place in the
> document's cache but be more efficient on the database level.
>
> === Other Problem 1: it still creates page revisions ===
>
> As long as we store the filter preferences with xobjects, we create page
> revisions. We can get rid of those by using some internal API to not create
> a revision when we save an xobject but I wonder if it's what users want. If
> a user tries to rollback some changes and don't see all filter preferences
> it concerns, I think it's not very transparent.
>
> === Other Problem 2: Document's cache ===
>
> Sometime we load the a user document to get the avatar of the user, her
> name, etc... So we load user documents very frequently, even if the user is
> not connected! Having 700 filters in 

[xwiki-devs] [Brainstorm] Notifications Filters Preferences Store.

[Guillaume Delhumeau]

Hi.

[TL;DR]

This thread is about the way we store notification filter preferences for
each user. The constraint is there can be a lot of them (700 is a number a
user has recently reported). So how should we store them?

[Full text]

= Definition =

So what is a filter preference? It's a generic object that can store many
elements, such as a page locations, application names, event types, etc...
They describe a configuration about a given filter for a given user. For
example, a filter preference can say "for the ScopeNotificationFilter and
the user A, include the location Main.WebHome" as it could be "for the
UserNotificationFilter and the user A, exclude the user SPAM". It's generic.

The main usage is for page locations (ScopeNotificationFilter). By default,
we have the "autowatch" mode enabled. It means every time a user modifies a
page, a filter preference for this page and this user is created. So if a
user modifies 700 pages, he gets 700 filter preferences.

= How are they stored =

Currently, we have a simple implementation. There is a generic XClass
called "XWiki.Notifications.Code.NotificationFilterPreferenceClass". For
each preference, we add an XObject on the user page. It's that simple. But
it also means that if a users have 700 filter preferences, she also gets
700 XObjects on her page, and 700 revisions of that page. Which is a pain:
it takes a lot of place in the document's cache, and it's heavy to load
(lot of SQL queries needed). So we have a big problem here.

= Possible solutions =

== A: Minimize the number of xobjects needed for ScopeNotificationFilter ==

Currently, one location is represented by 1 filter preference. But most
filter preferences are very similar. They almost all say "for the
ScopeNotificationFilter, for all event types, for all applications, the
filter preference is enabled". The only different part is the actual
location. But the "location" field is itself a LIST stored with the
"relational storage" option. So we can take advantage of it and store
similar preferences into 1 single object.

1 object with 700 locations instead of 700 objects with 1 location.

However, it's a bit harder than this. Event if the
NotificationFilterPreferences is generic and can contains many locations,
the ScopeNotificationFilter expect it to concern only one location (and
then it perform complex operations to sort the filters preferences
according to a hierarchy). The UI in the user profile makes the same
assumption so it does not handle multiple locations in the same preferences
object. Refactoring this is not simple and cannot be done for 10.6.

=== Variation 1: store only 1 xobject, but make the API return 700
preferences objects anyway ===

This is the variation I am prototyping. Actually it's ok if the filters and
the UI expect only 1 location into the preferences object. All we have to
do is to "smash" the xobject into many NotificationFilterPreferences
objects that we need internally. It would simply be the responsibility of
the Store to detect similarities and to save the minimal amount of XObjects
to store a bunch of preferences.

But it means being very smart when loading, creating, updating and deleting
a preference. Not having one xobject per filter preference introduces
complexity, and complexity can lead to bugs. Again, according to the time
frame, it's hard to implement.

=== Variation 2: use custom mapping ===

Probably the easiest solution that would help making less SQL queries. The
idea is to have a SQL table for notification filter preferences and bind
the XObjects to that table. It would still use a lot of place in the
document's cache but be more efficient on the database level.

=== Other Problem 1: it still creates page revisions ===

As long as we store the filter preferences with xobjects, we create page
revisions. We can get rid of those by using some internal API to not create
a revision when we save an xobject but I wonder if it's what users want. If
a user tries to rollback some changes and don't see all filter preferences
it concerns, I think it's not very transparent.

=== Other Problem 2: Document's cache ===

Sometime we load the a user document to get the avatar of the user, her
name, etc... So we load user documents very frequently, even if the user is
not connected! Having 700 filters in the document and cache them with the
document even if we don't need them is a big waste of memory.

== B: Implement a completely new store with Hibernate ==

A bit like having a custom mapping. We could create a SQL table and
implement an API to handle it. Then, no xobjects would be involved.

Some drawbacks:
* we need to write a custom cache as well.
* the user cannot modify her preferences using the wiki principles
(xobjects all the way).

== C: Refactor the UI and the ScopeNotificationFilter so they do not assume
1 filter preference = 1 location ==

This option is still possible. Probably the best because creating 1 filter
preferences object per location is an 

[xwiki-devs] Fwd: [Brainstorm] Notifications filters capabilities and performances.

[Guillaume Delhumeau]

I resend this message that was accidentally sent to Sergiu only.

-- Forwarded message --
From: Guillaume Delhumeau 
Date: 2018-07-02 16:06 GMT+02:00
Subject: Re: [xwiki-devs] [Brainstorm] Notifications filters capabilities
and performances.
To: Sergiu Dumitriu 


Hi and thanks you for your answers.

2018-06-29 5:41 GMT+02:00 Sergiu Dumitriu :

> The two main problems that I see are that you're mixing two separate
> things:
>
> 1. Tags which are stored in one place, and events which are stored in a
> different place
> 2. Again tags, and document locations. They may seem similar, but they
> are completely different as they are implemented. That's why saying "not
> in this wiki, except for this tag" cannot ever be implemented in a sane
> way since the exception is on a different plane.
>
> The logical approach would be to also store the tags in the events, but
> this is not a good thing to do.


Also, a tag could be added to a page AFTER the event has been triggered. In
this case, if you still want to fetch these pages, it won't work.



> Where do we stop? For future-proofing
> filters, we would have to store the entire document in the event, in
> case someone wants to add a filter on "documents with a specific type of
> object attached", or "documents with a specific value for a specific
> property of a specific object", or "documents with attachments ending in
> .extension".
>
> On 06/28/2018 04:44 PM, Guillaume Delhumeau wrote:
> > For the tags filter, I can also:
> >
> > * perform a query to fetch all documents that correspond to the given
> tags
> > (it doesn't need to be permanent, but it would be better to cache it)
> > * add a HQL filter on these pages (OR document IN :list_of_pages).
> >
> > It's a little variation of solution A. It's ugly but it could do the job.
>
> It's the sanest proposal so far, but still impossible.
>

Apparently it's the way it's done on Activity Stream:
https://github.com/xwiki/xwiki-platform/blob/553afe7287dcc4ce8b588276e639bf
283352e805/xwiki-platform-core/xwiki-platform-activitystream/xwiki-platform-
activitystream-ui/src/main/resources/Main/Activity.xml#L1008


>
> Since "not in LOCATION except WITH TAG" doesn't work because it mixes
> two types of information in the same query fragment, how about making
> this a one-dimensional query as "only WITH TAG". And since this
> information is in a different place, pre-querying it is needed. However,
> if there are thousands or tens/hundreds of thousands of documents with a
> tag, won't the query crash anyway?
>

Sure, it won't scale.


>
> > 2018-06-27 12:58 GMT+02:00 Guillaume Delhumeau <
> > guillaume.delhum...@xwiki.com>:
> >
> >> Hi developers.
> >>
> >> I am trying to add a new filter to the notifications to be able to
> follow
> >> pages
> >> that are marked with a given tag. And it leads me to some questions
> about
> >> the
> >> technical implementation of the notifications.
> >>
> >> To remind the context: notifications are computed on top of the events
> >> recorded
> >> by the event stream (a.k.a activity stream). We take events from the
> event
> >> stream SQL table, we apply some transformations on them, and we display
> >> them to
> >> the user.
> >>
> >> Then we have implemented the ability to filter on these events: for
> >> example
> >> "don't show events concerning the document A nor the wiki B". Filters
> are
> >> implemented with 2 distinct ways:
> >>
> >>   1/ SQL injections: each filter can add SQL elements in the query we
> make
> >> to
> >>  fetch the events from the event stream table. We made this
> mechanism
> >> so we
> >>  can let the database do a lot of the filtering process. After all,
> >> it's its
> >>  job and it's supposed to perform well. To be precise, Clement has
> >> even
> >>  created an Abstract Syntax Tree (AST) so it's easier to inject some
> >> content
> >>  in the query and it creates an abstraction over the SQL language so
> >> we can
> >>  even consider to change the storage of the event stream someday.
> >>
> >>  The bad thing is that some complex filtering are difficult to write
> >> with
> >>  the SQL language (event with the AST) or even impossible.
> >>
> >>   2/ Post-filtering: after the events have been fetched from the
> database,
> >> each
> >>  filter can still decide to keep or filter them. This is use

Re: [xwiki-devs] [Brainstorm] Notifications filters capabilities and performances.

[Guillaume Delhumeau]

Hi Clément,

2018-06-29 13:34 GMT+02:00 Clément Aubin :

> Hi,
>
> With the complexity of the additive filtering system, it's kind of
> normal to see OOM errors. AFAIR we already talked about that a year ago,
> when looking at how we could implement this feature.
>

We could try to improve a bit the situation by "optimizing" the filters.
For example, we can currently end up with filters like these:
- filter events about SpaceA.PageB
- filter events about SpaceA.PageC
- filter events about SpaceA.

Obviously the 2 first filters can be removed since the third one is already
doing their job. I've tried to minimize the number of unnecessary filters
by not creating a new one if the page is already concerned by a wider
filter, but it won't fix existing filters.

An other example is the watch list bridge that simply convert the list of
watched pages as they were in the previous version of XWiki and translate
them to the same number of filters. This may explain many of the OOM
problems. It is even enforced by the fact we had (and we still have) the
"autowatch" mode enabled by default.

So a filter optimizer could be a great help.


>
> On 06/29/2018 05:41 AM, Sergiu Dumitriu wrote:
> > The two main problems that I see are that you're mixing two separate
> things:
> >
> > 1. Tags which are stored in one place, and events which are stored in a
> > different place
> > 2. Again tags, and document locations. They may seem similar, but they
> > are completely different as they are implemented. That's why saying "not
> > in this wiki, except for this tag" cannot ever be implemented in a sane
> > way since the exception is on a different plane.
> >
> > The logical approach would be to also store the tags in the events, but
> > this is not a good thing to do. Where do we stop? For future-proofing
> > filters, we would have to store the entire document in the event, in
> > case someone wants to add a filter on "documents with a specific type of
> > object attached", or "documents with a specific value for a specific
> > property of a specific object", or "documents with attachments ending in
> > .extension".
> >
> > On 06/28/2018 04:44 PM, Guillaume Delhumeau wrote:
> >> For the tags filter, I can also:
> >>
> >> * perform a query to fetch all documents that correspond to the given
> tags
> >> (it doesn't need to be permanent, but it would be better to cache it)
> >> * add a HQL filter on these pages (OR document IN :list_of_pages).
> >>
> >> It's a little variation of solution A. It's ugly but it could do the
> job.
> >
> > It's the sanest proposal so far, but still impossible.
> >
> > Since "not in LOCATION except WITH TAG" doesn't work because it mixes
> > two types of information in the same query fragment, how about making
> > this a one-dimensional query as "only WITH TAG". And since this
> > information is in a different place, pre-querying it is needed. However,
> > if there are thousands or tens/hundreds of thousands of documents with a
> > tag, won't the query crash anyway?
> >
> >> 2018-06-27 12:58 GMT+02:00 Guillaume Delhumeau <
> >> guillaume.delhum...@xwiki.com>:
> >>
> >>> Hi developers.
> >>>
> >>> I am trying to add a new filter to the notifications to be able to
> follow
> >>> pages
> >>> that are marked with a given tag. And it leads me to some questions
> about
> >>> the
> >>> technical implementation of the notifications.
> >>>
> >>> To remind the context: notifications are computed on top of the events
> >>> recorded
> >>> by the event stream (a.k.a activity stream). We take events from the
> event
> >>> stream SQL table, we apply some transformations on them, and we display
> >>> them to
> >>> the user.
> >>>
> >>> Then we have implemented the ability to filter on these events: for
> >>> example
> >>> "don't show events concerning the document A nor the wiki B". Filters
> are
> >>> implemented with 2 distinct ways:
> >>>
> >>>   1/ SQL injections: each filter can add SQL elements in the query we
> make
> >>> to
> >>>  fetch the events from the event stream table. We made this
> mechanism
> >>> so we
> >>>  can let the database do a lot of the filtering process. After all,
> >>> it's its
> >>>  job and it's supposed to perform well. To be precise, Clement has
> 

Re: [xwiki-devs] [Brainstorm] Notifications filters capabilities and performances.

[Guillaume Delhumeau]

For the tags filter, I can also:

* perform a query to fetch all documents that correspond to the given tags
(it doesn't need to be permanent, but it would be better to cache it)
* add a HQL filter on these pages (OR document IN :list_of_pages).

It's a little variation of solution A. It's ugly but it could do the job.

2018-06-27 12:58 GMT+02:00 Guillaume Delhumeau <
guillaume.delhum...@xwiki.com>:

> Hi developers.
>
> I am trying to add a new filter to the notifications to be able to follow
> pages
> that are marked with a given tag. And it leads me to some questions about
> the
> technical implementation of the notifications.
>
> To remind the context: notifications are computed on top of the events
> recorded
> by the event stream (a.k.a activity stream). We take events from the event
> stream SQL table, we apply some transformations on them, and we display
> them to
> the user.
>
> Then we have implemented the ability to filter on these events: for
> example
> "don't show events concerning the document A nor the wiki B". Filters are
> implemented with 2 distinct ways:
>
>   1/ SQL injections: each filter can add SQL elements in the query we make
> to
>  fetch the events from the event stream table. We made this mechanism
> so we
>  can let the database do a lot of the filtering process. After all,
> it's its
>  job and it's supposed to perform well. To be precise, Clement has
> even
>  created an Abstract Syntax Tree (AST) so it's easier to inject some
> content
>  in the query and it creates an abstraction over the SQL language so
> we can
>  even consider to change the storage of the event stream someday.
>
>  The bad thing is that some complex filtering are difficult to write
> with
>  the SQL language (event with the AST) or even impossible.
>
>   2/ Post-filtering: after the events have been fetched from the database,
> each
>  filter can still decide to keep or filter them. This is useful for
>  complex filtering that cannot be expressed with the SQL language. It
> is
>  also needed by the real-time notification email sender, because it
> takes
>  the events immediately when they occurs without fetching them in the
>  database (so SQL filters are bypassed).
>
>  The bad thing is that some events are loaded in the memory to finally
> be
>  rejected, and these filters can perform costly operations such as
> loading
>  documents.
>
> Until now, this double mechanism was working quite well, with each
> mechanism
> filling the lacks of the other.
>
> However, we still have technical limitations in our design:
>
>   1/ Users who have a lot of filter preferences can end up with a giant
> SQL
>  query that is almost impossible to perform by the database. Actually
> we had
>  a user complaining about an OutOfMemory problem in the HQL to SQL
>  translator !
>
>   2/ I cannot implement the tag filter !
>
> The tag filter is supposed to show events that concern pages that hold a
> given
> tag, EVEN IF THE PAGE WAS EXCLUDED BY THE USER. Example of use-case: "I
> don't
> want to receive notifications about wiki A except for pages marked with
> the tag
> T".
>
> And it is not working. First because it is difficult to write a SQL query
> for
> that. It requires to make a join clause with the document and the object
> tables,
> which our SQL injection mechanism does not support. Even if it were
> possible,
> creating a SQL join with the document table will de-facto filter events
> that do
> not concern any pages or pages that do not have any objects: so many other
> filters will be broken. I also don't consider creating a SQL subquery, I
> think
> the whole query would became too big. So I decided to just not inject any
> SQL
> code for this filter and only implement the post-filtering mechanism.
>
> But the other filter "EXCLUDE WIKI A" generates a SQL injection such as
> "WIKI <> 'WIKI A'" so the events concerning the wiki A are not fetched
> from the
> database. Consequence: the tag filter never see the events that it is
> supposed
> to keep. It would be actually possible to by-pass the first SQL injections
> by
> injecting something like "OR 1=1". But doing something like this is like
> dropping the all SQL injections mechanism.
>
> I see some solutions for this problem:
>
>   A/ For each tag, create a permanent list of pages that hold it. So I can
>  inject "OR document IN (that_list)". I think this is heavy.
>
>   B/ Drop the SQL injection mechanism and only rely on the post-filtering
>  mechanism. It would 

[xwiki-devs] [Brainstorm] Notifications filters capabilities and performances.

[Guillaume Delhumeau]

Hi developers.

I am trying to add a new filter to the notifications to be able to follow
pages
that are marked with a given tag. And it leads me to some questions about
the
technical implementation of the notifications.

To remind the context: notifications are computed on top of the events
recorded
by the event stream (a.k.a activity stream). We take events from the event
stream SQL table, we apply some transformations on them, and we display
them to
the user.

Then we have implemented the ability to filter on these events: for example
"don't show events concerning the document A nor the wiki B". Filters are
implemented with 2 distinct ways:

  1/ SQL injections: each filter can add SQL elements in the query we make
to
 fetch the events from the event stream table. We made this mechanism
so we
 can let the database do a lot of the filtering process. After all,
it's its
 job and it's supposed to perform well. To be precise, Clement has even
 created an Abstract Syntax Tree (AST) so it's easier to inject some
content
 in the query and it creates an abstraction over the SQL language so we
can
 even consider to change the storage of the event stream someday.

 The bad thing is that some complex filtering are difficult to write
with
 the SQL language (event with the AST) or even impossible.

  2/ Post-filtering: after the events have been fetched from the database,
each
 filter can still decide to keep or filter them. This is useful for
 complex filtering that cannot be expressed with the SQL language. It
is
 also needed by the real-time notification email sender, because it
takes
 the events immediately when they occurs without fetching them in the
 database (so SQL filters are bypassed).

 The bad thing is that some events are loaded in the memory to finally
be
 rejected, and these filters can perform costly operations such as
loading
 documents.

Until now, this double mechanism was working quite well, with each
mechanism
filling the lacks of the other.

However, we still have technical limitations in our design:

  1/ Users who have a lot of filter preferences can end up with a giant SQL
 query that is almost impossible to perform by the database. Actually
we had
 a user complaining about an OutOfMemory problem in the HQL to SQL
 translator !

  2/ I cannot implement the tag filter !

The tag filter is supposed to show events that concern pages that hold a
given
tag, EVEN IF THE PAGE WAS EXCLUDED BY THE USER. Example of use-case: "I
don't
want to receive notifications about wiki A except for pages marked with the
tag
T".

And it is not working. First because it is difficult to write a SQL query
for
that. It requires to make a join clause with the document and the object
tables,
which our SQL injection mechanism does not support. Even if it were
possible,
creating a SQL join with the document table will de-facto filter events
that do
not concern any pages or pages that do not have any objects: so many other
filters will be broken. I also don't consider creating a SQL subquery, I
think
the whole query would became too big. So I decided to just not inject any
SQL
code for this filter and only implement the post-filtering mechanism.

But the other filter "EXCLUDE WIKI A" generates a SQL injection such as
"WIKI <> 'WIKI A'" so the events concerning the wiki A are not fetched from
the
database. Consequence: the tag filter never see the events that it is
supposed
to keep. It would be actually possible to by-pass the first SQL injections
by
injecting something like "OR 1=1". But doing something like this is like
dropping the all SQL injections mechanism.

I see some solutions for this problem:

  A/ For each tag, create a permanent list of pages that hold it. So I can
 inject "OR document IN (that_list)". I think this is heavy.

  B/ Drop the SQL injection mechanism and only rely on the post-filtering
 mechanism. It would require to load from the database A LOT of events,
 but maybe we could cache this.

  C/ Don't drop the SQL injection mechanism completely but use it as little
as
 possible (for example, do not use it for LOCATION filtering). Seems
hard to
 determine when a filter should use this feature or not.

  D/ Don't implement the "tags" filter, since it is the root of the issue.
But
 it is like sweeping dirt under the carpet!

Since we have the OutOfMemory problem with the SQL injections becoming too
huge,
I am more in favor of solution B or C. But I'm not sure for now, since I do
not
know how much it would impact the performances and the scalability of the
whole
notifications feature.

This is a complex topic, but I hope this message will inspire you some
suggestions or things I have not seen with my own eyes.

Thanks for your help,

Guillaume

Re: [xwiki-devs] [XWiki Day] BFD#182

[Guillaume Delhumeau]

Hi.

The results are available:
https://www.xwiki.org/xwiki/bin/view/Blog/Bug%20Fixing%20Day%20182

Thanks!

2018-06-21 10:11 GMT+02:00 Guillaume Delhumeau <
guillaume.delhum...@xwiki.com>:

> Hello devs,
>
> This Thursday is BFD#182:
> http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingday
>
> Our current status is:
> * -52 bugs over 120 days (4 months), i.e. we need to close 52 bugs to have
> created bugs # = closed bugs #
> * -96 bugs over 365 days (1 year)
> * -154 bugs over 500 days (between 1 and 2 years)
> * -326 bugs over 1600 days (4.3 years)
>
> See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352
>
> Here's the BFD#181 dashboard to follow the progress during the day:
> https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14305
>
> Happy Bug Fixing Day,
> Guillaume
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

[xwiki-devs] [ANN] XWiki 9.11.6 released

[Guillaume Delhumeau]

The XWiki development team is proud to announce the availability of XWiki
9.11.6.
This is a bugfix release that covers important issues that we have
discovered since 9.11.5 has been released.

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/9.11.6

Thanks for your support
-The XWiki dev team

[xwiki-devs] [XWiki Day] BFD#182

[Guillaume Delhumeau]

Hello devs,

This Thursday is BFD#182:
http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingday

Our current status is:
* -52 bugs over 120 days (4 months), i.e. we need to close 52 bugs to have
created bugs # = closed bugs #
* -96 bugs over 365 days (1 year)
* -154 bugs over 500 days (between 1 and 2 years)
* -326 bugs over 1600 days (4.3 years)

See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352

Here's the BFD#181 dashboard to follow the progress during the day:
https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14305

Happy Bug Fixing Day,
Guillaume

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

[Guillaume Delhumeau]

I like all these ideas. It's both more modern and more intuitive (the
"configure" button). How does it look if the left panel has less width ?

I'm not 100% about the stick panels. If we do it, we should do for both
panel sides. The scrollbars should be hidden most of the time (it's not
very elegant) but in the same time, it must be very clear that you can
scroll. But I like the idea.

2018-06-19 17:29 GMT+02:00 Ecaterina Moraru (Valica) :

> Hi devs,
>
> Some ideas that could be applied to left panels area:
>
> * Mark "More applications" as expandable
> * Provide a "Customize" panel button on hover
> * Some styling changes
> * Demo: show sticky left panels would behave
>
> 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
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [Brainstorming] Removing Watchlist & Activity Stream from XS?

[Guillaume Delhumeau]

2018-06-11 14:13 GMT+02:00 Vincent Massol :

> Hi Guillaume,
>
> > On 11 Jun 2018, at 10:56, Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com> wrote:
> >
> > Hi Vincent
> >
> > 2018-06-08 11:45 GMT+02:00 Vincent Massol :
> >
> >> Hi devs,
> >>
> >> Now that Notifications is providing an equivalent feature (and
> supposedly
> >> much faster, we still need some measurements on that!), we need to think
> >> about decommissioning the AS and Watchlist features.
> >>
> >> Decommissioning means moving them to xwiki-attic IMO.
> >>
> >> So the questions:
> >>
> >> * Are there any features still missing to replace the AS? For example
> the
> >> AS had the ability to display a RSS feed and other parameters, see
> >> http://extensions.xwiki.org/xwiki/bin/view/Extension/Activity%20Macro#
> >> HParametersdefinition. Are all of these having equivalents or other ways
> >> of doing them?
> >>
> >
> > * We have an RSS view, but it's not available from the macro. So it need
> to
> > be added if we want to keep it.
>
> I don’t think it’s that useful to have the RSS feed have a UI in the
> macro. However, I think it’s useful to be able to have a RSS feed for a
> specific configuration of the notifications (essentially this is what the
> macro does: configures the notifications to work in a given way). AFAIU the
> only RSS feed we have ATM is a fixed feed for the default notifications in
> your user profile. So something more generic would be nice. I guess that
> would mean a script service to return a RSS feed URL for some parameters
> passed (the same params as those on the macro) + a generic RSS feed wiki
> page that accepts parameters. WDYT?


It's indeed what we need, but note that the URL could generated by the
Notifications Macro itself (no need to create a script service, except if
we plan to use the URL in other modules).


>
> Do we have a jira issue for this?
>

Created: https://jira.xwiki.org/browse/XWIKI-15344


>
> > * We don't have a "tag" filter. Need to be added.
>
> Ok. Do we have a jira issue for it?
>

Created: https://jira.xwiki.org/browse/XWIKI-15343

This is a use-case that is needed only for AS, because I don't think it
make sense, inside the notifications system, to filter upon a tag.


>
> >
> >>
> >> * Personal note and especially for Caty: I don’t like too much the big
> >> icons that we have ATM. For example http://extensions.xwiki.org/
> >> xwiki/bin/view/Extension/User%20Profile%20Application#
> >> HSeetheNetworkActivity. I don’t think the replacement of the main AS
> with
> >> the notifications macro will look very nice with these icons. I already
> >> stated that I thought the user-focused view was much nicer visually but
> I
> >> was one of the few to think so from what I remember ;) Still even if we
> >> keep the icons, I think there’s some work to make the UI more appealling
> >> visually. WDYT?
> >>
> >> * When can we replace AS with notifications macro? I’d suggest to do
> that
> >> for 10.6-RC1. WDYT? AFAIK there are 2 places: user profiles + Dashboard
> >> home page.
> >>
> >
> > If we don't care about the 2 remaining items I've mentioned above, we
> could
> > do it for 10.6RC1.
> >
> >
> >>
> >> * Once the previous item is done, can we remove AS + watchlist from XS
> >> easily now? What does it entail, just moving xwiki-platform-watchlist
> and
> >> xwiki-platform-activitystream. Actually I think we need to first move
> the
> >> message stream sending UI to another place. I’d propose inside the alert
> >> menu as a UIX when message stream is enabled (that would be fast and
> simple
> >> to do and we could tune the location later, it doesn’t matter much since
> >> it’s off by default anyway). Could we do this in XWiki 10.6RC1?
> >>
> >
> > We can only get rid of Activity Stream's UI. Because the storage is still
> > implemented by Activity Stream's API (as the unique implementation of
> > xwiki-platform-eventstream).
>
> So another item in the todo list then:
> * Move the implementation to xwiki-platform-eventstream
>
> Do we have a jira for this?
>

It's more a new implementation that is needed, since the current one use
"activitystream" in the table names. We might take the occasion to think
about a new storage.

For now, I consider it's safer to stick to the ActivityStream
implementation (which is not visible from the UI) since it allows us to use
both AS and Notifications

Re: [xwiki-devs] [Brainstorming] Removing Watchlist & Activity Stream from XS?

[Guillaume Delhumeau]

Hi Vincent

2018-06-08 11:45 GMT+02:00 Vincent Massol :

> Hi devs,
>
> Now that Notifications is providing an equivalent feature (and supposedly
> much faster, we still need some measurements on that!), we need to think
> about decommissioning the AS and Watchlist features.
>
> Decommissioning means moving them to xwiki-attic IMO.
>
> So the questions:
>
> * Are there any features still missing to replace the AS? For example the
> AS had the ability to display a RSS feed and other parameters, see
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Activity%20Macro#
> HParametersdefinition. Are all of these having equivalents or other ways
> of doing them?
>

* We have an RSS view, but it's not available from the macro. So it need to
be added if we want to keep it.
* We don't have a "tag" filter. Need to be added.


>
> * Personal note and especially for Caty: I don’t like too much the big
> icons that we have ATM. For example http://extensions.xwiki.org/
> xwiki/bin/view/Extension/User%20Profile%20Application#
> HSeetheNetworkActivity. I don’t think the replacement of the main AS with
> the notifications macro will look very nice with these icons. I already
> stated that I thought the user-focused view was much nicer visually but I
> was one of the few to think so from what I remember ;) Still even if we
> keep the icons, I think there’s some work to make the UI more appealling
> visually. WDYT?
>
> * When can we replace AS with notifications macro? I’d suggest to do that
> for 10.6-RC1. WDYT? AFAIK there are 2 places: user profiles + Dashboard
> home page.
>

If we don't care about the 2 remaining items I've mentioned above, we could
do it for 10.6RC1.


>
> * Once the previous item is done, can we remove AS + watchlist from XS
> easily now? What does it entail, just moving xwiki-platform-watchlist and
> xwiki-platform-activitystream. Actually I think we need to first move the
> message stream sending UI to another place. I’d propose inside the alert
> menu as a UIX when message stream is enabled (that would be fast and simple
> to do and we could tune the location later, it doesn’t matter much since
> it’s off by default anyway). Could we do this in XWiki 10.6RC1?
>

We can only get rid of Activity Stream's UI. Because the storage is still
implemented by Activity Stream's API (as the unique implementation of
xwiki-platform-eventstream).


>
> * Anything else I’ve forgotten?
>
> So the plan seems to be, in this order:
> 1) Replace AS with notifications macro.
> 2) Move Message Stream sending UI outside of AS
>

I'm not sure I understand. The Message Sender Macro is defined in
https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-messagestream/xwiki-platform-messagestream-ui/src/main/resources/Main/MessageSenderMacro.xml
so I don't think we need to move something out of AS.


> 3) Move xwiki-platform-watchlist and xwiki-platform-activitystream to
> xwiki-attic and update their docs on e.x.o to explain how to put them back
> if needed
>
>
IMO we should wait for the next cycle to move the modules out.



> Thanks
> -Vincent
>
>
>
>
>
Thanks,


-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

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

[Guillaume Delhumeau]

t; >>>> 
> > >>>>   
> > >>>>   …
> > >>>> {{/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
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Thomas Mortagne
> >
> >
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

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

[Guillaume Delhumeau]

ssages, it’s not useful
> > >>>
> > >>> I see some use cases for live messages, but I'm indeed having a hard
> > >>> time seeing use cases for non-live messages as people can use another
> > >>> chat tool aside from their wiki if we don't propose an "inbox"
> > solution.
> > >>>
> > >>> It won't be reliable to send a message as :
> > >>> * It can be filtered out by the recipient notification preferences
> > >>> * It can be ditched in the bottom of the notifications of a user if
> he
> > /
> > >>> she does not clean his / her notifications quickly enough
> > >>> * There's no way to access this message once the notification center
> > has
> > >>> been cleared
> > >>>
> > >>>> What I’m saying:
> > >>>> * We don't have chat feature and that’s a very large feature to
> > develop with a completely different architecture.
> > >>>
> > >>> At least we agree on that :)
> > >>>
> > >>>> * A messaging feature is still interesting even if we have a chat
> > feature one day. Example use case: "send a message to everyone that the
> > xwiki will be be upgraded tomorrow”, “ notify a group of person to
> review a
> > document”, etc.
> > >>>
> > >>> Note that what you described are events and can actually be
> implemented
> > >>> using the event stream, so I'm not sure that those are correct
> > examples.
> > >>
> > >> A message is an event for which the content is defined by the user.
> Not
> > sure what you mean.
> > >
> > > Not sure about what you mean too then … following your definition, [1]
> > > is then a user message and [2] and [3] are not. At least, that's what I
> > > understand as "user messages”.
> >
> > I was trying to understand what you meant by “Note that what you
> described
> > are events and can actually be implemented
> > using the event stream, so I'm not sure that those are correct
> examples.”.
> >
> > Messages *ARE* implemented using the event stream :)
> >
> > Thanks
> > -Vincent
> >
> > >
> > >>>
> > >>>> * It costs little to be back to iso feature (1-2 days) and it’s
> > taking almost the same amount of time just to discuss not doing it in
> this
> > thread ;)
> > >>>
> > >>> I don't like this idea as this is kind of discouraging the discussion
> > on
> > >>> features that we have to put in the platform ([1], especially "Ensure
> > >>> agreement on the work being done (it's too stupid to do a lot of work
> > >>> and only find when it's finished that it wasn't the right way to do
> it
> > >>> and it has to be all redone again)") ;)
> > >>
> > >> What? You lost me completely here.
> > >>
> > >> Why does it discourage discussions to implement something?
> > >>
> > >> If you’re interested in working on a chat system in xwiki, please
> knock
> > yourself up and start a proposal/discussion. Nobody is preventing you
> from
> > doing that.
> > >>
> > >> Thanks
> > >> -Vincent
> > >>
> > >>>
> > >>>> * I don’t see why messaging would be bad and affect the XWiki usage
> > >>> negatively. Especially since message stream is off by default.
> > >>>
> > >>> See the beginning of my response.
> > >>>
> > >>>> Thanks
> > >>>> -Vincent
> > >>>
> > >>> Thanks,
> > >>> Clément
> > >
> > > [1]
> > > http://design.xwiki.org/xwiki/bin/view/Proposal/
> > UserMessageNotifications#HUserMessages
> > > [2]
> > > http://design.xwiki.org/xwiki/bin/view/Proposal/
> > UserMessageNotifications#HUserMentions
> > > [3]
> > > http://design.xwiki.org/xwiki/bin/view/Proposal/
> > UserMessageNotifications#HAppNotifications
> >
> >
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

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

[Guillaume Delhumeau]

2018-05-31 17:24 GMT+02:00 Guillaume Delhumeau <
guillaume.delhum...@xwiki.com>:

> I see a problem. If the message stream is disabled, the preferences
> buttons about the messages are still displayed in the notification
> settings...
>
> The way it works is by fetching all components that match some the role
> "RecordableEventDescriptor", but there is no conditional section to decide
> either or not the preference concerning the event type should be displayed.
>

I will just introduce a new isEnabled() method to the descriptor. Sorry for
the noise.



>
> 2018-05-31 16:42 GMT+02:00 Vincent Massol :
>
>>
>>
>> > On 31 May 2018, at 16:23, Clément Aubin  wrote:
>> >
>> > On 05/31/2018 03:18 PM, Vincent Massol wrote:
>> >> Hi Clement,
>> >>
>> >>> On 31 May 2018, at 14:56, Clément Aubin  wrote:
>> >>
>> >> [snip]
>> >>
>> >>>>
>> >>>> All others: if you have any recommendation or counter argument,
>> please post
>> >>>> it quickly :)
>> >>>
>> >>> I don't have a good knowledge of the "old" message stream
>> >>> implementation, however, I'm concerned about the ability of the
>> >>> notification system to act as a messaging center.
>> >>>
>> >>> - When working on multiple documents, I might end up talking with
>> >>> multiple people at the same time. What would happen to the
>> notification
>> >>> center ? Would I have a composite event with all of my conversations
>> in
>> >>> it, or one composite notification per user I'm talking with, which
>> would
>> >>> probably fill most of the notification center ?
>> >>
>> >> This is not supported ATM (see http://extensions.xwiki.org/xw
>> iki/bin/view/Extension/Message%20Stream%20Application/) so no issue FTM.
>> You can only send messages to a given user, to a group or to everyone.>
>> >> I don’t see a problem to add this feature later on if we need it.
>> >
>> > I'm here describing my own usage of collaborative platforms or social
>> > networks. If it wasn't supported before today, maybe we should think
>> > about it, because usually, people with only one friend to talk to are
>> > rare. Having multiple conversation is something that we should at least
>> > think about.
>>
>> Did I say we should not think about it?
>>
>> Also as I wrote you can send to a group and to everyone too so yes you
>> can send to multiple people.
>>
>> > Also, as you mentioned it in the end of your previous mail, "if we do
>> > nothing now, nothing will happen for at least 1 year", what makes you
>> > think that we'll have the time to improve the feature later on, even if
>> > we do need it ?
>>
>> Ok so we have a big disagreement:
>> * You say “displaying notifications in the proposed way is bad thing and
>> there’s no use case for it”
>> * I say “‘displaying notifications for those who want to send messages to
>> a single person, to a group or to everyone is better than not being able to
>> do it”.
>>
>> Also note that it’s disabled by default ATM so by default you get what
>> you want, i.e. nothing!
>>
>> >
>> >>> - When being in a wiki, I might end up staying 1, 2 hours or more on
>> the
>> >>> same page, either to edit it or to read it and refer to it from time
>> to
>> >>> time. The messaging feature of the notification is interesting here if
>> >>> and only if we have the ability to auto-refresh the notification
>> center
>> >>> every X seconds / minutes to check for new events or, in this case,
>> new
>> >>> messages. AFAIK, this feature isn't in place for now.
>> >>
>> >> I don’t see this related at all to messaging. You have the same
>> problem for any kind of notifications. This is related to live
>> notifications and something generic for the notifications feature.
>> >>
>> >> I don’t agree with "The messaging feature of the notification is
>> interesting here if and only if we have the ability to auto-refresh the
>> notification center every X seconds”. Again I don’t see why this is related
>> only to messaging and also I find it more useful to have messaging than
>> nothing (which is what you propose). I can imagine plenty of use cases
>> where it’s still useful to have messaging without the auto refresh. I
>> c

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

[Guillaume Delhumeau]

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.

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

[xwiki-devs] [ANN] XWiki 9.11.5 released

[Guillaume Delhumeau]

The XWiki development team is proud to announce the availability of XWiki
9.11.5.
It is a bugfix release that covers important issues that we have discovered
since 9.11.4 has been released. It also includes a feature from XWiki 10.4:
the notifications macro, that is designed to replace Activity Stream soon.

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/9.11.5/

Thanks for your support
-The XWiki dev team

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

[Guillaume Delhumeau]

+1

2018-05-24 10:20 GMT+02:00 Thomas Mortagne <thomas.morta...@xwiki.com>:

> +1
>
> On Thu, May 24, 2018 at 9:34 AM, Vincent Massol <vinc...@massol.net>
> 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
>
>
>
> --
> Thomas Mortagne
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

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

[Guillaume Delhumeau]

gt; in the navigation panel.
> >
>
> this is the same principle as blacklisting (only "reversed"), and as far as
> I can project now, it already has a workaround: having multiple
> documentTree calls with the root parameter set and showroots to true.
> Also, the default create button of the wiki creates pages on the root of
> the wiki, next to "Main" and this would mean that the administrator would
> need to update the navigation panel any time a page is created, which is
> way more often than "any time an extension is installed".
>
>
> >
> > Pros:
> > * the whitelist doesn't depend on the installed extensions or hidden
> pages
> > so it's easier to maintain.
> > * the whitelist can be used to order the top level pages visible in the
> > navigation panel.
> > * the whitelist can be used to show at the top level (for navigation
> > purpose) a page that is not really a top level page
> > * No performance penalty
> >
> > Cons:
> > * The user (top level) pages created later on will not be visible in the
> > navigation panel. The administrator will have to add them to the
> whitelist
> > if they are useful for the navigation. Although creating top level pages
> > should happen less often than creating nested pages under the existing
> top
> > level pages.
> >
>
> err, how? The create button displayed on the homepage - the only create
> button that you see when you start on an empty wiki - creates top level
> pages! (there's actually a bug in 9.11.3, I explicitly changed the location
> to the "Home" page, and it still created a toplevel page).
>
> Indeed, if the administrator has an idea about what would be put on the
> wiki, he can create the toplevel pages, but 1/ it's not always the case, 2/
> he might not want to, leaving users to organise their content as they wish.
>
>
> > * the whitelist controls only the first level in the tree. The next
> levels
> > will be dynamic (database queries) and with the default order.
> >
> >
> > Solution 4: Exclude extension pages
>
>
> > Exclude from the navigation panel the top level pages that belong to an
> > installed extension, allowing the administrator to make some exceptions
> > (e.g. keep the home page). The rationale is that if an installed
> extension
> > has a top level page then that page is most probably the application home
> > page which should be accessible from the application panel. This can be
> > implemented on top of solution 3 (the whitelist is basically dynamic: we
> > collect the top level pages that don't belong to an extension).
> >
>
> This is _very_ close to the cases I had, but the difference between
> "exactly" and "very close" is relevant, to me: obviously, some XWiki,
> Sandbox and other standard content needed to be removed, but also a custom
> page that I had created and manually put in the application panel.
>
> So, in my opinion, the work to do this is comparable to the work for
> implementing explicit blacklisted roots, so between this and 2, I choose 2.
>
> Long story short:
> I believe, as Vincent said, that we need to have the generic whitelist /
> blacklist parameters for the documentTree macro, in order to cover the
> maximum cases possible, and in my opinion, they all exist, because there is
> a great diversity in what users can do on the wiki but also in how they
> interpret some things: some people see applications as "special", some
> others don't, etc.
>
> For the navigation panel default blacklist we can make some dynamic
> computing of the parameters we pass to the documentTree call, e.g. all
> extensions, or some configuration in administration.
>
> As a priority choice between blacklist and whitelist, I would choose
> blacklist, as some sort of whitelist already exists, even if not fully
> complete and anyway it covers less "user content" cases than the blacklist
> one.
>
> Thanks,
> Anca
>
>
> >
> > Pros:
> > * It does a clear separation between applications (accessible from the
> > application panel) and content (accessible from the navigation panel).
> The
> > navigation panel is currently mixing application pages and (user) content
> > pages.
> > * The administrator doesn't need to update the navigation panel
> > configuration to exclude a top level application home page each time an
> > application is installed
> > * The hidden top level extension code pages are not shown even when "show
> > hidden pages" is set to true
> > * The user top level pages created later on appear in the tree
> > automatically
> >
> > Cons:
> > * The user won't be able to navigate easily to an application home page:
> > ** if the application panel is not shown
> > ** or if the application doesn't provide an application panel entry
> > ** or if the administrator has removed the entry from the application
> panel
>
>
> >
> > I prefer solution 4.
> >
> > WDYT?
> >
> > Thanks,
> > Marius
> >
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [VOTE] Is it OK to edit a standard color theme

[Guillaume Delhumeau]

and Vincent.
> > >>>
> > >>> Guillaume I'm not sure if you prefer 2) or 3) (i.e. what do you think
> > >>> about delete ?).
> > >>>
> > >>>
> > >>
> > >>> Marius, does your proposal means you are more for 1) but with the
> > >>> difference that the default color theme would be allowed for edit ?
> > >>>
> > >>
> > >> Yes, but I'm ok with 2)
> > >>
> > >>
> > >>>
> > >>> Any other point of view input ?
> > >>>
> > >>> On Wed, Apr 25, 2018 at 1:50 PM, Ecaterina Moraru (Valica)
> > >>> <vali...@gmail.com> wrote:
> > >>>> On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne <
> > >>> thomas.morta...@xwiki.com>
> > >>>> wrote:
> > >>>>
> > >>>>> On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol <
> vinc...@massol.net
> > >
> > >>>>> wrote:
> > >>>>>> To give my opinion, I’m hesitating about 2 approaches:
> > >>>>>>
> > >>>>>> Approach 1: “standard"
> > >>>>>> ==
> > >>>>>>
> > >>>>>> * We should have “Default Color Theme” be a copy from the Iceberg
> > >>> color
> > >>>>> theme page. I think I’d prefer the copy to be done at runtime; for
> > >>> example
> > >>>>> if the currently defined color theme page doesn’t exist when going
> to
> > >>> the
> > >>>>> L > Themes admin page, create it by copying Iceberg. This
> provides
> > a
> > >>> self
> > >>>>> healing feature if the color theme page has been removed/doesn’t
> > >>> exist/etc.
> > >>>>>>
> > >>>>>> * Predefined color theme pages should be considered “standard”
> and a
> > >>>>> warning message displayed if a user wants to edit them. BTW would
> be
> > >>> nice
> > >>>>> to have a feature to have a customized message per “type”. For
> > example
> > >>> for
> > >>>>> color theme pages we would display a message saying that the user
> > >> should
> > >>>>> copy the page to customize it instead of editing it.
> > >>>>>>
> > >>>>>> * The Color Theme UI should also be improved a bit to have a
> > >>> “Customize”
> > >>>>> button on color theme pages that would perform a copy to let the
> user
> > >>>>> customize a theme.
> > >>>>>>
> > >>>>>> Approach 2: “demo"
> > >>>>>> 
> > >>>>>>
> > >>>>>> * Consider all color themes to be demo content and once the user
> > >>> starts
> > >>>>> modifying them don’t merge them anymore
> > >>>>>> * When we want to provide modified color themes, introduce new
> theme
> > >>>>> pages
> > >>>>>> * Don’t provide a “Default Color Theme” page. Directly set
> “Iceberg”
> > >>> to
> > >>>>> be the default CT.
> > >>>>>>
> > >>>>>> Analysis
> > >>>>>> ===
> > >>>>>>
> > >>>>>> Approach 2 is more wiki style and simpler for sure. Users can use
> > >> the
> > >>>>> diff feature and the rollback feature if they want to go back to
> the
> > >>>>> original versions.
> > >>>>>>
> > >>>>>> I think I’m leaning more towards 2 ATM.
> > >>>>>
> > >>>>> So you think delete is OK too, right ?
> > >>>>>
> > >>>>
> > >>>> For me delete is ok too. IMO we should provide just a few themes by
> > >>>> default, and the user should be able to uninstall and install what
> > >> themes
> > >>>> he wants (ideally he would be able to preview them live).
> > >>>>
> > >>>> I don't like the copying part very much. Users like to have a base
> to
> > >>> start
> > >>>> from, but they also have history as a fallback.
> > >>>>
> > >>>> Also we rarely make changes to ColorThemes, especially since they
> are
> > >> not
> > >>>> very complex since they should contain only variables. Still it all
> > >>> depends
> > >>>> on how well the Default Theme is tested initially.
> > >>>>
> > >>>> Thanks,
> > >>>> Caty
> > >>>>
> > >>>>
> > >>>>>
> > >>>>>>
> > >>>>>> Thanks
> > >>>>>> -Vincent
> > >>>>>>
> > >>>>>>> On 25 Apr 2018, at 11:35, Vincent Massol <vinc...@massol.net>
> > >> wrote:
> > >>>>>>>
> > >>>>>>> Is this a VOTE or a proposal or a brainstorming? I’m asking since
> > >>>>> nobody has voted yet, not even Thomas (except if we consider that
> > >>> “prefer”
> > >>>>> means +1 and “OK” means +0 ;)).
> > >>>>>>>
> > >>>>>>> From the answer it seems we might need a new VOTE since several
> new
> > >>>>> points have been added to the discussion. I’m not able to VOTE
> right
> > >>> now.
> > >>>>>>>
> > >>>>>>> Thanks
> > >>>>>>> -Vincent
> > >>>>>>>
> > >>>>>>>> On 23 Apr 2018, at 12:29, Thomas Mortagne <
> > >>> thomas.morta...@xwiki.com>
> > >>>>> wrote:
> > >>>>>>>>
> > >>>>>>>> Hi xwikiers,
> > >>>>>>>>
> > >>>>>>>> Following new XAR entry type mail here is a question about color
> > >>>>>>>> themes we provide in standard XWiki (Cerulean, Charcoal, etc.).
> > >>>>>>>>
> > >>>>>>>> 1) Standard stuff, if you want a custom color theme create a new
> > >> one
> > >>>>>>>> (would be nice to be able to copy a standard one and propose it
> > >> when
> > >>>>>>>> you try to edit a standard one).
> > >>>>>>>>
> > >>>>>>>> 2) Demo content, edit and delete it all you want and upgrade
> won't
> > >>>>>>>> touch a customized theme to avoid surprises (background color
> > >>> changed
> > >>>>>>>> a bit in the standard version which now collide with your logo)
> > >>>>>>>>
> > >>>>>>>> 3) Same as 2 but delete is bad (same as home page)
> > >>>>>>>>
> > >>>>>>>> WDYT ?
> > >>>>>>>>
> > >>>>>>>> I'm think I prefer 1) but I'm OK with 3) if other think it's
> more
> > >>>>>>>> example than standard material. Let's say -0 for 2).
> > >>>>>>>>
> > >>>>>>>> Thanks,
> > >>>>>>>> --
> > >>>>>>>> Thomas Mortagne
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>> Thomas Mortagne
> > >>>>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Thomas Mortagne
> > >>>
> > >>
> >
> >
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [VOTE] Is it OK to edit a standard color theme

[Guillaume Delhumeau]

to customize it instead of editing it.
> >>>>>>
> >>>>>> * The Color Theme UI should also be improved a bit to have a
> >>> “Customize”
> >>>>> button on color theme pages that would perform a copy to let the user
> >>>>> customize a theme.
> >>>>>>
> >>>>>> Approach 2: “demo"
> >>>>>> 
> >>>>>>
> >>>>>> * Consider all color themes to be demo content and once the user
> >>> starts
> >>>>> modifying them don’t merge them anymore
> >>>>>> * When we want to provide modified color themes, introduce new theme
> >>>>> pages
> >>>>>> * Don’t provide a “Default Color Theme” page. Directly set “Iceberg”
> >>> to
> >>>>> be the default CT.
> >>>>>>
> >>>>>> Analysis
> >>>>>> ===
> >>>>>>
> >>>>>> Approach 2 is more wiki style and simpler for sure. Users can use
> >> the
> >>>>> diff feature and the rollback feature if they want to go back to the
> >>>>> original versions.
> >>>>>>
> >>>>>> I think I’m leaning more towards 2 ATM.
> >>>>>
> >>>>> So you think delete is OK too, right ?
> >>>>>
> >>>>
> >>>> For me delete is ok too. IMO we should provide just a few themes by
> >>>> default, and the user should be able to uninstall and install what
> >> themes
> >>>> he wants (ideally he would be able to preview them live).
> >>>>
> >>>> I don't like the copying part very much. Users like to have a base to
> >>> start
> >>>> from, but they also have history as a fallback.
> >>>>
> >>>> Also we rarely make changes to ColorThemes, especially since they are
> >> not
> >>>> very complex since they should contain only variables. Still it all
> >>> depends
> >>>> on how well the Default Theme is tested initially.
> >>>>
> >>>> Thanks,
> >>>> Caty
> >>>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>> Thanks
> >>>>>> -Vincent
> >>>>>>
> >>>>>>> On 25 Apr 2018, at 11:35, Vincent Massol <vinc...@massol.net>
> >> wrote:
> >>>>>>>
> >>>>>>> Is this a VOTE or a proposal or a brainstorming? I’m asking since
> >>>>> nobody has voted yet, not even Thomas (except if we consider that
> >>> “prefer”
> >>>>> means +1 and “OK” means +0 ;)).
> >>>>>>>
> >>>>>>> From the answer it seems we might need a new VOTE since several new
> >>>>> points have been added to the discussion. I’m not able to VOTE right
> >>> now.
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>> -Vincent
> >>>>>>>
> >>>>>>>> On 23 Apr 2018, at 12:29, Thomas Mortagne <
> >>> thomas.morta...@xwiki.com>
> >>>>> wrote:
> >>>>>>>>
> >>>>>>>> Hi xwikiers,
> >>>>>>>>
> >>>>>>>> Following new XAR entry type mail here is a question about color
> >>>>>>>> themes we provide in standard XWiki (Cerulean, Charcoal, etc.).
> >>>>>>>>
> >>>>>>>> 1) Standard stuff, if you want a custom color theme create a new
> >> one
> >>>>>>>> (would be nice to be able to copy a standard one and propose it
> >> when
> >>>>>>>> you try to edit a standard one).
> >>>>>>>>
> >>>>>>>> 2) Demo content, edit and delete it all you want and upgrade won't
> >>>>>>>> touch a customized theme to avoid surprises (background color
> >>> changed
> >>>>>>>> a bit in the standard version which now collide with your logo)
> >>>>>>>>
> >>>>>>>> 3) Same as 2 but delete is bad (same as home page)
> >>>>>>>>
> >>>>>>>> WDYT ?
> >>>>>>>>
> >>>>>>>> I'm think I prefer 1) but I'm OK with 3) if other think it's more
> >>>>>>>> example than standard material. Let's say -0 for 2).
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> --
> >>>>>>>> Thomas Mortagne
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Thomas Mortagne
> >>>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Thomas Mortagne
> >>>
> >>
>
>


-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [VOTE] Is it OK to edit a standard color theme

[Guillaume Delhumeau]

2018-04-23 13:46 GMT+02:00 Ecaterina Moraru (Valica) <vali...@gmail.com>:

> I don't know why I don't like this "copy" solution. Maybe because
> everything will feel less "wiki" like.
> Everything will become like a template, including color themes. Lot's of
> duplication instead of relying on the history.
>
> Another solution (that applies only for the use case of Color Themes and
> Skins) would be to externalize the Logo property.
>

+1


>
> On Mon, Apr 23, 2018 at 2:38 PM, Thomas Mortagne <
> thomas.morta...@xwiki.com>
> wrote:
>
> > Yes that's why I sent this mail.
> >
> > But as I suggested there is always ways to make them not do that if we
> > want those theme to stay standard. For example the UI could automate a
> > bit the creation of a copy of the standard theme you want to customize
> > (ask you the new name, etc.).
> >
> > On Mon, Apr 23, 2018 at 12:47 PM, Ecaterina Moraru (Valica)
> > <vali...@gmail.com> wrote:
> > > The major problem is that some users reused the Color Themes as they
> > were,
> > > but they have "customized" them by adding their own logo.
> > >
> > > On Mon, Apr 23, 2018 at 1:29 PM, Thomas Mortagne <
> > thomas.morta...@xwiki.com>
> > > wrote:
> > >
> > >> Hi xwikiers,
> > >>
> > >> Following new XAR entry type mail here is a question about color
> > >> themes we provide in standard XWiki (Cerulean, Charcoal, etc.).
> > >>
> > >> 1) Standard stuff, if you want a custom color theme create a new one
> > >> (would be nice to be able to copy a standard one and propose it when
> > >> you try to edit a standard one).
> > >>
> > >> 2) Demo content, edit and delete it all you want and upgrade won't
> > >> touch a customized theme to avoid surprises (background color changed
> > >> a bit in the standard version which now collide with your logo)
> > >>
> > >> 3) Same as 2 but delete is bad (same as home page)
> > >>
> > >> WDYT ?
> > >>
> > >> I'm think I prefer 1) but I'm OK with 3) if other think it's more
> > >> example than standard material. Let's say -0 for 2).
> > >>
> > >> Thanks,
> > >> --
> > >> Thomas Mortagne
> > >>
> >
> >
> >
> > --
> > Thomas Mortagne
> >
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] Onboarding feedback

[Guillaume Delhumeau]

2018-04-19 11:05 GMT+02:00 Adel Atallah <adel.atal...@xwiki.com>:

> Hello everyone,
>
> I've been following the onboarding tracks 1 and 2 on the past days, here is
> what I can say:
> The first track really helped me to get started in XWiki contributions as I
> could easily pick a jira issue to work on. The issue description was clear
> even though we had to discuss it on the chat. Speaking of the chat, it has
> been a very valuable tool, people have been very responsive and I was
> rarely stuck. I found the development practice a bit inconvenient at first,
> having to make changes in the vm files of my XWiki instance and then report
> the changes to the sources.


On my side I like to use a diff tool to compare the templates of my running
instance to the corresponding folder in my source files. For example, with
the tool "meld", I do:

meld ~/xwiki/instance/webapps/xwiki/templates/
~/xwiki/platform/xwiki-platform-core/xwiki-platform-web/src/main/webapp/templates/

Or, for flamingo:

meld ~/xwiki/instance/webapps/xwiki/skins/flamingo/
~/xwiki/platform/xwiki-platform-core/xwiki-platform-flamingo/xwiki-platform-flamingo-skin/xwiki-platform-flamingo-skin-resources/src/main/resources/flamingo

On my computer, I have created bash aliases for these 2 commands so I can
start a diff very quickly.

Then, it's very easy to see which files has changed, and I can copy them to
the sources directory with a single click.

I hope it helps,

Thanks


> I would have love to see a way to link my
> source files (especially for vm/js/css files) with the one of my XWiki
> instance to avoid errors when I copy past my changes (and get benefit of my
> git ecosystem).
> The second track is a good introduction to some XWiki concepts, I don't
> have much to say for this one. A link to a real application could maybe
> give a better understanding.
>
> Thanks again for the help I had!
>
> <http://www.xwiki.com/> *Adel Atallah*
> *Product developer intern*
> adel.atal...@xwiki.com <corina.lu...@xwiki.com>
> tel: +33 (0)6 12 96 35 06
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [Proposal] Autogenerate release note summaries

[Guillaume Delhumeau]

2018-04-18 11:12 GMT+02:00 Thomas Mortagne <thomas.morta...@xwiki.com>:

> On Tue, Apr 17, 2018 at 10:39 AM, Vincent Massol <vinc...@massol.net>
> wrote:
> >
> >
> >> On 17 Apr 2018, at 10:35, Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com> wrote:
> >>
> >> +1 since we want to release often, it's better to have a lot of things
> >> automated.
> >>
> >> Additional proposition: automate the blog post
> >
> > We need the summary so if we automate the summary we can indeed automate
> the blog post.
>
> Yes what we do now by hand is pretty much just copy/pasting summary in
> some template right now. We should ideally automate it even if we
> don't automate the summary (i.e. we should extract the summary from
> the RN).
>
> >
> >> and the twitter message that
> >> announce the release.
> >
> > This is already automated AFAIK.
>
> Yes the twitt is sent by a script.
>

Yes but you still need to write its content :) (except is someone has
changed it since the last release I performed).


>
> >
> > Thanks
> > -Vincent
> >
> >>
> >> 2018-04-17 10:31 GMT+02:00 Vincent Massol <vinc...@massol.net>:
> >>
> >>>
> >>>
> >>>> On 17 Apr 2018, at 10:28, Vincent Massol <vinc...@massol.net> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> I’d like to modify the Release Notes app to autogenerate summaries for
> >>> releases.
> >>>>
> >>>> The idea is to auto generate it based on the headings for user ,
> admins
> >>> and devs headers.
> >>>>
> >>>> For ex, taking the 10.2 release notes it would give:
> >>>>
> >>>> "For users: New default Color Theme, Figure Macro, Rename/Move
> >>> protection and Minor changes do not generate notifications anymore. For
> >>> admins: Default Notifications. For Developers: REST API now supports
> the
> >>> use of minor revision for page changes, Translation fallback and Jobs
> >>> improvements.”
> >>>
> >>> To give a comparions this is how we manually summarised it:
> >>>
> >>> "This release has a fresh look thanks to its new default color theme. A
> >>> new Figure macro is available for content creators to add illustrations
> >>> along with optional captions. Renaming and moving standard pages is now
> >>> discouraged with a warning message that should prevent editors from
> >>> breaking XWiki.”
> >>>
> >>> Ofc, the manual summary is nicer but I think the automated one could be
> >>> enough for the user to know the topics and then check the release
> notes to
> >>> understand better what’s in it.
> >>>
> >>> Context: This is an effort to automate further our release process and
> to
> >>> win some more minutes.
> >>>
> >>> Thanks
> >>> -Vincent
> >>>
> >>>>
> >>>> It's not too bad IMO.
> >>>>
> >>>> WDYT?
> >>>>
> >>>> Thanks
> >>>> -Vincent
> >
>
>
>
> --
> Thomas Mortagne
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [Proposal] Autogenerate release note summaries

[Guillaume Delhumeau]

+1 since we want to release often, it's better to have a lot of things
automated.

Additional proposition: automate the blog post and the twitter message that
announce the release.

2018-04-17 10:31 GMT+02:00 Vincent Massol <vinc...@massol.net>:

>
>
> > On 17 Apr 2018, at 10:28, Vincent Massol <vinc...@massol.net> wrote:
> >
> > Hi,
> >
> > I’d like to modify the Release Notes app to autogenerate summaries for
> releases.
> >
> > The idea is to auto generate it based on the headings for user , admins
> and devs headers.
> >
> > For ex, taking the 10.2 release notes it would give:
> >
> > "For users: New default Color Theme, Figure Macro, Rename/Move
> protection and Minor changes do not generate notifications anymore. For
> admins: Default Notifications. For Developers: REST API now supports the
> use of minor revision for page changes, Translation fallback and Jobs
> improvements.”
>
> To give a comparions this is how we manually summarised it:
>
> "This release has a fresh look thanks to its new default color theme. A
> new Figure macro is available for content creators to add illustrations
> along with optional captions. Renaming and moving standard pages is now
> discouraged with a warning message that should prevent editors from
> breaking XWiki.”
>
> Ofc, the manual summary is nicer but I think the automated one could be
> enough for the user to know the topics and then check the release notes to
> understand better what’s in it.
>
> Context: This is an effort to automate further our release process and to
> win some more minutes.
>
> Thanks
> -Vincent
>
> >
> > It's not too bad IMO.
> >
> > WDYT?
> >
> > Thanks
> > -Vincent
> >
>
>


-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [Discussion] Coding practice for location of internal package name

[Guillaume Delhumeau]

When I need to write code that I don't want to be seen as public API, I put
it in the internal package (that's the definition).

Now, if I have a lot of code that I want to keep internal, I create
sub-packages under that "internal" package.

Because sometimes, it doesn't make any sense to create dozens of empty
packages just to have an "internal" package at the deeper level that
actually have code.

Thanks

2018-04-16 18:28 GMT+02:00 Vincent Massol <vinc...@massol.net>:

> Hi devs,
>
> On Matrix/IRC, I’ve posted the following:
>
> "
> * Guillaume Delhumeau: BTW your naming is strange for the internal package
> * for ex: package org.xwiki.notifications.preferences.internal.email;
> * normally we put internal just after the main package part
> * ie.
> * org.xwiki.notifications.internal.*
> * and org.xwiki.notifications.* for public classes
> * see http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle/
> JavaCodeStyle/#HPackagenames
> * General rule is org.xwiki.(module name).internal.
> * I see thomas has done the same “error" for
> org.xwiki.job.handler.internal and org.xwiki.job.handler.internal.question
> . So maybe there's something to discuss/change
> * I guess we have a mix of both now so we should discuss it and adjust our
> rules if need be
> “
>
> So I think we don’t have all the same rules/understanding of the
> definition at http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle/
> JavaCodeStyle/#HPackagenames
>
> I’d like to discuss with you to see what you prefer and adjust our rules
> so that it matches what we do in practice.
>
> Any take in this?
>
> Thanks
> -Vincent




-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [Proposal] Invest in a new translation service

[Guillaume Delhumeau]

 We could also ask XWiki SAS if they’d accept paying a “Basic” plan
> (200
> > euros/year which is affordable IMO vs hosting it ourselves)
> > ** There’s a REST API so that if we want we can provide a view/status of
> > the translations from xwiki.org: https://docs.weblate.org/en/
> > latest/api.html . We could even imagine using this API to convert from a
> > format to our own format, if need be.
> > * Propose to have a developer work on this in an upcoming roadmap (to be
> > defined but as early as possible since l10n is not in good shape)
> > * Fix l10n as much as we can without spending too much time on it, until
> > we have the new translation service ready to be used
> >
> > Things to look at:
> > * Ability to register custom formats or more generally how to handle our
> > custom format
> > * How do we handle deprecated translations keys
> > * How do we handle global rename/move of keys from one resource file to
> > another
> > * 
> >
> > WDYT?
> >
> > I’d like to have especially Thomas’s POV since he’s the one who spent the
> > most time on l10n and I’d like to make sure he’s ok with this.
> >
> > Thanks
> > -Vincent
> >
> >
> >
> >
> >
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [VOTE] Add new check to measure quality of tests

[Guillaume Delhumeau]

+1

2018-03-15 11:26 GMT+01:00 Thomas Mortagne <thomas.morta...@xwiki.com>:

> +1
>
> On Thu, Mar 15, 2018 at 9:30 AM, Vincent Massol <vinc...@massol.net>
> wrote:
> > Hi devs,
> >
> > As part of the STAMP research project, we’ve developed a new tool
> (Descartes, based on Pitest) to measure the quality of tests. It generates
> a mutation score for your tests, defining how good the tests are. Technical
> Descartes performs some extreme mutations on the code under test (e.g.
> remove content of void methods, return true for methods returning a
> boolean, etc - See https://github.com/STAMP-project/pitest-descartes). If
> the test continues to pass then it means it’s not killing the mutant and
> thus its mutation score decreases.
> >
> > So in short:
> > * Jacoco/Clover: measure how much of the code is tested
> > * Pitest/Descartes: measure how good the tests are
> >
> > Both provide a percentage value.
> >
> > I’m proposing to compute the current mutation scores for xwiki-commons
> and xwiki-rendering and fail the build when new code is added that reduce
> the mutation score threshold (exactly the same as our jacoco threshold and
> strategy).
> >
> > I consider this is an experiment to push the limit of software
> engineering a bit further. I don’t know how well it’ll work or not. I
> propose to do the work and test this for over 2-3 months and see how well
> it works or not. At that time we can then decide whether it works or not
> (i.e whether the gains it brings are more important than the problems it
> causes).
> >
> > Here’s my +1 to try this out.
> >
> > Some links:
> > * pitest: http://pitest.org/
> > * descartes: https://github.com/STAMP-project/pitest-descartes
> > * http://massol.myxwiki.org/xwiki/bin/view/Blog/ControllingTestQuality
> > * http://massol.myxwiki.org/xwiki/bin/view/Blog/MutationTestingDescartes
> >
> > If you’re curious, you can see a screenshot of a mutation score report
> at http://massol.myxwiki.org/xwiki/bin/download/Blog/
> MutationTestingDescartes/report.png
> >
> > Please cast your votes.
> >
> > Thanks
> > -Vincent
>
>
>
> --
> Thomas Mortagne
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [ANN] XWiki 9.11.3 released

[Guillaume Delhumeau]

Erratum: this version does not disable the Watchlist and enable all
Notification features by default, but still correct import bugs discovered
in the 9.11.2 version.

2018-02-28 11:16 GMT+01:00 Guillaume Delhumeau <
guillaume.delhum...@xwiki.com>:

> The XWiki development team is proud to announce the availability of XWiki
> 9.11.3.
>
> This is a bugfix release that covers important issues that we have
> discovered since 9.11.2 has been released, but it also disable the
> Watchlist and enable all Notification features by default
>
> 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/9.11.3/
>
> Thanks for your support
> -The XWiki dev team
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

[xwiki-devs] [ANN] XWiki 9.11.3 released

[Guillaume Delhumeau]

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

This is a bugfix release that covers important issues that we have
discovered since 9.11.2 has been released, but it also disable the
Watchlist and enable all Notification features by default

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/9.11.3/

Thanks for your support
-The XWiki dev team

Re: [xwiki-devs] [VOTE] Refresh the default Color Theme for XWiki 10.x

[Guillaume Delhumeau]

* Dawn looks nice when used with the Groupware Flavor.
* Pantera is very nice but looks too geek for a default color theme.
* Iceberg is nice but a bit sad

For me the winner is Cotton Candy. Looks fresh and colorful, and not too
geek.

2018-02-23 17:55 GMT+01:00 Ecaterina Moraru (Valica) <vali...@gmail.com>:

> Hi devs,
>
> As part of the 10.1 roadmap there was an investigation in order to refresh
> the UI for XWiki Standard 10.x in order to differentiate it from the older
> versions.
>
> Here is the detailed proposal with more screenshots:
> http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemes10x/
>
> I've also run a community vote at
> https://forum.xwiki.org/t/refresh-the-default-color-
> theme-for-xwiki-10-x/2677
> in order to see the general preference.
>
> As committers, please state your vote also in this mail thread, so that I
> can count the votes properly and with the correct weight to them.
>
> Let me know if you have other proposals or questions.
>
> Thanks,
> Caty
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [Usability] Create a dedicated Logo section in Administration

[Guillaume Delhumeau]

2018-02-21 18:57 GMT+01:00 Vincent Massol <vinc...@massol.net>:

>
>
> > On 21 Feb 2018, at 18:03, Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com> wrote:
> >
> > Do we know a single person that have different logos in the different
> > spaces of the same wiki?
> >
> > I've never met any, but I don't know all users.
> >
> > To me, it just creates confusion for 99% of users, for the sake of
> helping
> > 1% of them (supposing they know how to do it).
> >
> > That would be ok if that 1% were contributors to XWiki, but it does not
> > seem to be the situation.
> >
> > My proposal is to have a single input, for the logo of the current wiki
> > (subwikis can fallback to the main one), et trash all the other options.
>
> If XWiki wasn’t a platform I’d agree. However it’s a platform so we need
> the ability.


You still have the ability to override the skin.


> Thus we just need to make the main use case (the 99%) extra easy and
> simple and hide the advanced options so that users don’t see them by
> default but so that it’s still possible.
>
> Thanks
> -Vincent
>
>
> >
> > My 2 cents,
> >
> > Guillaume
>
>


-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [Usability] Create a dedicated Logo section in Administration

[Guillaume Delhumeau]

Do we know a single person that have different logos in the different
spaces of the same wiki?

I've never met any, but I don't know all users.

To me, it just creates confusion for 99% of users, for the sake of helping
1% of them (supposing they know how to do it).

That would be ok if that 1% were contributors to XWiki, but it does not
seem to be the situation.

My proposal is to have a single input, for the logo of the current wiki
(subwikis can fallback to the main one), et trash all the other options.

My 2 cents,

Guillaume

Re: [xwiki-devs] [Brainstorming] LaTeX Renderer - Styling

[Guillaume Delhumeau]

ition table
> column content (left, centered, right) or whether the rows and/or columns
> of your table have vertical and horizontal lines (or other configs,
> autowrap, etc).
> >>>>
> >>>> The idea is that the Tex Renderer would support some custom
> tex-specific parameters. For example:
> >>>>
> >>>> (% tex-table-spec=“c | c | c" tex-table-floating="true"
> tex-table-caption="caption" %)
> >>>> |=A|=B
> >>>> (% tex-table-row-ending="\hline" %)|a|b
> >>>>
> >>>> (by default the table spec would be left aligned with vertical lines,
> and rows would be separated by horizontal lines).
> >>>>
> >>>> If you have some comments or ideas, please let me know.
> >>>>
> >>>> Inventing a CSS-like mechanism would just be too hard to implement
> IMO.
> >>>>
> >>>> Thanks
> >>>> -Vincent
> >>>>
> >>>> PS: If you want to see table options in LaTeX, see
> https://en.wikibooks.org/wiki/LaTeX/Tables
>
>


-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [VOTE] Enable notifications about XWiki pages by default

[Guillaume Delhumeau]

2018-02-14 16:25 GMT+01:00 Clément Aubin <aubincl...@gmail.com>:

> Hi Guillaume,
>
> On 02/14/2018 02:19 PM, Guillaume Delhumeau wrote:
> > Hi devs.
> >
> > This vote is about enabling notifications about "page" events (create,
> > update, delete, comment) by default, for both notification menu and
> emails.
> > I think it is important since watchlist is replaced by notifications in
> the
> > next version. If the user does not enable it, then even if there is a
> > bridge between the watchlist preferences and the notifications, she won't
> > receive emails anymore.
> >
> > Moreover, it makes this feature more discoverable (for sure!).
> >
> > Here is my +1.
>
> +1 too ; regarding notification emails, my best guess would be to enable
> the «Daily Email» option.
>

Thanks for your vote.


>
> Also, it would be nice to add a footer in the notifications emails with
> a link to the notification center, in order to help the user manage its
> subscription options if he wishes to disable or filter its notifications.
>

It's already the case, but in the header :)


>
> > Thanks,
> >
> > PS: my plan was initially to have it for 10.1RC1 and 9.11.3. Regarding
> the
> > time-frame, I'm not sure we can do it for 10.1RC1. So either we do it for
> > 10.1 final or 10.2RC1.
> >
>
> Thanks,
> Clément
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

[xwiki-devs] [VOTE] Enable notifications about XWiki pages by default

[Guillaume Delhumeau]

Hi devs.

This vote is about enabling notifications about "page" events (create,
update, delete, comment) by default, for both notification menu and emails.
I think it is important since watchlist is replaced by notifications in the
next version. If the user does not enable it, then even if there is a
bridge between the watchlist preferences and the notifications, she won't
receive emails anymore.

Moreover, it makes this feature more discoverable (for sure!).

Here is my +1.

Thanks,

PS: my plan was initially to have it for 10.1RC1 and 9.11.3. Regarding the
time-frame, I'm not sure we can do it for 10.1RC1. So either we do it for
10.1 final or 10.2RC1.

-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [Usability] Create a dedicated Logo section in Administration

[Guillaume Delhumeau]

+1

2018-02-09 14:34 GMT+01:00 Ecaterina Moraru (Valica) <vali...@gmail.com>:

> Hi,
>
> As some of you know, in January we had another session of usability tests
> performed. As a result of those tests, I have prioritized [1] some issues
> that we might want to improve in our next 10.x+ Roadmaps.
>
> One of the entries from that list is: "Create a dedicated Logo section in
> Administration".
>
> Although we made some improvements in this area, users still struggle to
> find the Logo changing area (takes more than 3 minutes). Plus there is a
> lot of confusion between the Skin and ColorThemes overriding.
>
> This is a proposal to explicitly have a Logo section inside the Themes
> section of Administration
> http://design.xwiki.org/xwiki/bin/view/Proposal/
> IdeaChangeLogo#HSolution1-1
>
> Let me know what you think,
> Caty
>
> [1]
> http://design.xwiki.org/xwiki/bin/view/Proposal/Usability/
> Tasks5/Prioritization/
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [VOTE] Disable the Watchlist by default

[Guillaume Delhumeau]

Thanks you. Let's do it!

2018-02-01 15:55 GMT+01:00 Clément Aubin <aubincl...@gmail.com>:

> Hello,
>
> +1 for both ;
>
> Thanks,
> Clément
>
> On 02/01/2018 12:14 PM, Ecaterina Moraru (Valica) wrote:
> > +1
> >
> > Thanks,
> > Caty
> >
> > On Thu, Feb 1, 2018 at 12:20 PM, Guillaume Delhumeau <
> > guillaume.delhum...@xwiki.com> wrote:
> >
> >> VOTE 1: Disable the Watchlist by default and enable all Notifications
> >> features on XWiki 10.1 RC 1
> >> +1
> >>
> >> VOTE 2: Disable the Watchlist by default and enable all Notifications
> >> features on XWiki 9.12.3 so the LTS has good options enabled by default
> >> +1
> >>
> >> Thanks,
> >>
> >> --
> >> Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
> >> Research & Development Engineer at XWiki SAS
> >> Committer on the XWiki.org project
> >>
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [VOTE] Disable the Watchlist by default

[Guillaume Delhumeau]

2018-02-01 11:28 GMT+01:00 Vincent Massol <vinc...@massol.net>:

> Hi Guillaume/all,
>
> > On 1 Feb 2018, at 11:20, Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com> wrote:
> >
> > VOTE 1: Disable the Watchlist by default and enable all Notifications
> > features on XWiki 10.1 RC 1
> > +1
>
> Could you explain what you mean by “enable all notifications”?
>

I meant having the "Watched Entities" (
http://extensions.xwiki.org/xwiki/bin/view/Extension/Notifications%20Application/#HWatchedEntities)
enabled, which mean having the toggles in the alert menu in the same place
that we had them for Watchlist. Disabling Watchlist without this is a
non-sense actually.


>
> Does this mean that any user by default will receive all events happening
> on the wiki?
>

That's an other idea. Interesting that you don't like it


>
> If so, I don’t think I agree. All other system I know only send you
> notifications/emails for stuff you interact with.
>
> This could make sense only for an admin IMO (not even sure there) but not
> for all users.
>
> BTW did you port the autowatch feature to notifications?
>

Yes but it seems I have not written the documentation for that yet.


>
> What would make sense to me would be:
> 1) When enabling an app, also enable email by default
> 2) to auto send notifications & emails for pages that you’ve created or
> made changes to (including commenting on). And ofc add ability for the user
> to change that setting in his/her profile
>
> > VOTE 2: Disable the Watchlist by default and enable all Notifications
> > features on XWiki 9.12.3 so the LTS has good options enabled by default
> > +1
>
> So right now I’m -0 on both VOTE1 and VOTE2 till I understand better what
> it means.
>
> I’m +1 to disable the watchlist by default though for both branches.
>

> Thanks
> -Vincent
>
> > Thanks,
> >
> > --
> > Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
> > Research & Development Engineer at XWiki SAS
> > Committer on the XWiki.org project
>
>


-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

[xwiki-devs] [VOTE] Disable the Watchlist by default

[Guillaume Delhumeau]

VOTE 1: Disable the Watchlist by default and enable all Notifications
features on XWiki 10.1 RC 1
+1

VOTE 2: Disable the Watchlist by default and enable all Notifications
features on XWiki 9.12.3 so the LTS has good options enabled by default
+1

Thanks,

-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [ANN] XWiki 9.11.2 released

[Guillaume Delhumeau]

Good job! Thanks Thomas.

2018-01-31 12:52 GMT+01:00 Thomas Mortagne <thomas.morta...@xwiki.com>:

> The XWiki development team is proud to announce the availability of
> XWiki 9.11.2.
> This is a bugfix release that covers important issues that we have
> discovered since 9.11.1 has been released.
>
> 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/9.11.2
>
> Thanks for your support
> -The XWiki dev team
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

[xwiki-devs] KnockoutJs is a great library

[Guillaume Delhumeau]

Hi developers,

We have never really decided what we will do with javascript frameworks in
the future. Angular was a good candidate at some point, and we have even
used it in the File Manager application. But then we have been very
disappointed when we discovered the new versions of Angular were not
retro-compatible. It may have been fixed since then, but I have not really
followed the news about it.

An other disadvantage of AngularJS is that it does too much. For example,
they have a custom component system with a kind of dependencies injections.
But we already can do that with RequireJS, for which it is the job. I have
already started to split my JavaScript's code in several components thanks
to RequireJS, and it works well. I think it's good to continue with
RequireJS. It is currently our go-to library when we need to use jQuery, or
even... Angular.

I have worked a lot on a new version of the Nested Pages Migrator last
year. The new version has never been released, because of blocking bugs on
the XWiki Platform's core-side. But I now have some experience with the
library I used: KnockoutJS.

It's a very simple library that does only one job and does it well: two-way
data-bindings. It plays well with RequireJS and it does not re-invent its
own component mechanism. The HTML code is not polluted by non-valid tags
(instead it uses "data-" properties and special HTML comments). The
documentation is extremely clear, and tutorials are great.

It's not the most popular library out there, but it's stable and still
alive. The trends are changing so quickly in the JS world (React was the
star not so long ago, but now it is hated because of a license change...),
but Knockout is still there. If the project dies, I think it will be easier
to replace it with an other simple library than a big "framework".

This is not a proposal or a vote, but only a feedback about this library.

You can test it there: http://knockoutjs.com/

Thanks,

-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

[xwiki-devs] [ANN] XWiki 10.0 released

[Guillaume Delhumeau]

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

This release introduces the new 10.x cycle, corresponding to the 2018 year.
It brings a lot of bug fixings to start the year on good basis. It is also
the first release which include the result of the teenager learning program
called Google Code-In
,
allowing young people to have a first experience on software's development
and sponsored by Google. You can even read a testimonial of one of the
students there

.

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.0/

Thanks for your support
-The XWiki dev team

[xwiki-devs] Drop XWiki 10.0 RC 1

[Guillaume Delhumeau]

Hi devs.

Last week, we failed to release XWiki 10.0 Release Candidate 1 on time. The
reason was the build was still not passing on Wednesday's evening. That is
why Vincent, Thomas and I decided that it does not worth to release it
knowing that we need to release XWiki 10.0 final today.

We had not followed the usual practice about sending an email to the
community first, and we want to apologize for that.

Thanks,

-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [Proposal] [CodeStyle] Committing XML wiki page date changes

[Guillaume Delhumeau]

+1 for both

2018-01-15 10:47 GMT+01:00 Vincent Massol <vinc...@massol.net>:

> Same as Thomas too.
>
> Thanks
> -Vincent
>
> > On 12 Jan 2018, at 13:50, Eduard Moraru <enygma2...@gmail.com> wrote:
> >
> > Hi devs,
> >
> > These are the current code style rules for committed XML wiki pages:
> > http://dev.xwiki.org/xwiki/bin/view/Community/XWikiXMLFilesCodeStyle
> >
> > = Proposal 1 =
> >
> > I was personally not aware we had documented these practices that we had
> > been applying since forever. It's good that we have them, but there seems
> > to be no mention about committing changes for the "creationDate", "date"
> > and "contentUpdateDate" fields.
> >
> > Part of the committers (including myself) are applying the old practice
> of
> > omitting changes to the date fields when committing a change to an XML
> wiki
> > page. However, since this practice is not written and agreed upon, its
> > usage is not consistent.
> >
> > So, the proposal is to include the rule of not committing changes on the
> > date fields of XML wiki pages.
> >
> > The rationale, AFAIR, includes:
> > * After an upgrade, users should not see "ghost" modifications in their
> > wiki (e.g. when sorting by date in the Page Index). This affects even
> more
> > manual imports with the "as backup" option enabled.
> > * On release, any date changes of a default translation XML page will
> > produce N other XML page changes, for each translation of the modified
> page
> > (due to the way l10n exports the translations based on the latest version
> > of the default language of that page).
> > * others?
> >
> > = Proposal 2 =
> >
> > Now, building on this, I would like to make a second proposal (which I
> > don't believe deserves a separate thread):
> > 1) Let's remove all date fields from committed XML wiki pages in our
> source
> > repository
> > 2) Let's make sure that the XAR import properly handles empty or missing
> > date fields and falls back on the current date
> > 3) Let's update the xar:format goal to remove the date fields
> > (configurable, since it could they might still be needed by some content
> > projects, etc.)
> > 4) Let's make the build fail (xar:verify) if the XML wiki pages contain
> > date fields (again configurable, as above)
> >
> > Note: All the above still depend on the first proposal of not committing
> > date changes to XML files (which will be simplified by point 3) above).
> >
> > The rationale for this is that we have always wanted to fix our "dates
> > problem", since after installation, the wiki is populated with pages
> > created in 2009, which is extremely odd to users that have just installed
> > XWiki. This second proposal sounds to me like a solution for that.
> >
> > WDYT?
> >
> > Thanks,
> > Eduard
>
>


-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [Proposal] Replace surefire plugin by failsafe plugin for functional tests

[Guillaume Delhumeau]

+1

Guillaume

2018-01-15 13:57 GMT+01:00 Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com>:

> +1
>
> Thanks,
> Marius
>
> On Mon, Jan 15, 2018 at 2:55 PM, Thomas Mortagne <
> thomas.morta...@xwiki.com>
> wrote:
>
> > This plugin is part of Maven project itself and state that "The
> > Failsafe Plugin is designed to run integration tests while the
> > Surefire Plugin is designed to run unit tests" so indeed it looks like
> > the right move :)
> >
> > +1
> >
> > On Mon, Jan 15, 2018 at 1:36 PM, Vincent Massol <vinc...@massol.net>
> > wrote:
> > > Hi devs,
> > >
> > > We’ve been using the surefire plugin from the beginning even for
> > functional tests.
> > >
> > > However it would be more correct to use the failsafe plugin for
> > functional tests since this allows to perform some actions if a test
> fails
> > (like stopping XWiki - Note that right now this is not affecting us since
> > we start/stop XWiki from Java so we’ve implemented this behavior
> ourselves).
> > >
> > > I need this for using the fabric8 docker plugin for ex so that if some
> > functional test fails the docker containers will be stopped.
> > >
> > > Ok with everyone?
> > >
> > > For reference: http://maven.apache.org/surefire/maven-failsafe-plugin/
> > >
> > > Thanks
> > > -Vincent
> > >
> >
> >
> >
> > --
> > Thomas Mortagne
> >
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [PROPOSAL] Implement decorators in xwiki-platform-container

[Guillaume Delhumeau]

Seems, nice. +1

2018-01-08 23:01 GMT+01:00 Clément Aubin <aubincl...@gmail.com>:

> On 01/08/2018 12:29 PM, Thomas Mortagne wrote:
> > Sounds good.
> >
> > +1 for RedirectResponse interface
>
> Nice; just created XWIKI-14948 to deal with this particular interface.
> We should be able to find more decorators in the near future.
>
> > On Mon, Jan 8, 2018 at 11:51 AM, Clément Aubin <aubincl...@gmail.com>
> wrote:
> >> Hi devs,
> >>
> >> This proposal is related to the following discussion on IRC :
> >> https://botbot.me/freenode/xwiki/2018-01-08/?msg=95495049=5
> >>
> >> Abstract: We currently have an abstraction of the notion of a
> >> "container" defined in xwiki-platform-container-api [1]. This
> >> abstraction is very basic, but allows XWiki to support two different
> >> types of containers : Servlet and Portlet, and maybe support other types
> >> in the future.
> >>
> >> Problem: As those abstractions are very basic, it's quite hard to use
> >> them without downcasting them. A common example is the following: if I
> >> want to send a redirection in a Response object [2], I will need either
> >> to forge my own output that returns the correct HTTP code, with the
> >> correct header, etc … or I can downcast the given Response to all of its
> >> possible implementations and, for each implementation, find the correct
> >> method to use for sending a redirect.
> >>
> >> In order to avoid such tricks in the future, we could implement
> >> decorators that will allow Request and Response implementations to
> >> handle certain actions. In my previous example, a Response implementing
> >> RedirectResponse would expose a method `#sendRedirect(String url)`. The
> >> advantage here is that we don't really need to know on which Response
> >> implementation we are working on.
> >>
> >> WDYT ?
> >>
> >> Thanks,
> >>
> >> Clément
> >>
> >> [1]
> >> https://github.com/xwiki/xwiki-platform/tree/master/
> xwiki-platform-core/xwiki-platform-containers/xwiki-
> platform-container-api/src/main/java/org/xwiki/container
> >>
> >> [2]
> >> https://github.com/xwiki/xwiki-platform/blob/master/
> xwiki-platform-core/xwiki-platform-containers/xwiki-
> platform-container-api/src/main/java/org/xwiki/container/Response.java
> >
> >
> >
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

[xwiki-devs] [Proposal] Use JSON in Wiki Components

[Guillaume Delhumeau]

Hi devs.

In XWiki, we have the ability to create wiki components. It means that each
extension can define a custom XClass which is used to create a component
when a corresponding XObject exists.

Sometimes, this XObject contains a textarea where the developer could write
velocity code. The velocity code is rendered, and the result is parsed in
order to complete other actions. For example, velocity can render a
boolean, or a list of documents, etc... The reason why Velocity is used is
because it does not require programming rights. On the other-side, it can
only return a string: the rendered content.

My use-case is to generate a specific list of users when an event is
triggered, to perform some actions with these users.

Currently, we have no recommended practice about this
"velocity-rendered-fields".

That's what I propose to always use JSON when velocity is used to render
data in a wiki component. The reason is that JSON is standard and easy to
parse.

Use case:
In the Event Stream module [1], the XClass
"XWiki.EventStream.Code.EventClass" is used to trigger custom events when
some event occurs.
Example: if a DocumentUpdatedEvent is triggered and that event contains an
XObject of type "Meeting", you can send a new "Meeting Created" event.
There is a "Validation Expression" field used to determine either or not
the custom event should be sent. Now I need to add an other field to
determine which user should receive the event notifications. For example:
if userA and userB have been invited to MeetingC, I need to send an event
"Meeting Created" only for user A and user B.

Here is my +1,

Thanks,

[1]
http://extensions.xwiki.org/xwiki/bin/view/Extension/Event%20Stream%20Module#HDefinecustomeventsinwikipages

--
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] Will XWiki Activity Stream deprecation affect activitystream_events table?

[Guillaume Delhumeau]

Hi.

Notifications will replace the Activity Stream (probably next year), but
only on the surface. Currently, all events are stored by Activity Stream,
and the Notifications Application loads the event from there.

Note that accessing the "activitystream_events" directly is not the
recommend practice as it may be replaced in the future. Instead, you should
use the more generic "Event Stream Module" :
http://extensions.xwiki.org/xwiki/bin/view/Extension/Event%20Stream%20Module
.

It provides an API to get the events. This is the API used by Notifications
to load the events.

I hope it helps,

2017-12-16 1:29 GMT+01:00 ktc <ktc-w...@amazon.com>:

> Hi devs,
>
> Right now we are building a feature based on XWiki Activity Stream and get
> data from activitystream_events table from database. We've heard that XWiki
> will replace Activity Stream with Notification. Does this mean
> activitystream_events table will be deprecated as well? If it is, do you
> have any suggestions for replacement like where we can get similar data
> from
> database and which application/extension with similar support features that
> we can rely on? Thanks a lot!
>
>
>
> --
> Sent from: http://xwiki.475771.n2.nabble.com/XWiki-Dev-f475773.html
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [Proposal] Login button for desktop

[Guillaume Delhumeau]

I've proposed
https://jira.xwiki.org/secure/attachment/34732/Proposition4.png, but Thomas
already said that it's clearly not obvious.

I've voluntary broken the consistency to highlight this action. It's the
most important one if you are not logged.

Thanks

2017-12-12 16:41 GMT+01:00 Vincent Massol <vinc...@massol.net>:

> I’d also prefer an icon and not text if we can find an icon that’s clear
> enough. The other icons don’t have text so it would be nicer to continue
> with this for consistency.
>
> Thanks
> -Vincent
>
> > On 12 Dec 2017, at 16:40, Vincent Massol <vinc...@massol.net> wrote:
> >
> > Hi,
> >
> > I have 2 points:
> >
> > 1) We need to have this configurable somehow but that should be easy
> since both buttons (inside and outside of the drawer are UIX). I still
> think there are use cases for having it inside the drawer.
> > 2) I’d put the Login on the right, just left of the Hamburger icon (ie
> right of the search).
> >
> > Thanks
> > -Vincent
> >
> >> On 12 Dec 2017, at 16:04, Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com> wrote:
> >>
> >> Hi Devs,
> >>
> >> Currently, the login button is inside the drawer menu, which is quite
> >> standard on mobile phones. However, on desktop, a lot of people are
> >> confused and cannot find how to login/register.
> >>
> >> I propose to add a login button in the top menu, like this:
> >> https://jira.xwiki.org/secure/attachment/34731/Proposition3.png
> >>
> >> Related JIRA: https://jira.xwiki.org/browse/XWIKI-14881#
> >>
> >> That could be nice to have it in addition to the current links, for
> 9.11.
> >>
> >> Note: we also need to put a "register" link in the login form, so that
> >> people can register from there without the need to also add a register
> >> button on the top menu (that would be too much IMO).
> >>
> >> WDYT?
> >>
> >> Thanks,
> >>
> >> --
> >> Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
> >> Research & Development Engineer at XWiki SAS
> >> Committer on the XWiki.org project
> >
>
>


-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] Notifications final steps

[Guillaume Delhumeau]

Hello

2017-12-06 16:49 GMT+01:00 Ecaterina Moraru (Valica) <vali...@gmail.com>:

> Congrats on the progress.
>
> Regarding unbundling Watchlist, we usually wait like 1 cycle before doing
> that. I think we should disable it somehow, but unbundling it just from
> 9.11 to 9.12, which is 1 month, sounds a bit short.
>

I don't see the problem about unbundling it. All you have to do, to get it
back, is to install the Watchlist Application via Extension Manager, which
is very simple. In comparison, modifying a property in xwiki.properties
requires to have access to the server. You can even install the application
with the option "install on farm", so you have it everywhere. But we need
to check if the java listeners would not be triggered to much if they are
installed on several wikis without the "install on farm" option.

I'm not proposing to move the Watchlist to Contrib, just not to have it by
default on XWiki Standard anymore.

Maybe I don't see the whole picture, please comment :)

Thanks,



>
> Thanks,
> Caty
>
> On Wed, Dec 6, 2017 at 4:40 PM, Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com> wrote:
>
> > Hello devs community,
> >
> > As you know, my main focus this year was on the notifications. My
> objective
> > has been to replace the Watchlist with the notification emails. Today, we
> > are almost there.
> >
> > The 2 remaining issues are:
> > * https://jira.xwiki.org/browse/XWIKI-14844 (Live emails notifications
> > should be grouped by XWiki pages)
> > and
> > * https://jira.xwiki.org/browse/XWIKI-14891 (Introduce a notifications
> > macro to replace the Watchlist macro)
> >
> > I have updated the design page about this replacement:
> > http://design.xwiki.org/xwiki/bin/view/Proposal/
> > ReplacetheWatchlistbyNotifications
> > .
> >
> > I am confident that these issues will be implemented for 9.12.
> >
> > Proposition:
> > * we encourage users to enable the notifications on 9.11 and to test it
> > * for 9.12, we enable all notification features by default
> > * for 9.12, we don't bundle the Watchlist in XWiki Standard anymore.
> >
> > What do you think ?
> >
> > Thanks,
> >
> > --
> > Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
> > Research & Development Engineer at XWiki SAS
> > Committer on the XWiki.org project
> >
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

[xwiki-devs] Notifications final steps

[Guillaume Delhumeau]

Hello devs community,

As you know, my main focus this year was on the notifications. My objective
has been to replace the Watchlist with the notification emails. Today, we
are almost there.

The 2 remaining issues are:
* https://jira.xwiki.org/browse/XWIKI-14844 (Live emails notifications
should be grouped by XWiki pages)
and
* https://jira.xwiki.org/browse/XWIKI-14891 (Introduce a notifications
macro to replace the Watchlist macro)

I have updated the design page about this replacement:
http://design.xwiki.org/xwiki/bin/view/Proposal/ReplacetheWatchlistbyNotifications
.

I am confident that these issues will be implemented for 9.12.

Proposition:
* we encourage users to enable the notifications on 9.11 and to test it
* for 9.12, we enable all notification features by default
* for 9.12, we don't bundle the Watchlist in XWiki Standard anymore.

What do you think ?

Thanks,

-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [Proposal] Agree on en_US vs en_GB

[Guillaume Delhumeau]

+1 for en_US

2017-12-04 14:58 GMT+01:00 Thomas Mortagne <thomas.morta...@xwiki.com>:

> +1 for en_US
>
> On Mon, Dec 4, 2017 at 2:50 PM, Caleb James DeLisle <c...@cjdns.fr> wrote:
> > +1 for en_US
> >
> > 
> >
> > Thanks,
> > Caleb
> >
> >
> > On 04/12/17 14:36, Manuel Smeria wrote:
> >> Hello,
> >>
> >> +1 for en_US
> >>
> >> Thanks,
> >> Manuel
> >>
> >> On Mon, Dec 4, 2017 at 3:18 PM, Eduard Moraru <enygma2...@gmail.com>
> wrote:
> >>
> >>> +1 for en_US
> >>>
> >>> Thanks,
> >>> Eduard
> >>>
> >>> On Mon, Dec 4, 2017 at 2:42 PM, Alex Cotiugă <
> alexandru.coti...@xwiki.com>
> >>> wrote:
> >>>
> >>>> +1 for en_US
> >>>>
> >>>> Thanks,
> >>>> Alex
> >>>>
> >>>> On Mon, Dec 4, 2017 at 2:38 PM, Marius Dumitru Florea <
> >>>> mariusdumitru.flo...@xwiki.com> wrote:
> >>>>
> >>>>> +1 for en_US
> >>>>>
> >>>>> On Mon, Dec 4, 2017 at 2:35 PM, Vincent Massol <vinc...@massol.net>
> >>>> wrote:
> >>>>>
> >>>>>> Hi devs,
> >>>>>>
> >>>>>> By default the xwiki core committers maintain an “en” version of all
> >>>>>> translations and the other languages are left to the community to
> >>>>> maintain
> >>>>>> on l10n.xwiki.org
> >>>>>>
> >>>>>> This mail is about deciding if our “en” version is “en_US” or
> >>> “en_GB”.
> >>>>>>
> >>>>>> I propose that we standardize on “en_US”. for example
> >>>>> ApplicationResources.properties
> >>>>>> would correspond to en_US.
> >>>>>>
> >>>>>> I also propose that we add en_GB on l10n so that the community could
> >>>>>> maintain a UK version if they want (it would fall back to en_US when
> >>>>> there
> >>>>>> are no translations, which is a good thing).
> >>>>>>
> >>>>>> WDYT?
> >>>>>>
> >>>>>> Thanks
> >>>>>> -Vincent
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>
>
> --
> Thomas Mortagne
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [Proposal][UX] Notifications Improvements 9.8+

[Guillaume Delhumeau]

; I would not drop it but it’s already contained in the text on the
> right
> >> so
> >>>> that’s duplication.
> >>>>
> >>>> I’d use the avatar + the app and leave the event icon on the right or
> >>>> simply drop it in favor of the text (either one).
> >>>>
> >>>>> The grouping is done by page and by event.
> >>>>> You want to know if someone deleted a new entry or just edited in a
> >> rapid
> >>>>> way, without the need to read the text.
> >>>>
> >>>> I’d prefer to see who did something and what they modified. That’s
> >> really
> >>>> how I use XWiki’s AS the most personally.
> >>>>
> >>>> If the text is not visual enough the event icon is ok too but I
> wouldn’t
> >>>> put it on the left.
> >>>>
> >>>> In any case, you need consistency and all entries need to look the
> same.
> >>>> We must not have special cases as it makes it very hard to understand.
> >>>>
> >>>
> >>> For me it was confusing seeing "Pages", since in XWiki everything is a
> >> page
> >>> and I don't have any application called Pages. I saw the addition of
> >>> "Pages" as redundant.
> >>>
> >>>
> >>>>
> >>>>>
> >>>>>> In your variations I don’t see one where the app icon is on the
> left.
> >>>>>>
> >>>>>
> >>>>> I have put all the icons on the left in order to be easier to scan
> for
> >>>> them
> >>>>> in collapsed and expanded form. Having the icons on the right made
> the
> >>>>> layout very centered-heavy + you didn't had the extremities in order
> to
> >>>>> scan for them.
> >>>>>
> >>>>> So Guillaume and Clement like the event-focused view.
> >>>>>
> >>>>> I don't particularly like the big event icons. I find them more cold
> >> and
> >>>>> less personal. So I prefer the users-centered version.
> >>>>
> >>>> Same here for the same reason, but… (see below)
> >>>>
> >>>>> I like:
> >>>>> http://design.xwiki.org/xwiki/bin/download/Proposal/
> >>>> NotificationsImprovements9xTypes/userCentered_smallAvatars_
> reverse.png
> >>>>
> >>>> I don’t like the generic group image, it breaks the nice UI with
> >> avatars.
> >>>> We could maybe resize the avatars and display up to 4 and if beyond
> then
> >>>> display some continuations symbol.
> >>>>
> >>>
> >>> Not really sure how to display 4 avatars + in a nice way, while still
> >> being
> >>> the main focus.
> >>
> >> There’s another problem too actually. Not all events are related to
> >> people. For example the “A new version of XWiki is available” event
> would
> >> not have an avatar. However we could decide to use an “X” icon,
> >> representing the xwiki.org entity/avatar.
> >>
> >> What I wouldn’t like is some generic image such as a bland group image.
> I
> >> find that this breaks the concept of showing avatars.
> >>
> >> Thanks
> >> -Vincent
> >>
> >>>
> >>>>> Now I haven't created versions for all the combinations, but we
> should
> >>>>> decide if:
> >>>>> - we want user focused vs. event focused layout
> >>>>> - expanded version should have users or events on the left;
> >>>>> - the summary should contain avatars or not for the users (important
> >> when
> >>>>> there is a single user that did the event);
> >>>>> - if / when we combine the users (when we have more than 2/3 users;
> >>>> always;
> >>>>>
> >>>>> I am lacking some information in order to get some statistical
> >> decisions.
> >>>>> For example, in practice:
> >>>>> - we have more individual events or more events done by multiple
> >> people?
> >>>>> - how common is to group also events? the example with blog published
> >>>> that
> >>>>> also has the create. Do we really need to display them? Also when
> >>>> creating
> >>>>> an user profi

Re: [xwiki-devs] [Proposal][UX] Notifications Improvements 9.8+

[Guillaume Delhumeau]

Hello.

My personal favorite is
http://design.xwiki.org/xwiki/bin/download/Proposal/NotificationsImprovements9xTypes/eventCentered_smallAvatars.png

With this "details" section:
http://design.xwiki.org/xwiki/bin/download/Proposal/NotificationsImprovements9xTypes/userCentered_uncropped.png

Could we consider having a little extract of the document's content in the
notification. For a blog post, I could imagine a little extract, such as:

*This release focused on fixing bugs on Notifications, Office Viewer and
> Solr Search. The server is...*


(extract from http://www.xwiki.org/xwiki/bin/view/Blog/XWiki%2099%20Released
)

Thanks,

Guillaume


2017-10-27 20:04 GMT+02:00 Clément Aubin <aubincl...@gmail.com>:

> Hello !
>
> On 10/27/2017 05:31 PM, Ecaterina Moraru (Valica) wrote:
> > Hi,
> >
> > So these are some more iterations for the notifications layout
> > http://design.xwiki.org/xwiki/bin/view/Proposal/
> NotificationsImprovements9xTypes
> >
> > I've played with User centered vs. Event centered and variants for
> > displaying the avatars, user names and event names.
> >
> > Let me know what version you prefer. Also you can fork the prototypes if
> > you want to make some small changes.
>
> I really like the Event-focused "Description with small avatars" options:
>
> * The notification title does not mentions the full name of the users
> involved in this notification (if multiple) ; this reduces the size of
> the title. Also, the users involved in the notifications are still
> available through their icons.
> * The main focus isn't on the users involved in the notification, but on
> its content.
>
> Hope it helps,
> Thanks,
>
> Clément
>
> > Thanks,
> > Caty
> >
> > On Tue, Oct 24, 2017 at 12:47 PM, Vincent Massol <vinc...@massol.net>
> wrote:
> >
> >>
> >>> On 24 Oct 2017, at 11:24, Guillaume Delhumeau <
> >> guillaume.delhum...@xwiki.com> wrote:
> >>>
> >>> Hello
> >>>
> >>> 2017-10-24 11:12 GMT+02:00 Vincent Massol <vinc...@massol.net>:
> >>>
> >>>> Hi Guillaume,
> >>>>
> >>>>> On 24 Oct 2017, at 10:58, Guillaume Delhumeau <
> >>>> guillaume.delhum...@xwiki.com> wrote:
> >>>>>
> >>>>> Any news on this? I'd like to implement this quickly because 9.10 is
> >>>> coming
> >>>>> :)
> >>>>
> >>>> This the current status:
> >>>> * Caty proposed some improved layout for displaying notifications
> >>>> * I commented about the need to display event + type, and about the
> need
> >>>> to have a link to see the diff. I also mentioned that we need to work
> on
> >>>> the mail template display
> >>>> * Caty replied and updated her proposal to take into account those
> >>>> comments.
> >>>> * I kind of like Caty’s proposal focused on the user. We want to favor
> >>>> contributions and I think it helps. It also makes the UI more
> appealing
> >>>> visually.
> >>>> * You mentioned that you’d prefer a proposal more focused on the event
> >>>> rather than the user
> >>>> * Thomas agrees with you
> >>>> * Edy mentioned some extra points
> >>>>
> >>>
> >>> I have also mentioned that the diff we propose is too technical for
> many
> >>> users.
> >>
> >> Yes and we have 4 solutions:
> >>
> >> * Solution 1: make it simpler to understand for everyone
> >> * Solution 2: have a wiki admin UI level option to select whether to
> >> include diff or not in the default template + user-level profile UI
> option
> >> (ie. per user)
> >> * Solution 3: have a singe button in the mail, that, when clicked,
> >> displays the diff (which is hidden by default)
> >> * Solution 4: implement 2 mail templates (one for simple users and one
> for
> >> advanced users) and let the users choose in their profile which one they
> >> want to receive + have a wiki admin UI level option to decide which is
> the
> >> default when not overridden by the user.
> >>
> >> Thanks
> >> -Vincent
> >>
> >>>
> >>>> So I guess we need to decide about whether we show the avatar as in
> >> Caty’s
> >>>> proposal or not, right? Is that what you’re asking about Guillaume?
> >>>>
> >>>> On my side, I don’t see the issue in displaying 

Re: [xwiki-devs] [Proposal][UX] Notifications Improvements 9.8+

[Guillaume Delhumeau]

2017-10-24 11:16 GMT+02:00 Ecaterina Moraru (Valica) <vali...@gmail.com>:

> I don't have any new proposal right now. I could do another iteration
> starting from tomorrow.
>

If you need help, please ask me.

I'll switch to an other topic until I can implement your ideas.

Thanks,


>
> Thanks,
> Caty
>
> On Tue, Oct 24, 2017 at 12:12 PM, Vincent Massol <vinc...@massol.net>
> wrote:
>
> > Hi Guillaume,
> >
> > > On 24 Oct 2017, at 10:58, Guillaume Delhumeau <
> > guillaume.delhum...@xwiki.com> wrote:
> > >
> > > Any news on this? I'd like to implement this quickly because 9.10 is
> > coming
> > > :)
> >
> > This the current status:
> > * Caty proposed some improved layout for displaying notifications
> > * I commented about the need to display event + type, and about the need
> > to have a link to see the diff. I also mentioned that we need to work on
> > the mail template display
> > * Caty replied and updated her proposal to take into account those
> > comments.
> > * I kind of like Caty’s proposal focused on the user. We want to favor
> > contributions and I think it helps. It also makes the UI more appealing
> > visually.
> > * You mentioned that you’d prefer a proposal more focused on the event
> > rather than the user
> > * Thomas agrees with you
> > * Edy mentioned some extra points
> >
> > So I guess we need to decide about whether we show the avatar as in
> Caty’s
> > proposal or not, right? Is that what you’re asking about Guillaume?
> >
> > On my side, I don’t see the issue in displaying the user avatar large vs
> > small. The events are still ordered by page events.
> >
> > Thanks
> > -Vincent
> >
> > >
> > > 2017-10-23 13:19 GMT+02:00 Guillaume Delhumeau <
> > > guillaume.delhum...@xwiki.com>:
> > >
> > >> Note that you have a mail template for the notifications too. It's
> > >> https://github.com/xwiki/xwiki-platform/blob/
> > >> 83b76ed4c26954aa2755bbdce23b32c41725ac06/xwiki-platform-
> > >> core/xwiki-platform-notifications/xwiki-platform-
> > >> notifications-ui/src/main/resources/XWiki/Notifications/
> > >> MailTemplate.xml#L23 but it's not documented yet.
> > >>
> > >> This mail template allows you to customize the header and the footer
> of
> > >> the email, but not the actual content.
> > >>
> > >> To be precise, each *event type* can have its own template or failback
> > to
> > >> the default one (https://github.com/xwiki/xwiki-platform/blob/
> > >> acdf68f4c0d20a9b44ea48eec4df808e22c54548/xwiki-platform-
> > >> core/xwiki-platform-web/src/main/webapp/templates/
> > >> notification/email/default.html.vm)
> > >>
> > >> So it's a template *per event type* and it's not linked to any user
> > >> choice. But we could add some options in the default template for
> > example.
> > >>
> > >> 2017-10-17 16:23 GMT+02:00 Vincent Massol <vinc...@massol.net>:
> > >>
> > >>> Hi Guillaume,
> > >>>
> > >>>> On 17 Oct 2017, at 07:16, Guillaume Delhumeau <
> > >>> guillaume.delhum...@xwiki.com> wrote:
> > >>>>
> > >>>> Some ideas.
> > >>>>
> > >>>> I have feedback about the fact the diff is way too technical for
> > users.
> > >>>>
> > >>>> Example: "What does it means???" https://img15.hostingpics.net/
> > >>>> pics/670307example1.png
> > >>>>
> > >>>> So we could hide this in a "technical details" link.
> > >>>
> > >>> That’s one option but there’s another which is to provide the ability
> > to
> > >>> choose which mail template to use in the Admin and provide several
> > >>> templates for different needs.
> > >>>
> > >>> For example for the xwiki.org watchlist we absolutely need to be
> able
> > to
> > >>> see the diffs without clicking a “technical details” link for each
> > >>> notification. It could be ok if there’s a single “technical details”
> > link
> > >>> for ALL notifications that shows all diffs at once.
> > >>>
> > >>> Thanks
> > >>> -Vincent
> > >>>
> > >>>>
> > >>>> The "details" link could b

Re: [xwiki-devs] [Proposal][UX] Notifications Improvements 9.8+

[Guillaume Delhumeau]

Hello

2017-10-24 11:12 GMT+02:00 Vincent Massol <vinc...@massol.net>:

> Hi Guillaume,
>
> > On 24 Oct 2017, at 10:58, Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com> wrote:
> >
> > Any news on this? I'd like to implement this quickly because 9.10 is
> coming
> > :)
>
> This the current status:
> * Caty proposed some improved layout for displaying notifications
> * I commented about the need to display event + type, and about the need
> to have a link to see the diff. I also mentioned that we need to work on
> the mail template display
> * Caty replied and updated her proposal to take into account those
> comments.
> * I kind of like Caty’s proposal focused on the user. We want to favor
> contributions and I think it helps. It also makes the UI more appealing
> visually.
> * You mentioned that you’d prefer a proposal more focused on the event
> rather than the user
> * Thomas agrees with you
> * Edy mentioned some extra points
>

I have also mentioned that the diff we propose is too technical for many
users.


>
> So I guess we need to decide about whether we show the avatar as in Caty’s
> proposal or not, right? Is that what you’re asking about Guillaume?
>
> On my side, I don’t see the issue in displaying the user avatar large vs
> small. The events are still ordered by page events.
>
> Thanks
> -Vincent
>

Thanks


>
> >
> > 2017-10-23 13:19 GMT+02:00 Guillaume Delhumeau <
> > guillaume.delhum...@xwiki.com>:
> >
> >> Note that you have a mail template for the notifications too. It's
> >> https://github.com/xwiki/xwiki-platform/blob/
> >> 83b76ed4c26954aa2755bbdce23b32c41725ac06/xwiki-platform-
> >> core/xwiki-platform-notifications/xwiki-platform-
> >> notifications-ui/src/main/resources/XWiki/Notifications/
> >> MailTemplate.xml#L23 but it's not documented yet.
> >>
> >> This mail template allows you to customize the header and the footer of
> >> the email, but not the actual content.
> >>
> >> To be precise, each *event type* can have its own template or failback
> to
> >> the default one (https://github.com/xwiki/xwiki-platform/blob/
> >> acdf68f4c0d20a9b44ea48eec4df808e22c54548/xwiki-platform-
> >> core/xwiki-platform-web/src/main/webapp/templates/
> >> notification/email/default.html.vm)
> >>
> >> So it's a template *per event type* and it's not linked to any user
> >> choice. But we could add some options in the default template for
> example.
> >>
> >> 2017-10-17 16:23 GMT+02:00 Vincent Massol <vinc...@massol.net>:
> >>
> >>> Hi Guillaume,
> >>>
> >>>> On 17 Oct 2017, at 07:16, Guillaume Delhumeau <
> >>> guillaume.delhum...@xwiki.com> wrote:
> >>>>
> >>>> Some ideas.
> >>>>
> >>>> I have feedback about the fact the diff is way too technical for
> users.
> >>>>
> >>>> Example: "What does it means???" https://img15.hostingpics.net/
> >>>> pics/670307example1.png
> >>>>
> >>>> So we could hide this in a "technical details" link.
> >>>
> >>> That’s one option but there’s another which is to provide the ability
> to
> >>> choose which mail template to use in the Admin and provide several
> >>> templates for different needs.
> >>>
> >>> For example for the xwiki.org watchlist we absolutely need to be able
> to
> >>> see the diffs without clicking a “technical details” link for each
> >>> notification. It could be ok if there’s a single “technical details”
> link
> >>> for ALL notifications that shows all diffs at once.
> >>>
> >>> Thanks
> >>> -Vincent
> >>>
> >>>>
> >>>> The "details" link could be replaced by a "more" link, with a very
> >>>> simplified diff (the complete diff would go the the technical details
> >>> view).
> >>>>
> >>>> In the body of the event, in addition with the title of the document,
> we
> >>>> could add some extracts of the diff.
> >>>>
> >>>> Example taken on gmail:
> >>>> https://img15.hostingpics.net/pics/763456example2.png
> >>>>
> >>>> I hope it helps,
> >>>>
> >>>> Thanks
> >>>>
> >>>>
> >>>>
> >>>> 2017-10-12 15:38 GMT+02:00 Vincent Massol <vin

Re: [xwiki-devs] [Proposal][UX] Notifications Improvements 9.8+

[Guillaume Delhumeau]

Any news on this? I'd like to implement this quickly because 9.10 is coming
:)

2017-10-23 13:19 GMT+02:00 Guillaume Delhumeau <
guillaume.delhum...@xwiki.com>:

> Note that you have a mail template for the notifications too. It's
> https://github.com/xwiki/xwiki-platform/blob/
> 83b76ed4c26954aa2755bbdce23b32c41725ac06/xwiki-platform-
> core/xwiki-platform-notifications/xwiki-platform-
> notifications-ui/src/main/resources/XWiki/Notifications/
> MailTemplate.xml#L23 but it's not documented yet.
>
> This mail template allows you to customize the header and the footer of
> the email, but not the actual content.
>
> To be precise, each *event type* can have its own template or failback to
> the default one (https://github.com/xwiki/xwiki-platform/blob/
> acdf68f4c0d20a9b44ea48eec4df808e22c54548/xwiki-platform-
> core/xwiki-platform-web/src/main/webapp/templates/
> notification/email/default.html.vm)
>
> So it's a template *per event type* and it's not linked to any user
> choice. But we could add some options in the default template for example.
>
> 2017-10-17 16:23 GMT+02:00 Vincent Massol <vinc...@massol.net>:
>
>> Hi Guillaume,
>>
>> > On 17 Oct 2017, at 07:16, Guillaume Delhumeau <
>> guillaume.delhum...@xwiki.com> wrote:
>> >
>> > Some ideas.
>> >
>> > I have feedback about the fact the diff is way too technical for users.
>> >
>> > Example: "What does it means???" https://img15.hostingpics.net/
>> > pics/670307example1.png
>> >
>> > So we could hide this in a "technical details" link.
>>
>> That’s one option but there’s another which is to provide the ability to
>> choose which mail template to use in the Admin and provide several
>> templates for different needs.
>>
>> For example for the xwiki.org watchlist we absolutely need to be able to
>> see the diffs without clicking a “technical details” link for each
>> notification. It could be ok if there’s a single “technical details” link
>> for ALL notifications that shows all diffs at once.
>>
>> Thanks
>> -Vincent
>>
>> >
>> > The "details" link could be replaced by a "more" link, with a very
>> > simplified diff (the complete diff would go the the technical details
>> view).
>> >
>> > In the body of the event, in addition with the title of the document, we
>> > could add some extracts of the diff.
>> >
>> > Example taken on gmail:
>> > https://img15.hostingpics.net/pics/763456example2.png
>> >
>> > I hope it helps,
>> >
>> > Thanks
>> >
>> >
>> >
>> > 2017-10-12 15:38 GMT+02:00 Vincent Massol <vinc...@massol.net>:
>> >
>> >> Looks nice. Does it work in all mail clients that support HTML?
>> >>
>> >> I'd like an option to show the details for all events as otherwise it's
>> >> too painful to have to open all one by one (for the use case when you
>> want
>> >> to check everything).
>> >>
>> >> Same as Guillaume: not all events are page-related events. So we need
>> to
>> >> handle those too.
>> >>
>> >> Thanks!
>> >> -Vincent
>> >>
>> >>> On 12 Oct 2017, at 15:03, Guillaume Delhumeau <
>> >> guillaume.delhum...@xwiki.com> wrote:
>> >>>
>> >>> First of all, it looks very nice.
>> >>>
>> >>> Now, you said the events are displayed like in the notifications, but
>> in
>> >>> the notifications they are ordered by dates, not by pages. Does your
>> >>> proposal imply to change the ordering? What about events that do not
>> >>> concern any page (like: "a new wiki has been created" or "a new XWiki
>> >>> version is available")? We don't have such events for now but we plan
>> to
>> >>> have some soon. We could display them last for example.
>> >>>
>> >>> Nice CSS expand!
>> >>>
>> >>> Thanks you,
>> >>>
>> >>> 2017-10-12 14:47 GMT+02:00 Ecaterina Moraru (Valica) <
>> vali...@gmail.com
>> >>> :
>> >>>
>> >>>> This is a proposal for the Notifications mail:
>> >>>> http://design.xwiki.org/xwiki/bin/view/Proposal/
>> >>>> NotificationsImprovements9xEmail
>> >>>>
>> >>>> I've continued with the 'user' av

Re: [xwiki-devs] [Proposal][UX] Notifications Improvements 9.8+

[Guillaume Delhumeau]

Note that you have a mail template for the notifications too. It's
https://github.com/xwiki/xwiki-platform/blob/83b76ed4c26954aa2755bbdce23b32c41725ac06/xwiki-platform-core/xwiki-platform-notifications/xwiki-platform-notifications-ui/src/main/resources/XWiki/Notifications/MailTemplate.xml#L23
but it's not documented yet.

This mail template allows you to customize the header and the footer of the
email, but not the actual content.

To be precise, each *event type* can have its own template or failback to
the default one (
https://github.com/xwiki/xwiki-platform/blob/acdf68f4c0d20a9b44ea48eec4df808e22c54548/xwiki-platform-core/xwiki-platform-web/src/main/webapp/templates/notification/email/default.html.vm
)

So it's a template *per event type* and it's not linked to any user choice.
But we could add some options in the default template for example.

2017-10-17 16:23 GMT+02:00 Vincent Massol <vinc...@massol.net>:

> Hi Guillaume,
>
> > On 17 Oct 2017, at 07:16, Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com> wrote:
> >
> > Some ideas.
> >
> > I have feedback about the fact the diff is way too technical for users.
> >
> > Example: "What does it means???" https://img15.hostingpics.net/
> > pics/670307example1.png
> >
> > So we could hide this in a "technical details" link.
>
> That’s one option but there’s another which is to provide the ability to
> choose which mail template to use in the Admin and provide several
> templates for different needs.
>
> For example for the xwiki.org watchlist we absolutely need to be able to
> see the diffs without clicking a “technical details” link for each
> notification. It could be ok if there’s a single “technical details” link
> for ALL notifications that shows all diffs at once.
>
> Thanks
> -Vincent
>
> >
> > The "details" link could be replaced by a "more" link, with a very
> > simplified diff (the complete diff would go the the technical details
> view).
> >
> > In the body of the event, in addition with the title of the document, we
> > could add some extracts of the diff.
> >
> > Example taken on gmail:
> > https://img15.hostingpics.net/pics/763456example2.png
> >
> > I hope it helps,
> >
> > Thanks
> >
> >
> >
> > 2017-10-12 15:38 GMT+02:00 Vincent Massol <vinc...@massol.net>:
> >
> >> Looks nice. Does it work in all mail clients that support HTML?
> >>
> >> I'd like an option to show the details for all events as otherwise it's
> >> too painful to have to open all one by one (for the use case when you
> want
> >> to check everything).
> >>
> >> Same as Guillaume: not all events are page-related events. So we need to
> >> handle those too.
> >>
> >> Thanks!
> >> -Vincent
> >>
> >>> On 12 Oct 2017, at 15:03, Guillaume Delhumeau <
> >> guillaume.delhum...@xwiki.com> wrote:
> >>>
> >>> First of all, it looks very nice.
> >>>
> >>> Now, you said the events are displayed like in the notifications, but
> in
> >>> the notifications they are ordered by dates, not by pages. Does your
> >>> proposal imply to change the ordering? What about events that do not
> >>> concern any page (like: "a new wiki has been created" or "a new XWiki
> >>> version is available")? We don't have such events for now but we plan
> to
> >>> have some soon. We could display them last for example.
> >>>
> >>> Nice CSS expand!
> >>>
> >>> Thanks you,
> >>>
> >>> 2017-10-12 14:47 GMT+02:00 Ecaterina Moraru (Valica) <
> vali...@gmail.com
> >>> :
> >>>
> >>>> This is a proposal for the Notifications mail:
> >>>> http://design.xwiki.org/xwiki/bin/view/Proposal/
> >>>> NotificationsImprovements9xEmail
> >>>>
> >>>> I've continued with the 'user' avatar focused proposal, since I've
> >>>> currently focused on the email template. If we drop the user avatar
> >> (since
> >>>> we group multiple users) then we can have the event/app icon instead
> of
> >> the
> >>>> avatar.
> >>>>
> >>>> What I want to have feedback on is the email layout, functionality
> (tree
> >>>> navigation, details expanding) and styling.
> >>>>
> >>>> You can play with the Prototype
> >>>> http://jsfiddle.net/risherry/cj25759w/embedded/#Result
>

Re: [xwiki-devs] [Proposal][UX] Notifications Improvements 9.8+

[Guillaume Delhumeau]

Some ideas.

I have feedback about the fact the diff is way too technical for users.

Example: "What does it means???" https://img15.hostingpics.net/
pics/670307example1.png

So we could hide this in a "technical details" link.

The "details" link could be replaced by a "more" link, with a very
simplified diff (the complete diff would go the the technical details view).

In the body of the event, in addition with the title of the document, we
could add some extracts of the diff.

Example taken on gmail:
https://img15.hostingpics.net/pics/763456example2.png

I hope it helps,

Thanks



2017-10-12 15:38 GMT+02:00 Vincent Massol <vinc...@massol.net>:

> Looks nice. Does it work in all mail clients that support HTML?
>
> I'd like an option to show the details for all events as otherwise it's
> too painful to have to open all one by one (for the use case when you want
> to check everything).
>
> Same as Guillaume: not all events are page-related events. So we need to
> handle those too.
>
> Thanks!
> -Vincent
>
> > On 12 Oct 2017, at 15:03, Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com> wrote:
> >
> > First of all, it looks very nice.
> >
> > Now, you said the events are displayed like in the notifications, but in
> > the notifications they are ordered by dates, not by pages. Does your
> > proposal imply to change the ordering? What about events that do not
> > concern any page (like: "a new wiki has been created" or "a new XWiki
> > version is available")? We don't have such events for now but we plan to
> > have some soon. We could display them last for example.
> >
> > Nice CSS expand!
> >
> > Thanks you,
> >
> > 2017-10-12 14:47 GMT+02:00 Ecaterina Moraru (Valica) <vali...@gmail.com
> >:
> >
> >> This is a proposal for the Notifications mail:
> >> http://design.xwiki.org/xwiki/bin/view/Proposal/
> >> NotificationsImprovements9xEmail
> >>
> >> I've continued with the 'user' avatar focused proposal, since I've
> >> currently focused on the email template. If we drop the user avatar
> (since
> >> we group multiple users) then we can have the event/app icon instead of
> the
> >> avatar.
> >>
> >> What I want to have feedback on is the email layout, functionality (tree
> >> navigation, details expanding) and styling.
> >>
> >> You can play with the Prototype
> >> http://jsfiddle.net/risherry/cj25759w/embedded/#Result
> >>
> >> If we were to translate to the mail template, there are still some
> things
> >> to be tested (like translating the CSS selectors into inline, decide
> what
> >> email clients we support, etc.)
> >>
> >> Let me know,
> >> Caty
> >>
> >>
> >> On Tue, Oct 10, 2017 at 5:51 PM, Guillaume Delhumeau <
> >> guillaume.delhum...@xwiki.com> wrote:
> >>
> >>> 2017-10-03 17:32 GMT+02:00 Ecaterina Moraru (Valica) <
> vali...@gmail.com
> >>> :
> >>>
> >>>> On Tue, Oct 3, 2017 at 10:50 AM, Guillaume Delhumeau <
> >>>> guillaume.delhum...@xwiki.com> wrote:
> >>>>
> >>>>> 2017-10-02 18:09 GMT+02:00 Vincent Massol <vinc...@massol.net>:
> >>>>>
> >>>>>>
> >>>>>>> On 2 Oct 2017, at 18:08, Vincent Massol <vinc...@massol.net>
> >>> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>> On 2 Oct 2017, at 18:05, Vincent Massol <vinc...@massol.net>
> >>> wrote:
> >>>>>>>>
> >>>>>>>> Another feedback/questions:
> >>>>>>>>
> >>>>>>>> * Is the avatar icon clickable and leading to the user profile?
> >>>>>>>> * We need a way to link directly to the diff, at least for page
> >>>> events
> >>>>>> so that the user can see what was modified (as we have currently in
> >>> the
> >>>>> AS)
> >>>>>>>
> >>>>>>> * Maybe “2 hours ago” is not precise enough. In your example I
> >> see
> >>> I
> >>>>>> created and modified the Roadmap page but they both say “2 hours
> >>> ago”.
> >>>>>> Shouldn’t I be able to see how far away both events were done?
> >>>>>>
> >>>>>> My understanding is that events are grouped by app+type 

Re: [xwiki-devs] [Proposal][UX] Notifications Improvements 9.8+

[Guillaume Delhumeau]

First of all, it looks very nice.

Now, you said the events are displayed like in the notifications, but in
the notifications they are ordered by dates, not by pages. Does your
proposal imply to change the ordering? What about events that do not
concern any page (like: "a new wiki has been created" or "a new XWiki
version is available")? We don't have such events for now but we plan to
have some soon. We could display them last for example.

Nice CSS expand!

Thanks you,

2017-10-12 14:47 GMT+02:00 Ecaterina Moraru (Valica) <vali...@gmail.com>:

> This is a proposal for the Notifications mail:
> http://design.xwiki.org/xwiki/bin/view/Proposal/
> NotificationsImprovements9xEmail
>
> I've continued with the 'user' avatar focused proposal, since I've
> currently focused on the email template. If we drop the user avatar (since
> we group multiple users) then we can have the event/app icon instead of the
> avatar.
>
> What I want to have feedback on is the email layout, functionality (tree
> navigation, details expanding) and styling.
>
> You can play with the Prototype
> http://jsfiddle.net/risherry/cj25759w/embedded/#Result
>
> If we were to translate to the mail template, there are still some things
> to be tested (like translating the CSS selectors into inline, decide what
> email clients we support, etc.)
>
> Let me know,
> Caty
>
>
> On Tue, Oct 10, 2017 at 5:51 PM, Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com> wrote:
>
> > 2017-10-03 17:32 GMT+02:00 Ecaterina Moraru (Valica) <vali...@gmail.com
> >:
> >
> > > On Tue, Oct 3, 2017 at 10:50 AM, Guillaume Delhumeau <
> > > guillaume.delhum...@xwiki.com> wrote:
> > >
> > > > 2017-10-02 18:09 GMT+02:00 Vincent Massol <vinc...@massol.net>:
> > > >
> > > > >
> > > > > > On 2 Oct 2017, at 18:08, Vincent Massol <vinc...@massol.net>
> > wrote:
> > > > > >
> > > > > >
> > > > > >> On 2 Oct 2017, at 18:05, Vincent Massol <vinc...@massol.net>
> > wrote:
> > > > > >>
> > > > > >> Another feedback/questions:
> > > > > >>
> > > > > >> * Is the avatar icon clickable and leading to the user profile?
> > > > > >> * We need a way to link directly to the diff, at least for page
> > > events
> > > > > so that the user can see what was modified (as we have currently in
> > the
> > > > AS)
> > > > > >
> > > > > > * Maybe “2 hours ago” is not precise enough. In your example I
> see
> > I
> > > > > created and modified the Roadmap page but they both say “2 hours
> > ago”.
> > > > > Shouldn’t I be able to see how far away both events were done?
> > > > >
> > > > > My understanding is that events are grouped by app+type but not by
> > > entity
> > > > > anymore (for page events) and thus you can have 3 events displayed
> > for
> > > > the
> > > > > same page, f.ex: Creation, Modification, Deletion.
> > > > >
> > > >
> > > > And you could also have different users grouped in the same composite
> > > > event. So when you display the details, it would be nice to show
> which
> > > user
> > > > made each event, and I see you have removed this info.
> > > >
> > >
> > > The focus of this proposal is on user, compared to the old one, when it
> > was
> > > on the app/doc.
> > > Close to what we have on Facebool. So it didn't made sense that we say
> > that
> > > a page has been edited by vmassol, and that the details showcase that
> > > multiple user actually did the edit.
> > >
> >
> > In Facebook, you have it actually:
> > https://pasteboard.co/GOioRAT.png
> >
> > On XWiki, we have the following (already implemented):
> > https://pasteboard.co/GOiqgYf.png
> >
> >
> > Thanks,
> >
> >
> > >
> > >
> > > >
> > > >
> > > >
> > > > >
> > > > > Thanks
> > > > > -Vincent
> > > > >
> > > > > >
> > > > > > Thanks
> > > > > > -Vincent
> > > > > >
> > > > > >>
> > > > > >> Thanks
> > > > > >> -Vincent
> > > > > >>
> > > > > >>> On 2 Oct 2017, at 1

Re: [xwiki-devs] [Proposal][UX] Notifications Improvements 9.8+

[Guillaume Delhumeau]

2017-10-03 17:32 GMT+02:00 Ecaterina Moraru (Valica) <vali...@gmail.com>:

> On Tue, Oct 3, 2017 at 10:50 AM, Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com> wrote:
>
> > 2017-10-02 18:09 GMT+02:00 Vincent Massol <vinc...@massol.net>:
> >
> > >
> > > > On 2 Oct 2017, at 18:08, Vincent Massol <vinc...@massol.net> wrote:
> > > >
> > > >
> > > >> On 2 Oct 2017, at 18:05, Vincent Massol <vinc...@massol.net> wrote:
> > > >>
> > > >> Another feedback/questions:
> > > >>
> > > >> * Is the avatar icon clickable and leading to the user profile?
> > > >> * We need a way to link directly to the diff, at least for page
> events
> > > so that the user can see what was modified (as we have currently in the
> > AS)
> > > >
> > > > * Maybe “2 hours ago” is not precise enough. In your example I see I
> > > created and modified the Roadmap page but they both say “2 hours ago”.
> > > Shouldn’t I be able to see how far away both events were done?
> > >
> > > My understanding is that events are grouped by app+type but not by
> entity
> > > anymore (for page events) and thus you can have 3 events displayed for
> > the
> > > same page, f.ex: Creation, Modification, Deletion.
> > >
> >
> > And you could also have different users grouped in the same composite
> > event. So when you display the details, it would be nice to show which
> user
> > made each event, and I see you have removed this info.
> >
>
> The focus of this proposal is on user, compared to the old one, when it was
> on the app/doc.
> Close to what we have on Facebool. So it didn't made sense that we say that
> a page has been edited by vmassol, and that the details showcase that
> multiple user actually did the edit.
>

In Facebook, you have it actually:
https://pasteboard.co/GOioRAT.png

On XWiki, we have the following (already implemented):
https://pasteboard.co/GOiqgYf.png


Thanks,


>
>
> >
> >
> >
> > >
> > > Thanks
> > > -Vincent
> > >
> > > >
> > > > Thanks
> > > > -Vincent
> > > >
> > > >>
> > > >> Thanks
> > > >> -Vincent
> > > >>
> > > >>> On 2 Oct 2017, at 18:01, Vincent Massol <vinc...@massol.net>
> wrote:
> > > >>>
> > > >>>
> > > >>>> On 2 Oct 2017, at 17:54, Ecaterina Moraru (Valica) <
> > vali...@gmail.com>
> > > wrote:
> > > >>>>
> > > >>>> Event Type: BlogPostPublishedEvent
> > > >>>> from
> > > >>>> http://design.xwiki.org/xwiki/bin/view/Proposal/
> > > NotificationsImprovements9x#HEventTypes
> > > >>>
> > > >>> ok thanks, had missed this since I was reading from top to bottom
> and
> > > stopped at the overview :)
> > > >>>
> > > >>> However I don’t think it scales since it means one unique icon per
> > > combination of app type + event type.
> > > >>>
> > > >>> What would scale better is two icons: one for the app type and one
> > for
> > > the event type.
> > > >>>
> > > >>> For example imagine that the Blog app had the following events:
> > > >>> * When a blog post is published
> > > >>> * When a blog post is created
> > > >>> * When a blog post is removed
> > > >>>
> > > >>> You wouldn’t be able to use the RSS icon to represent the 3 events.
> > > >>>
> > > >>> BTW the RSS icon isn’t necessarily representative of the Blog app.
> A
> > > lot of apps can have a RSS feed.
> > > >>>
> > > >>> That’s the main remark I have: it’s going to be harder and harder
> to
> > > find unique icons as we had more events to apps, especially if there’s
> > only
> > > 1 icon that is supposed to combine both app type + event type.
> > > >>>
> > > >>> WDYT?
> > > >>>
> > > >>> Thanks
> > > >>> -Vincent
> > > >>>
> > > >>>> Thanks,
> > > >>>> Caty
> > > >>>>
> > > >>>> On Mon, Oct 2, 2017 at 6:52 PM, Vincent Massol <
> vinc...@massol.net>
> > > wrote:
> > > >>>>
> > > >>>>> Hi Caty,
> > > >>>>>
> > > >>>>>> On 2 Oct 2017, at 17:21, Ecaterina Moraru (Valica) <
> > > vali...@gmail.com>
> > > >>>>> wrote:
> > > >>>>>>
> > > >>>>>> Hi,
> > > >>>>>>
> > > >>>>>> I've created some improvements suggestions for our Notifications
> > > UI, see
> > > >>>>>> http://design.xwiki.org/xwiki/bin/view/Proposal/
> > > >>>>> NotificationsImprovements9x
> > > >>>>>>
> > > >>>>>> Let me know what you think.
> > > >>>>>
> > > >>>>> Re the overview, I don’t see where you mention the app?
> > > >>>>>
> > > >>>>> For example, could you show how a new Blog post would be
> displayed
> > > and you
> > > >>>>> differentiate that for example from a Page creation or
> > modification?
> > > >>>>>
> > > >>>>> Thanks
> > > >>>>> -Vincent
> > > >>>>>
> > > >>>>>>
> > > >>>>>> Thanks,
> > > >>>>>> Caty
> > > >>>>>
> > > >>>>>
> > > >>>
> > > >>
> > > >
> > >
> > >
> >
> >
> > --
> > Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
> > Research & Development Engineer at XWiki SAS
> > Committer on the XWiki.org project
> >
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project

Re: [xwiki-devs] [Proposal][UX] Notifications Improvements 9.8+

[Guillaume Delhumeau]

2017-10-07 2:08 GMT+02:00 Eduard Moraru <enygma2...@gmail.com>:

> Hi,
>
> I was wondering if we could identify the center point of an notification by
> considering the action that the current user (receiving the notification)
> did to subscribe to that event, i.e. what actually interests the current
> user.
>
> 1) Now, if we consider the Watchlist approach where a user goes to a
> page/wiki and clicks "watch"/"subscribe", then we could see the point of
> interest as the content... since the user wants to be notified when changes
> are made to that content... by whoever.
> ... in this case, it makes sense to see the events of, say the recent 24
> hours, grouped by pages and only in their details to see which users and
> what even types they performed.
>
> 2) If we consider going to the user profile and clicking "follow", then the
> current user is interested in the getting notifications of the changes done
> by that particular user, no matter the page.
> ... in this case, I would imagine the user expecting to see events in the
> last 24 hours grouped by users "i.e. user X worked on 5 pages" and, when
> expanding, to see which pages and what type of events...
>
> 3) Finally, there are applications, where events could be sent by either
> users of the application (e.g. Blog, AWM, etc.) or by the application
> itself (e.g. Meeting Manager/Calendar sending a reminder to the
> participants, 30 minutes before, about an upcoming meeting/event).
> ... in this case, the user subscribes to the application (or is
> automatically subscribed and can unsubscribe).
>
> Not sure if this helps to the discussion, just thought I'd share.
>

The user could have done many of these actions. So we need to chose a
standard "view" in that case.



>
> Thanks,
> Eduard
>
> On Thu, Oct 5, 2017 at 4:58 PM, Ecaterina Moraru (Valica) <
> vali...@gmail.com
> > wrote:
>
> > On Wed, Oct 4, 2017 at 4:04 PM, Guillaume Delhumeau <
> > guillaume.delhum...@xwiki.com> wrote:
> >
> > > 2017-10-03 17:34 GMT+02:00 Ecaterina Moraru (Valica) <
> vali...@gmail.com
> > >:
> > >
> > > > On Tue, Oct 3, 2017 at 11:27 AM, Thomas Mortagne <
> > > > thomas.morta...@xwiki.com>
> > > > wrote:
> > > >
> > > > > On Tue, Oct 3, 2017 at 9:54 AM, Guillaume Delhumeau
> > > > > <guillaume.delhum...@xwiki.com> wrote:
> > > > > > So your proposal focuses a lot more on the users instead of the
> > apps
> > > > > (like
> > > > > > facebook for example). It's OK for me, but I think the type icon
> > > > (create,
> > > > > > edit, comment, etc...) is too small compared to the user face.
> > > > > >
> > > > > > Actually when I see these screenshot, my first impression is that
> > the
> > > > > user
> > > > > > has been modified :) Would it be nice to have the type icon
> bigger
> > > than
> > > > > the
> > > > > > user face? To me, what happened is more important than who made
> it,
> > > but
> > > > > > maybe it's only my feeling.
> > > > >
> > > > > Pretty much the same comments on my side. I find weird to focus
> that
> > > > > much on users, I would have preferred images corresponding on the
> > > > > change made.
> > > > >
> > > >
> > > > Depends on what we want to focus on and also on what are user's
> > > > expectations.
> > > > If you look at the majority of notifcations in the wild, the user is
> > the
> > > > focus.
> > > > People want to know who did what, on what page, when.
> > > >
> > >
> > > But Facebook, for example, is a social network. It focuses on people by
> > > nature. On XWiki, it is not that evident. In the case of a knowledge
> > base,
> > > you focus more on the content (the knowledge) than on the people. On
> > > xwiki.org, I guess you prefer seeing what's change instead of who made
> > > some
> > > changes...
> > >
> > >
> > I know the pages are important, that's why the first link and item
> > displayed is the page name.
> > I want to know if a spam user did something.
> >
> > Thanks,
> > Caty
> >
> >
> > > If we define XWiki as a collaboration tool, then you collaborate to
> > create
> > > something and so the focus is naturally more on that "something".

[xwiki-devs] [ANN] XWiki 9.8.1 released

[Guillaume Delhumeau]

The XWiki development team is proud to announce the availability of XWiki
9.8.1.
This is a bug fix release that bring corrections for important issues we
have discovered since 9.8 has been released.

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/9.8.1/

Thanks for your support
-The XWiki dev team

Re: [xwiki-devs] [Proposal][UX] Notifications Improvements 9.8+

[Guillaume Delhumeau]

On big instances such as Wikipedia, you might not even know personally who
is the user who contributed (but notifications might not scale in a
Wikipedia instance anyway).

2017-10-04 15:13 GMT+02:00 Thomas Mortagne <thomas.morta...@xwiki.com>:

> On Wed, Oct 4, 2017 at 3:04 PM, Guillaume Delhumeau
> <guillaume.delhum...@xwiki.com> wrote:
> > 2017-10-03 17:34 GMT+02:00 Ecaterina Moraru (Valica) <vali...@gmail.com
> >:
> >
> >> On Tue, Oct 3, 2017 at 11:27 AM, Thomas Mortagne <
> >> thomas.morta...@xwiki.com>
> >> wrote:
> >>
> >> > On Tue, Oct 3, 2017 at 9:54 AM, Guillaume Delhumeau
> >> > <guillaume.delhum...@xwiki.com> wrote:
> >> > > So your proposal focuses a lot more on the users instead of the apps
> >> > (like
> >> > > facebook for example). It's OK for me, but I think the type icon
> >> (create,
> >> > > edit, comment, etc...) is too small compared to the user face.
> >> > >
> >> > > Actually when I see these screenshot, my first impression is that
> the
> >> > user
> >> > > has been modified :) Would it be nice to have the type icon bigger
> than
> >> > the
> >> > > user face? To me, what happened is more important than who made it,
> but
> >> > > maybe it's only my feeling.
> >> >
> >> > Pretty much the same comments on my side. I find weird to focus that
> >> > much on users, I would have preferred images corresponding on the
> >> > change made.
> >> >
> >>
> >> Depends on what we want to focus on and also on what are user's
> >> expectations.
> >> If you look at the majority of notifcations in the wild, the user is the
> >> focus.
> >> People want to know who did what, on what page, when.
> >>
> >
> > But Facebook, for example, is a social network. It focuses on people by
> > nature. On XWiki, it is not that evident. In the case of a knowledge
> base,
> > you focus more on the content (the knowledge) than on the people. On
> > xwiki.org, I guess you prefer seeing what's change instead of who made
> some
> > changes...
> >
> > If we define XWiki as a collaboration tool, then you collaborate to
> create
> > something and so the focus is naturally more on that "something".
> >
> > Just my 2 cents :)
>
> Some for me, if "the majority of notifcations in the wild" only refer
> to social networks and communication tools then it's not a good input
> for a wiki IMO.
>
> >
> >
> >
> >>
> >>
> >> >
> >> > >
> >> > > Nice work anyway, as usual :)
> >> > >
> >> > > Guillaume
> >> > >
> >> > > 2017-10-03 9:50 GMT+02:00 Guillaume Delhumeau <
> >> > guillaume.delhum...@xwiki.com
> >> > >>:
> >> > >
> >> > >>
> >> > >>
> >> > >> 2017-10-02 18:09 GMT+02:00 Vincent Massol <vinc...@massol.net>:
> >> > >>
> >> > >>>
> >> > >>> > On 2 Oct 2017, at 18:08, Vincent Massol <vinc...@massol.net>
> >> wrote:
> >> > >>> >
> >> > >>> >
> >> > >>> >> On 2 Oct 2017, at 18:05, Vincent Massol <vinc...@massol.net>
> >> wrote:
> >> > >>> >>
> >> > >>> >> Another feedback/questions:
> >> > >>> >>
> >> > >>> >> * Is the avatar icon clickable and leading to the user profile?
> >> > >>> >> * We need a way to link directly to the diff, at least for page
> >> > events
> >> > >>> so that the user can see what was modified (as we have currently
> in
> >> > the AS)
> >> > >>> >
> >> > >>> > * Maybe “2 hours ago” is not precise enough. In your example I
> see
> >> I
> >> > >>> created and modified the Roadmap page but they both say “2 hours
> >> ago”.
> >> > >>> Shouldn’t I be able to see how far away both events were done?
> >> > >>>
> >> > >>> My understanding is that events are grouped by app+type but not by
> >> > entity
> >> > >>> anymore (for page events) and thus you can have 3 events displayed
> >> for
> >> > the
> >> > &g

Re: [xwiki-devs] [Proposal][UX] Notifications Improvements 9.8+

[Guillaume Delhumeau]

2017-10-03 17:34 GMT+02:00 Ecaterina Moraru (Valica) <vali...@gmail.com>:

> On Tue, Oct 3, 2017 at 11:27 AM, Thomas Mortagne <
> thomas.morta...@xwiki.com>
> wrote:
>
> > On Tue, Oct 3, 2017 at 9:54 AM, Guillaume Delhumeau
> > <guillaume.delhum...@xwiki.com> wrote:
> > > So your proposal focuses a lot more on the users instead of the apps
> > (like
> > > facebook for example). It's OK for me, but I think the type icon
> (create,
> > > edit, comment, etc...) is too small compared to the user face.
> > >
> > > Actually when I see these screenshot, my first impression is that the
> > user
> > > has been modified :) Would it be nice to have the type icon bigger than
> > the
> > > user face? To me, what happened is more important than who made it, but
> > > maybe it's only my feeling.
> >
> > Pretty much the same comments on my side. I find weird to focus that
> > much on users, I would have preferred images corresponding on the
> > change made.
> >
>
> Depends on what we want to focus on and also on what are user's
> expectations.
> If you look at the majority of notifcations in the wild, the user is the
> focus.
> People want to know who did what, on what page, when.
>

But Facebook, for example, is a social network. It focuses on people by
nature. On XWiki, it is not that evident. In the case of a knowledge base,
you focus more on the content (the knowledge) than on the people. On
xwiki.org, I guess you prefer seeing what's change instead of who made some
changes...

If we define XWiki as a collaboration tool, then you collaborate to create
something and so the focus is naturally more on that "something".

Just my 2 cents :)



>
>
> >
> > >
> > > Nice work anyway, as usual :)
> > >
> > > Guillaume
> > >
> > > 2017-10-03 9:50 GMT+02:00 Guillaume Delhumeau <
> > guillaume.delhum...@xwiki.com
> > >>:
> > >
> > >>
> > >>
> > >> 2017-10-02 18:09 GMT+02:00 Vincent Massol <vinc...@massol.net>:
> > >>
> > >>>
> > >>> > On 2 Oct 2017, at 18:08, Vincent Massol <vinc...@massol.net>
> wrote:
> > >>> >
> > >>> >
> > >>> >> On 2 Oct 2017, at 18:05, Vincent Massol <vinc...@massol.net>
> wrote:
> > >>> >>
> > >>> >> Another feedback/questions:
> > >>> >>
> > >>> >> * Is the avatar icon clickable and leading to the user profile?
> > >>> >> * We need a way to link directly to the diff, at least for page
> > events
> > >>> so that the user can see what was modified (as we have currently in
> > the AS)
> > >>> >
> > >>> > * Maybe “2 hours ago” is not precise enough. In your example I see
> I
> > >>> created and modified the Roadmap page but they both say “2 hours
> ago”.
> > >>> Shouldn’t I be able to see how far away both events were done?
> > >>>
> > >>> My understanding is that events are grouped by app+type but not by
> > entity
> > >>> anymore (for page events) and thus you can have 3 events displayed
> for
> > the
> > >>> same page, f.ex: Creation, Modification, Deletion.
> > >>>
> > >>
> > >> And you could also have different users grouped in the same composite
> > >> event. So when you display the details, it would be nice to show which
> > user
> > >> made each event, and I see you have removed this info.
> > >>
> > >>
> > >>
> > >>>
> > >>> Thanks
> > >>> -Vincent
> > >>>
> > >>> >
> > >>> > Thanks
> > >>> > -Vincent
> > >>> >
> > >>> >>
> > >>> >> Thanks
> > >>> >> -Vincent
> > >>> >>
> > >>> >>> On 2 Oct 2017, at 18:01, Vincent Massol <vinc...@massol.net>
> > wrote:
> > >>> >>>
> > >>> >>>
> > >>> >>>> On 2 Oct 2017, at 17:54, Ecaterina Moraru (Valica) <
> > >>> vali...@gmail.com> wrote:
> > >>> >>>>
> > >>> >>>> Event Type: BlogPostPublishedEvent
> > >>> >>>> from
> > >>> >>>> http://design.xwiki.org/xwiki/bin/vi

Re: [xwiki-devs] [Proposal][UX] Notifications Improvements 9.8+

[Guillaume Delhumeau]

2017-10-03 17:32 GMT+02:00 Ecaterina Moraru (Valica) <vali...@gmail.com>:

> On Tue, Oct 3, 2017 at 10:50 AM, Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com> wrote:
>
> > 2017-10-02 18:09 GMT+02:00 Vincent Massol <vinc...@massol.net>:
> >
> > >
> > > > On 2 Oct 2017, at 18:08, Vincent Massol <vinc...@massol.net> wrote:
> > > >
> > > >
> > > >> On 2 Oct 2017, at 18:05, Vincent Massol <vinc...@massol.net> wrote:
> > > >>
> > > >> Another feedback/questions:
> > > >>
> > > >> * Is the avatar icon clickable and leading to the user profile?
> > > >> * We need a way to link directly to the diff, at least for page
> events
> > > so that the user can see what was modified (as we have currently in the
> > AS)
> > > >
> > > > * Maybe “2 hours ago” is not precise enough. In your example I see I
> > > created and modified the Roadmap page but they both say “2 hours ago”.
> > > Shouldn’t I be able to see how far away both events were done?
> > >
> > > My understanding is that events are grouped by app+type but not by
> entity
> > > anymore (for page events) and thus you can have 3 events displayed for
> > the
> > > same page, f.ex: Creation, Modification, Deletion.
> > >
> >
> > And you could also have different users grouped in the same composite
> > event. So when you display the details, it would be nice to show which
> user
> > made each event, and I see you have removed this info.
> >
>
> The focus of this proposal is on user, compared to the old one, when it was
> on the app/doc.
> Close to what we have on Facebool. So it didn't made sense that we say that
> a page has been edited by vmassol, and that the details showcase that
> multiple user actually did the edit.
>

But it's the way it is implemented right now. If we change that, it's not
only an UI change, it's also on the API-side too. Or maybe we could display
more than one avatar ?

Other problem: the emails that the notifications module send are supposed
to replace the watchlist at some point. Vincent already complained about
the fact the events concerning documents are not displayed as a tree,
corresponding to the hierarchy of the pages. I could think of a way to
display the events as a tree, but if we decide to focus more on the users,
we are going in two opposite directions.

Do you plan to cover the email case in your proposals?

Thanks,


>
> >
> >
> >
> > >
> > > Thanks
> > > -Vincent
> > >
> > > >
> > > > Thanks
> > > > -Vincent
> > > >
> > > >>
> > > >> Thanks
> > > >> -Vincent
> > > >>
> > > >>> On 2 Oct 2017, at 18:01, Vincent Massol <vinc...@massol.net>
> wrote:
> > > >>>
> > > >>>
> > > >>>> On 2 Oct 2017, at 17:54, Ecaterina Moraru (Valica) <
> > vali...@gmail.com>
> > > wrote:
> > > >>>>
> > > >>>> Event Type: BlogPostPublishedEvent
> > > >>>> from
> > > >>>> http://design.xwiki.org/xwiki/bin/view/Proposal/
> > > NotificationsImprovements9x#HEventTypes
> > > >>>
> > > >>> ok thanks, had missed this since I was reading from top to bottom
> and
> > > stopped at the overview :)
> > > >>>
> > > >>> However I don’t think it scales since it means one unique icon per
> > > combination of app type + event type.
> > > >>>
> > > >>> What would scale better is two icons: one for the app type and one
> > for
> > > the event type.
> > > >>>
> > > >>> For example imagine that the Blog app had the following events:
> > > >>> * When a blog post is published
> > > >>> * When a blog post is created
> > > >>> * When a blog post is removed
> > > >>>
> > > >>> You wouldn’t be able to use the RSS icon to represent the 3 events.
> > > >>>
> > > >>> BTW the RSS icon isn’t necessarily representative of the Blog app.
> A
> > > lot of apps can have a RSS feed.
> > > >>>
> > > >>> That’s the main remark I have: it’s going to be harder and harder
> to
> > > find unique icons as we had more events to apps, especially if there’s
> > only
> > > 1 icon that is suppo