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

[xwiki-devs] XWiki GSoC Blockly Editor
by Vivek Iyer 05 May '18

05 May '18

Hello all! My name is Vivek Iyer (github and Riot handle: Remorax) and I'm so grateful for being selected as part of GSoC and I'm honestly looking forward to contributing here! My project for the summer is the Google Blockly Editor and to integrate it with the current wiki and WYSIWYG editors. I plan to do this in four stages: - Firstly develop a small extension as test, so that I can build up on it. - The second stage would be actually integrating a basic Blockly editor in XWiki. - The third stage would be adding custom blocks which generate the code for functions which are most commonly used - The fourth and the last stage would be making these blocks output Velocity (or alternatively JS) code which would substitute the contents of the div which would normally contain the manually written code. Ideally, I plan on finishing stages 1 and 2 before the first evaluation, stage 3 before the second evaluation and stage 4 before the final evaluation. As mentioned in my proposal, I'll be on vacation from 10th to 20th May and won't have internet access so I'll be unable to contribute during that period, but I'll surely make up for the lost time later on and get the work done on schedule! I've also kept buffer slots in between in case I run behind schedule. I have also made a design on design.xwiki.org here: http://design.xwiki.org/xwiki/bin/view/Google-Blockly-Editor/ Do check it out and let me know your opinions! That's all from my side. I'm eager for your feedback and happy to receive any suggestions as to where I could improve my current schedule. Thanks and regards, Vivek Iyer

3 4

[xwiki-devs] [Proposal] Improve the Ratings UI
by Alex Cotiugă 04 May '18

04 May '18

Hello devs, While I was trying the Ratings UI in the Iceberg color theme, I noticed that the golden images of the stars might just not fit in any environment. My main issue is that I am not able to change the stars' colors and it's a pain to provide different images to override the existing ones. I was looking for a solution to fit in both Silk(default) and Font Awesome icon themes, using the Icon Service Renderer, but for the Silk's case the issue will be the same since the output would be also represented by images. So I would like to refactor the Ratings UI using the Font Awesome which will provide the needed flexibility in changing the font and colors of the icons. Thanks, Alex

2 1

[xwiki-devs] [XWiki Day] BFD#175
by Alex Cotiugă 04 May '18

04 May '18

Hello devs, This Thursday is BFD#175: 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 # * -96 bugs over 365 days (1 year) * -116 bugs over 500 days (between 1 and 2 years) * -311 bugs over 1600 days (4.3 years) See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#175 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14294 Happy Bug Fixing Day, Alex

1 1

[xwiki-devs] [Proposal] So which protection to we want by default for extensions pages
by Thomas Mortagne 04 May '18

04 May '18

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

5 13

Re: [xwiki-devs] [GSoC] Community Bonding Period ending on 14th of May. PRs needed!
by Eduard Moraru 03 May '18

03 May '18

