September 2018 - xwiki-devs@xwiki.org

[xwiki-devs] [XWiki Day] BFD#187
by Alex Cotiugă 07 Sep '18

07 Sep '18

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

2 2

[xwiki-devs] Roadmap process defined
by Vincent Massol 06 Sep '18

06 Sep '18

Hi devs, We’ve been following a roadmap process and a development flow for years but Adel just mentioned to me that this process wasn’t documented. Thus I’ve tried to define it on https://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HRoadmap Could you please all read it and verify it matches the process that you have in mind and that we think we’re following :) Thanks! -Vincent

1 0

[xwiki-devs] [API] New GroupManager component
by Thomas Mortagne 06 Sep '18

06 Sep '18

Hi devs, I just introduced a new GroupManager API (and related script service and new modules). The idea (for now) is just to provide two new clean entry points to: * get the members of a group * get the groups of a member Right, yet another one but here is what's new: * it's a component * you can use it without depending on oldcore * it support groups of groups * there is a cache behind the scene for all that Main Java entry point: https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwi… Script service ($services.user.group): https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwi… Also to start actually using it I added in the profile a new section which display all the groups (including groups of groups) the user belongs to. I also needed the feature in a 8.4.5 wiki so I published a contrib extension you can use before 10.8: https://extensions.xwiki.org/xwiki/bin/view/Extension/User%20membership%20i… (this is the application but the API is available too, look at the application dependencies). TODO: * remove the cache from group service and recommend using the new component instead (the new component is still based on the group service since people might implement this service another way so it's safer to keep going trough the configured service for now, also it's not that based to separate caching and groups of groups handling from storage anyway) * track down all uses of the group service and the old rightmanager plugin group membership related methods and replace them with the new API FUTURE: The module name is xwiki-platform-user-api and there is a (empty except from the sub script service bridge) user script service, the idea being that we will want to add other user related APIs there in the future but I did not had time to work on the big picture so I left room for it. Thanks, -- Thomas Mortagne

2 2

[xwiki-devs] Follow-up brainstorming about adding apps in administration (menu, scheduler)
by Simon Urli 05 Sep '18

05 Sep '18

Hello everyone, I'm writing this email as a follow-up after (yet another) brainstorming with Vincent about how adding the app Menu in the administration (https://jira.xwiki.org/browse/XWIKI-15483) Sorry in advance if I repeat things that have already been said. So the general problem is that we want to be able to put apps with an existing UI in the admin context, without loosing the ability to use the apps outside the admin. It's already possible to include external apps in the admin in keeping their UI, but it implies that the app can be used without changing the page: for example, the menu app involves to go to /edit when creating a new menu so it cannot be directly integrated as it is now. The best solution would be to create two UIs, one for the app to be used externally and one for the admin, but then it would imply to maintain twice the code. The solution on which we agreed with Vincent on the short-term view, is to provide in the admin the app inside an iframe: the only problem we see would be the design adaptation, especially for the responsiveness, but it should do the job. Another solution discussed, to only allow using the app through the admin (and so to keep only this UI) seems not acceptable as the app might be used by other users in some usecases. It's also possible to only provide in the admin a link to the app, and then to open it using the standard path, i.e. outside the admin, but then the user might be constantly switching context which looks bad in the UX point of view. Maybe to ponderate this problem of context switching, a long term view solution would be to allow displaying the administration menu in some apps but I really don't know if it's feasible or not. So to conclude, first: - do you agree with the short term solution to use an iframe for displaying the admin app in the admin, at least as a first step for the menu app? Then how do you think we should do more globally for the other admin app (menu, scheduler, stats, admintools, ...): 1. maintain two UIs 2. include the existing UI in an iframe 3. provide only a link to access the app externally 4. ... another idea? Thanks, Simon -- Simon Urli Software Engineer at XWiki SAS simon.urli(a)xwiki.com More about us at http://www.xwiki.com

3 3

[xwiki-devs] [VOTE] Update the xar plugin and stop committing XML wiki page date fields
by Eduard Moraru 03 Sep '18

03 Sep '18

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

8 9

[xwiki-devs] [Proposal] Roadmap for XWiki 10.8
by Vincent Massol 03 Sep '18

03 Sep '18

Hi devs, With one week late (sorry!), here’s the proposal for XWiki 10.8 (already discussed with committers from XWiki SAS): Dates: * 10.8RC1: 17th of Sep * 10.8Final: 24th of Sep. Scope: * Thomas, Marius, Adel, Simon, anyone interested: Improve STAMP KPIs (20%) - 1 day per week * All: BFD (20%) * Thomas: continue work on performance (started in 10.4). Goal: go back to XWiki 8.x performance! Hint: https://t.co/0ZckyVYg6c ;) * Thomas: Add a new tab in the user profile to list groups the user belongs to * Marius: Improve the Group sheet page. When viewing a group page, be able to filter by first name, last name in addition of id (which is already implemented). * Guillaume: Notifications performance + bugfixes * Marius/Adel/Simon: For macros having wiki markup content (need new macro descriptor metadata), let the user enter it in the WYSIWYG directly. When hovering over the macro allow editing content + have some icons to edit parameters (similar to the CKEditor easy image feature: https://github.com/ckeditor/ckeditor-dev/issues/932 They call it a "balloon toolbar"). Related: http://design.xwiki.org/xwiki/bin/view/Improvements/MacrosOptions * Marius/Adel/Simon: Move Menus inside administration (see http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaMenuInAdministration) * Adel/Simon: finish applying Autocomplete on reference everywhere, see https://design.xwiki.org/xwiki/bin/view/Proposal/AutocompleteOnReference#HW… * Vincent/Thomas: Possible work on improving the LaTeX exporter (will maybe be done in October or split between Sep. and Oct.) * Caty: investigate how we could make the upgrade experience simpler. * Caty: investigation for a new XClass picker in object edit mode As usual let me now if there are some issues and please update https://www.xwiki.org/xwiki/bin/view/Roadmaps/ with the corresponding list of JIRA issues (create them if they don’t exist). Ofc, if anyone is interested to also contribute other things to this roadmap please let us know by replying to this mail. Thanks! -Vincent

1 0