xwiki-devs April 2018

xwiki-devs@xwiki.org

11 participants
26 discussions

[xwiki-devs] [Proposal] So which protection to we want by default for extensions pages

by Thomas Mortagne

Hi xwikiers, In 10.3 we introduced a warning to discourage users from editing extension pages (unless the extension indicate it's OK to edit it). This was a first version to have something in 10.3 but the initial (vague) plan (for 10.4 this time) base on previous discussions was: * EDIT right forced false for basic users * still a warning for advanced users * various options to change that (EDIT right forced false for everyone, warning for everyone, etc.) That was before I actually look at what we can do with our security system :) Turns out that it's not a huge fan of dynamic criteria like "basic/advanced user", it's still possible but will require a big of work. Also since ADMIN imply EDIT forbidding basic admin to edit a protected document would not exactly be straightforward. Before starting big stuff I would like to discuss in more details what we want in the end. In this mail I would like to focus on default behavior and we can talk about which options we need to provide in another one: Note: in all of theses superdamin still have the right to edit everything (with a warning). 1) Basic/advanced based 1.a) Forced EDIT right to DENY for basic users. Edit warning for advanced users. Forced EDIT right to DENY for basic admins (we overwrite the ADMIN implied rights logic) 1.b) Forced EDIT right to DENY for basic users. Edit warning for advanced users. Edit warning for admins (they get EDIT trough ADMIN right). 2) Admin right based 2.a) Forced EDIT right to DENY for everyone Even admins 2.b) Forced EDIT right to DENY for everyone Edit warning for admins (they get EDIT trough ADMIN right). 3) Both Warning if you are both advanced user and have ADMIN right Forced EDIT right to DENY for everyone else WDYT ? The initial plan was 1.a in my mind but I'm still hesitating. 2.b is by far the easiest to implement and probably good enough but not sure having ADMIN right is the right criteria to be allowed to force edit of protected pages since it's not about security and more about knowledge. I'm -1 for 2.a) as a default. It's way too harsh for the product (but I can understand it as an option in a cloud offering for example). It's quite young and we will most probably forget to indicate that some pages are OK for edit for a little while, plus there is Contrib extensions which will probably never get configured properly because not really maintained anymore but still used. In term of refactoring/hacking to the current design the most dangerous option is working around the imply link between ADMIN and EDIT rights. The right system was not really designed for basic/advanced criteria use case but it's OK. Thanks, -- Thomas Mortagne

6 years, 7 months

[xwiki-devs] [Proposal] Using JUnit5 from now on?

by Vincent Massol

Hi devs, I’ve recently worked on converting our JUnit4 @Rule rules into JUnit5 equivalent. There are now equivalent for: - MockitoComponentManagerRule, - ComponentManagerRule - AllLogRule - MockitoOldcoreRule See http://dev.xwiki.org/xwiki/bin/view/Community/Testing#HJavaUnitTesting for examples of how to use them. Feel free to ask here if you have questions or if you have ideas on how to better integrate with JUnit5 (I’m sure we’ll need to perform some tuning and there are use cases that I have forgotten that we’ll need to support). I’m thus proposing that from now on, we start writing new tests as JUnit5 tests and that we start converting old JUnit3/4 tests into JUnit5 ones. For example if we need to add a method to a JUnit4 test, we convert it to JUnit5 and then add the new test method. It’s pretty simple to do the conversion. WDYT? Thanks -Vincent

6 years, 7 months

[xwiki-devs] [Proposal] Weblate as XWiki's translation platform

by Adel Atallah

Hello everyone, As you may already know, we have thought about replacing the l10n platform which is becoming too slow. Weblate seems to be a good replacement choice, as it will able contributors to have their name in the commits and it has every features needed to make translations. One problem is that XWiki doesn't use a standard method to process translation files. We can solve that by creating some scripts to convert XWiki translation files into one that Weblate can understand. A detailed solution can be found here : http://design.xwiki.org/xwiki/bin/view/Proposal/WeblateasXWikistranslationp… Feel free to discuss it by responding here or directly in the design page. Thanks, <http://www.xwiki.com/> *Adel Atallah* *Product developer intern* adel.atallah(a)xwiki.com <corina.luong(a)xwiki.com> tel: +33 (0)6 12 96 35 06