Hi again, An very important detail that I forgot to remind you (it's mentioned in the Student Guidelines as well) is that you need to be registered to the devs(a)xwiki.org mailing list [1] in order to be able to post messages to it. If you sent the email without being registered, you messages will not reach the list and we will not be able to see them. Thanks, Eduard ---------- [1] http://dev.xwiki.org/xwiki/bin/view/Community/Discuss#HMailingLists On Thu, May 3, 2018 at 2:58 AM, Алексей Овсянников < ovsyannikov.alexey95(a)gmail.com> wrote: > Got it! > > On Thu, May 3, 2018, 00:58 Eduard Moraru <enygma2002(a)gmail.com> wrote: > >> Hello, GSoC students, >> >> As you all know, we are in the middle of the "Community Bonding" period >> of the GSoC 2018 program's timeline [1]. >> >> This is a very important period in which you are supposed to get familiar >> with the XWiki project, read documentation (APIs, processes, development >> practices, etc.), setup tooling and development environments, figure out >> the way the project is organized and what is the best approach for you to >> make an impact. At the end of this period, you should be ready and >> productive to start working on your cool project. (Nobody will complain if >> you have already started ;) ). >> >> Even more so, the community bonding period is about getting to know the >> community and helping the community to know you. So, if you have not yet >> introduced yourself or did not get the chance to exchange some initial >> thoughts with your mentor(s), now is the time to do it. You need to >> remember that GSoC is not a bounty program, but a community building one, >> so the main objective is not simply to deliver, at a certain deadline, a >> feature, but to be integrated in the open source community you have joined >> and help it grow (through your contributions). >> >> As such, on the technical side, your objective for this period is to get >> at least 1 of your Pull Requests (average size/complexity, must contain a >> few lines of code) to get reviewed and accepted either in the main >> repositories (platform/commons/rendering) or in one of the existing Contrib >> extensions. The PR needs to be associated to an existing Jira issue >> (bug/improvement). >> >> Make sure you read and follow the Student Guidelines, specifically the >> section dedicated to accepted students [2]. >> >> >> Reminder1: The deadline is the 14th of May. >> >> Reminder2: The community bonding period is also an eliminatory period. >> Students that choose to stay silent may be considered for elimination from >> the program. >> >> >> Thanks, >> Eduard >> >> ---------- >> [1] https://developers.google.com/open-source/gsoc/timeline >> [2] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines# >> HSuggestedwayofworkingforacceptedGSoCstudents >> >

1 0

[xwiki-devs] [Proposal] Using JUnit5 from now on?
by Vincent Massol 02 May '18

02 May '18

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 5

[xwiki-devs] [GSoC] Community Bonding Period ending on 14th of May. PRs needed!
by Eduard Moraru 02 May '18

02 May '18

Hello, GSoC students, As you all know, we are in the middle of the "Community Bonding" period of the GSoC 2018 program's timeline [1]. This is a very important period in which you are supposed to get familiar with the XWiki project, read documentation (APIs, processes, development practices, etc.), setup tooling and development environments, figure out the way the project is organized and what is the best approach for you to make an impact. At the end of this period, you should be ready and productive to start working on your cool project. (Nobody will complain if you have already started ;) ). Even more so, the community bonding period is about getting to know the community and helping the community to know you. So, if you have not yet introduced yourself or did not get the chance to exchange some initial thoughts with your mentor(s), now is the time to do it. You need to remember that GSoC is not a bounty program, but a community building one, so the main objective is not simply to deliver, at a certain deadline, a feature, but to be integrated in the open source community you have joined and help it grow (through your contributions). As such, on the technical side, your objective for this period is to get at least 1 of your Pull Requests (average size/complexity, must contain a few lines of code) to get reviewed and accepted either in the main repositories (platform/commons/rendering) or in one of the existing Contrib extensions. The PR needs to be associated to an existing Jira issue (bug/improvement). Make sure you read and follow the Student Guidelines, specifically the section dedicated to accepted students [2]. Reminder1: The deadline is the 14th of May. Reminder2: The community bonding period is also an eliminatory period. Students that choose to stay silent may be considered for elimination from the program. Thanks, Eduard ---------- [1] https://developers.google.com/open-source/gsoc/timeline [2] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines#HSuggeste…

1 0

[xwiki-devs] [Brainstorming] Roadmap Application
by Vincent Massol 02 May '18

02 May '18

Hi devs, I’ve started brainstorming about the idea of a Roadmap Application at http://design.xwiki.org/xwiki/bin/view/Proposal/RoadmapApplication Feel free to comment/edit the page there or add your ideas here. Disclaimer: I don’t have any time to work on this ATM ;) Thanks -Vincent

2 1

[xwiki-devs] [Proposal] Weblate as XWiki's translation platform
by Adel Atallah 30 Apr '18

30 Apr '18

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

5 7

[xwiki-devs] [VOTE] Is it OK to edit a standard color theme
by Thomas Mortagne 27 Apr '18

27 Apr '18

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 23