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

[xwiki-devs] Use the new Mail Sender API for the Share Page By Mail feature
by Gabriel Raileanu 09 Aug '19

09 Aug '19

Hello everyone! Currently, I'm working on moving to the new Mail Sender API for share page by mail, which is related in XWiki-11786 <https://jira.xwiki.org/browse/XWIKI-11786>. After having some discussions with Vincent, we decided to include the possibility of sending the email to groups, related in XWiki-12112 <https://jira.xwiki.org/browse/XWIKI-12112>. Even if everything looks good for now, a problem just appeared when trying to access the recipient name (it's used in the email body, for addressing the recipient (*Hello ${recipientName}*). It seems like the new API it's not providing other information than the email address, which was confirmed by XWiki-12207 <https://jira.xwiki.org/browse/XWIKI-12207>. For now, I worked here <https://github.com/arcilli/xwiki-platform/tree/XWIKI-12112> with some code from Vincent's commits <https://github.com/xwiki/xwiki-platform/tree/feature-sharepage-group>. Also, after a few discussions with Marius, we concluded that for having the name of the recipient in the message, the code needs some refactoring, which can take a considerable amount of time. Another solution is to exclude the *recipientName *from the body of the message and keep only *Hello *(which would be a regression). This will be a shorter solution, but with the benefit of having the possibility to send emails to groups. What's your opinion on this? Thanks a lot! Have a nice day! -- <http://www.xwiki.com/> *Gabriel Răileanu* *Software Developer Engineer Intern* gabriel.raileanu(a)xwiki.com

2 1

[xwiki-devs] [ANN] XWiki 11.6.1 released
by Simon Urli 08 Aug '19

08 Aug '19

The XWiki development team is proud to announce the availability of XWiki 11.6.1. This is a bugfix release that covers important issues that we have discovered since XWiki 11.6 has been released. It has been released mainly to fix a bug related with the usage of nested wikimacro, which might make some applications unusable. It also fix some other bugs related to the newly introduced async macro. 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.6.1 Thanks for your support -The XWiki dev team

1 0

[xwiki-devs] [Proposal] Best practice: tests must not output anything outside of the target directory
by Vincent Massol 08 Aug '19

08 Aug '19

Hi devs, I was pretty sure that this was discussed before but I can’t find it so I’m posting it again since I noticed that we continue to have tests (and even add new ones) that use the OS tmp directory to output test data. Tests must not generate anything outside of the target/ directory as this will cause several problems: * not clean generated test data after the test * create a state that can make other tests fail * generate errors in jenkins since jenkins monitors created files and doesn't allow to remove files outside of the worskspace WDYT? If ok I’ll add it to https://dev.xwiki.org/xwiki/bin/view/Community/Testing/JavaUnitTesting/#HBe… Thanks -Vincent PS: Ideally we should have a automatic verification in the build but it doesn’t seem easy to implement, so right now, I’m only proposing it as a best practice.

4 4

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

02 Aug '19

Hello devs, This Thursday is BFD#219: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingday Our current status is: * -28 bugs over 120 days (4 months), i.e. we need to close 28 bugs to have created bugs == closed bugs * -94 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#219 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14433 Good luck at fixing bugs, Lavinia

1 1

[xwiki-devs] [Proposal] Use a standard 3-way merge implementation
by Simon Urli 01 Aug '19

01 Aug '19

Hello everyone, I'm currently working on the commons-diff-api to add new capabilities in case of conflict. Yesterday while I was working on it, I added new tests to check my changes and discovered that our current implementation of the 3-way merge was not following a "standard" implementation, and so some expectations I could have was not followed. Actually Thomas did a huge job by implementing by himself the 3-way merge based on the diff of previous-current and previous-next, but AFAIU this implementation does not take into account the diff current-next which can also bring information. So for example if you try to do a merge, with the following lines: origin="Once upon a time","a wolf","started to walk","in the forest" next="Once upon a time","a wolf","dressed in black","in the forest" current="Once upon a time","a wolf","started to walk","dressed in black","in the forest" the current result will be: "Once upon a time", "a wolf", "dressed in black", "dressed in black", "in the forest" instead of treating it like a conflict which can be view as a more "standard" answer. Here by standard, I mean the result that a tool like "diff3" or git merge would do. I dig a bit on internet yesterday and apparently diff3 is really considered as the standard implementation of a 3-way merge. I performed the check with those lines both using git and diff3 and in both cases, they see the "started to walk" as a conflictual line: Once upon a time a wolf <<<<<<< HEAD started to walk ======= >>>>>>> 20b7776... My change dressed in black in the forest I assume we could debug the implementation Thomas done to ensure this usecase is taken into account, as far as I can see it's not easy, but I guess it's possible. Another solution, which I personally prefer, would be to rely on an existing implementation of a diff3 merge, or Git merge: I found yesterday that jgit have their own Java implementation of the merge (https://github.com/eclipse/jgit/blob/master/org.eclipse.jgit/src/org/eclips…) and AFAICS the license doesn't prevent us to reuse it (it's a derived BSD license). I don't think we cannot completely reuse it as it is, but it's at least a good inspiration to do our own implementation based on a standard. A better solution would certainly to use a dedicated maintained library but I did not manage to find it. Now we could also assume that the current behaviour of the merge is what we want and we keep up with it. So what do you think, should we change our implem or keep it like that? Simon -- Simon Urli Software Engineer at XWiki SAS simon.urli(a)xwiki.com More about us at http://www.xwiki.com

1 0

[xwiki-devs] [VOTE] Officially support for Tomcat 9
by Thomas Mortagne 31 Jul '19

31 Jul '19

Hi devs, tomcat9 package is now available in Debian repositories so I would like to start providing xwiki-tomcat9-* Debian packages of XWiki. Nothing complex so far but it if we provide an official tomcat 9 oriented package it would also make more sense to add Tomcat 9 in https://dev.xwiki.org/xwiki/bin/view/Community/SupportStrategy/ServletConta… (only Tomcat 8 right now). Another argument is that it's the current recommended stable version from Tomcat point of view so people will use it more and more. WDYT ? Here is my +1 -- Thomas Mortagne

3 13

[xwiki-devs] [ANN] XWiki 11.6 released
by Alex Cotiugă 31 Jul '19

31 Jul '19

The XWiki development team is proud to announce the availability of XWiki 11.6. This release brings new security features related to user authentication and management, a new way to see document changes closer to the WYSIWYG edition and a new macro to define part of a document that should be asynchronously loaded for better performance. 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.6/ Thanks for your support -The XWiki dev team

1 0

[xwiki-devs] [XWiki Day] BFD#218
by Oana-Lavinia Florean 26 Jul '19

26 Jul '19

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

1 1

[xwiki-devs] [Proposal] Roadmap for XS 11.7
by Vincent Massol 26 Jul '19

26 Jul '19

Hi devs, Here’s a proposal for 11.7: To finish for XWiki 11.6 (in progress) ==================== July * Finish Visual diff (on HTML and not markup) - Marius * Editor Selection For TextArea Fields When Editing XObjects - http://jira.xwiki.org/browse/XWIKI-15753 - Marius * Add UI to activate/deactivate users - https://jira.xwiki.org/browse/XWIKI-12654 - Simon XWiki 11.7 ========== August: * 11.7-rc-1: 19th of Aug * 11.7 final: 26th of Aug * Merge conflict: allow choice by chunks and custom fixes - https://jira.xwiki.org/browse/XWIKI-16464 - Simon * Security: not be allowed to set a right you don't have (min) - https://jira.xwiki.org/browse/XWIKI-16266 - Thomas * Async rendering improvements - Thomas * Better handling of user removal and transfer of rights - http://jira.xwiki.org/browse/XWIKI-12142 - Marius (usability) Thanks -Vincent

1 1

[xwiki-devs] [Proposal] Use an attribute whitelist for HtmlCleaner restricted mode
by Simon Urli 26 Jul '19

26 Jul '19

Hi everyone, I'm currently working on improving security on XWiki comments. We already use a restricted mode in our comments but that does not cover every possible case. In order to improve it we should also filter out some part of the html when using the html macro. I propose: (a) that we use a configurable whitelist of HTML attributes that would be allowed in the output HTML: all the other attributes would be filtered out. (b) that the HTML macro is put in restricted mode for users who do not have scripting rights. For (a) I'm hesitating between a whitelist or a blacklist: I assume a blacklist would be shorter but there's also more risk of missing something. On the contrary a configurable whitelist doesn't prevent administrator to accept more than what we give in standard. A first whitelist could be (taken from: https://github.com/xwiki/xwiki-platform/pull/122/files#diff-c33fcb5dca86b15…) alt, class, height, id, name, rel, scope, style, target, title, width Note that href is not included in this list for example. WDYT? Simon -- Simon Urli Software Engineer at XWiki SAS simon.urli(a)xwiki.com More about us at http://www.xwiki.com

5 8