6 years, 7 months

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

by Thomas Mortagne

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

6 years, 7 months

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

by Alex Cotiugă

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

6 years, 7 months

[xwiki-devs] [Proposal] Roadmap for XS 10.4, 10.5 & 10.6

by Vincent Massol

Hi devs, Here’s a roadmap proposal for XS 10.4, 10.5 & 10.6 So here’s a proposal which takes into account remaining work + try to go in the directions defined at https://forum.xwiki.org/t/brainstorming-xwiki-10-x-cycle-roadmap/2274 (globally meaning more usability for end users). XS 10.4 ======= * Date: May * Thomas: Finish work for edit protection from 10.3. Specifically ability to prevent editing/moving/deleting extension pages when a confi param is set for that. * Thomas: Register global wiki macro at wiki level when the macro document is in a subwiki - http://jira.xwiki.org/browse/XWIKI-12736 * Thomas: Performance work. Goal: be as good as XWiki 8.4.x. Fix performance issue in XWiki 10.x/Investigate problems with notifications. See for ex https://forum.xwiki.org/t/xwiki-and-tomcat-crashes/2788 but several users have reported issues so there's definitely something really bad happening. * Guillaume: Finish AS replacement + continue fixing Notifications problems * Marius: Improve Navigation panel. Introduce notion of blacklist for the Navigation panel and provide an Admin UI for it. Goal: remove the XWiki space by default using this blacklist (users can be seen in the User Index). Allow users to control better what they have in the panel + control the order. Others: try to improve performance. * Adel: Evaluate and implement weblate for XWiki (replacement for l10n). Note: weblate is moving fast: https://docs.weblate.org/en/latest/changes.html XS 10.5 ======= * Date: June * Thomas: continue work on performance (started in 10.4) * Thomas: Fix inconsistence of WebHome appearing everywhere when using references in macros and API calls. Finish Nested Spaces/Pages work. Page API. * Guillaume: Notifications bugfixes * Marius/Adel: Autocomplete on reference. Note: This would lessen the issue with WebHome. * Example 1: In object editor when the type is "Page Reference" + picker * Example 2: In WYSIWYG macro editor when a macro has a reference parameter + picker * Marius/Adel: Finish Visible Save implementation XS 10.6 ======= * Date: July * Thomas: continue work on performance (started in 10.4) * Thomas: Bug fixes (ongoing) * Guillaume: Notifications bugfixes * Marius/Adel: 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"). * Marius/Adel: Move Menus inside administration (see http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaMenuInAdministration) Let me know if you have any feedback. @Assignees: As always, please create jira issues and update the roadmap page with the jira issues (I’ll update the roadmap page now). Thanks -Vincent

6 years, 8 months

[xwiki-devs] [ANN] XWiki 10.3 released

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki 10.3. In this version you will automatically get notification when change are made to pages you worked on. It also introduce the protection against edition of pages coming from extensions to avoid breaking mistakes and ease upgrades. 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.3 Thanks for your support -The XWiki dev team

6 years, 8 months

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

by Alex Cotiugă

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

6 years, 8 months

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

by Vincent Massol

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." It's not too bad IMO. WDYT? Thanks -Vincent

6 years, 8 months

[xwiki-devs] Skipping XWiki 10.3 Release Candidate 1 and releasing 10.3 Final next week

by Eduard Moraru

Hi, Today was supposed to be the release of 10.3 RC1. However, due to various reasons (the stabilization of the release resulted in reverting the most important part of the work done for this release, missing documentation, etc.) and to avoid spending more time on almost empty releases instead of the features themselves, we have decided that it's best to skip the 10.3 RC1 release and jump directly to 10.3 Final, next week. I will be updating the version on jira as well to remove 10.3 RC1 and move the existing issues to 10.3. Some code changes need to be done as well for the @Since annotations mentioning 10.3RC1 that will have to be switched to 10.3. (will leave that to the devs that added them) Thanks and sorry for the inconvenience, Eduard

6 years, 8 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs April 2018