xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

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

by Gabriel Raileanu

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

5 years

[xwiki-devs] [ANN] XWiki 11.6.1 released

by Simon Urli

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

5 years, 1 month

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

by Vincent Massol

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.

5 years, 1 month

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

by Oana-Lavinia Florean

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

5 years, 1 month

[xwiki-devs] [Proposal] Use a standard 3-way merge implementation

by Simon Urli

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

5 years, 1 month

[xwiki-devs] [VOTE] Officially support for Tomcat 9

by Thomas Mortagne

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

5 years, 1 month

[xwiki-devs] [ANN] XWiki 11.6 released

by Alex Cotiugă

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

5 years, 1 month

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

by Oana-Lavinia Florean

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

5 years, 1 month

[xwiki-devs] [Proposal] Roadmap for XS 11.7

by Vincent Massol

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

5 years, 1 month

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

by Simon Urli

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 years, 1 month

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs