- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] [Proposal] Roadmap for XS 11.8
by Vincent Massol 03 Sep '19

03 Sep '19

Hi devs, Sorry, I’m late with this roadmap proposal. Tasks: * Finish merge conflict: allow choice by chunks and custom fixes - https://jira.xwiki.org/browse/XWIKI-16464 - Simon * Improved performances - Thomas - Some ideas: * User profile "Wikis" section make accessing the profile a huge pain when there is lots of wikis - https://jira.xwiki.org/browse/XWIKI-15648, * Possibly start testing stuff for the notifications storage refactoring (more an investigation) * Make more standard elements asynchronous * Make sure we can finally close https://jira.xwiki.org/browse/XWIKI-14806 - "9.9 is much slower than 8.4.5” * There is also some performance work around job logs * Ability to easily export only content from the XWiki Administration - Marius (basic implementation) Dates: * 11.8RC1: 23rd of Sep * 11.8 final: 30th of Sep WDYT? I’ve proactively put it on https://www.xwiki.org/xwiki/bin/view/Roadmaps/ Thanks -Vincent

1 0

[xwiki-devs] [XWiki Day] BFD#222
by Simon Urli 30 Aug '19

30 Aug '19

Hello devs, This Thursday is BFD#222: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingday Our current status is: * -19 bugs over 120 days (4 months), i.e. we need to close 19 bugs to have created bugs == closed bugs * -85 bugs over 365 days (1 year) * -147 bugs over 500 days (between 1 and 2 years) * -374 bugs over 1600 days (4.3 years) See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#222 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14439 Good luck at fixing bugs, Simon -- Simon Urli Software Engineer at XWiki SAS simon.urli(a)xwiki.com More about us at http://www.xwiki.com

1 1

[xwiki-devs] [ANN] XWiki 11.7 released
by Marius Dumitru Florea 27 Aug '19

27 Aug '19

The XWiki development team is proud to announce the availability of XWiki 11.7. This release brings a new date picker and various merge improvements. Developers will also be able to reuse the standard color picker and the merge API give more details about the conflicts. You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.7 Thanks for your support -The XWiki dev team

1 0

[xwiki-devs] [XWiki Day] BFD#221
by Oana-Lavinia Florean 23 Aug '19

23 Aug '19

Hello devs, This Thursday is BFD#221: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingday Our current status is: * -8 bugs over 120 days (4 months), i.e. we need to close 8 bugs to have created bugs == closed bugs * -77 bugs over 365 days (1 year) * -132 bugs over 500 days (between 1 and 2 years) * -360 bugs over 1600 days (4.3 years) See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#221 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14438 Good luck at fixing bugs, Lavinia

1 1

Re: [xwiki-devs] Map Application - GSoC 19
by Fawad Ali 23 Aug '19

23 Aug '19

Hi all, I wanted to ask if it was possible to have a custom class sheet and the editing options of a normal page available at the same time? As it stands, for the PointSheet, we will have to skip the WYSIWYG editor for editing the page. However, one thing could be that instead of taking the page's content for the Point's popup, we could introduce a new class property popupContent and have the popup content inside that. This way, we can use WYSIWYG as well. Another approach could be to keep the current Point Editor and use that create points without any sheet. The same questions apply for the Shape Editor as well. What do you think? Best, Fawad On Fri, Aug 2, 2019 at 2:53 PM Fawad Ali <m.fawaadali98(a)gmail.com> wrote: > Stéphane, > > Yes, sure. > In the meantime, I will be working on the PointSheet. > However, I do want to ask if the Shape Editor is necessary at this point > if we are going with GeoJSON. We can refer the user to http://geojson.io > for creating the features. What do you think? > > Best, > Fawad > > > On Fri, Aug 2, 2019 at 12:04 PM Stéphane Laurière <slauriere(a)xwiki.com> > wrote: > >> OK Fawad, >> >> Meantime since Caty is off, and since today might actually be a bit early >> for me I'm afraid, I'd propose we have the call on Monday 15:00 UTC on >> Monday if that's ok with you . >> >> Cheers >> >> Stéphane >> >> >> Fawad Ali: >> > Stéphane, Ecaterina, >> > >> > About the call, I think we should have it so that we all converge on >> the things to be done. >> > However, tomorrow (Friday), I have a call with the Pakistan's GSoC >> community at about 5 PM UTC. If the call will be finished in two hours I am >> fine with it or we could reschedule it to 2:30 PM UTC or else Monday. >> > >> > Best, >> >> >> -- >> Stéphane Laurière >> XWiki – https://xwiki.com >> >>

2 19

[xwiki-devs] [Proposal] Remove XWiki.User enable property and introduce email_check property
by Simon Urli 23 Aug '19

23 Aug '19

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

5 6

[xwiki-devs] Application pages layout best practices
by Stéphane Laurière 22 Aug '19

22 Aug '19

Hi everyone, I'm following up on a thread started in 2015 about the best practices regarding app pages organization: - https://xwiki.markmail.org/message/657vcm6ylkz4yytc - https://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPr… In this thread, the idea of introducing a dedicated common root area for all application technical pages was suggested by Denis: https://xwiki.markmail.org/message/kk5l3dwjmpfelkzp I'm wondering why this idea was not pushed further (it's not strictly incompatible with the current best practices, but most of the recent applications have their top level area, except a few like Notifications or ChartJS). Comparing with how other platforms do is inspirational (Microsoft Windows "Program Files" was mentioned in the thread). On Debian, the Maven package is installed in /usr/share/maven/ while files used and produced by Maven can be located anywhere. Along the same line, I would see as a user and developer experience improvement if we had the following structure: 1) Code: XWiki |- MyApp |- MyAppClass |- MyAppSheet |- ... 2) Data: the pages created by MyApp could then typically be located by default in a MyApp space at the root of the wiki, the user could however choose which default space to use, or leave it empty (then the space from where the user fires the create action could be used, for instance, or any scriptable rule). Another issue I see with the current practice (raised by Clément A. orally) is that some application names may conflict with names the user would like to use for content that is not strictly related to the app. Not necessarily a big deal with one thousand of applications, but might become one with more, wouldn't it? I understand that the layout proposed above would raise technical issues (XWiki space permissions for instance, mentionned in the 2015 thread, and others), however what's your view on it from a design perspective? (sorry if I overlooked strong arguments already expressed against it) Cheers Stéphane

2 4

[xwiki-devs] [ANN] XWiki 11.7 RC1 released
by Thomas Mortagne 20 Aug '19

20 Aug '19

The XWiki development team is proud to announce the availability of XWiki 11.7 RC1. This release brings a new date picker and various merge improvements. Developers will also be able to reuse the standard color picker and the merge API give more details about the conflicts. You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.7RC1 Thanks for your support -The XWiki dev team

1 0

[xwiki-devs] [contrib] any interest in another authenticator that deals with failed logins
by Clemens Klein-Robbenhaar 19 Aug '19

19 Aug '19

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

5 4

[xwiki-devs] [XWiki Day] BFD#220
by Oana-Lavinia Florean 09 Aug '19

09 Aug '19

Hello devs, This Thursday is BFD#220: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingday Our current status is: * -26 bugs over 120 days (4 months), i.e. we need to close 26 bugs to have created bugs == closed bugs * -98 bugs over 365 days (1 year) * -153 bugs over 500 days (between 1 and 2 years) * -376 bugs over 1600 days (4.3 years) See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#220 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14434 Good luck at fixing bugs, Lavinia

1 1