May 2018 - xwiki-devs@xwiki.org

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

11 May '18

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

1 1

[xwiki-devs] Onboarding feedback
by Adel Atallah 11 May '18

11 May '18

Hello everyone, I've been following the onboarding tracks 1 and 2 on the past days, here is what I can say: The first track really helped me to get started in XWiki contributions as I could easily pick a jira issue to work on. The issue description was clear even though we had to discuss it on the chat. Speaking of the chat, it has been a very valuable tool, people have been very responsive and I was rarely stuck. I found the development practice a bit inconvenient at first, having to make changes in the vm files of my XWiki instance and then report the changes to the sources. I would have love to see a way to link my source files (especially for vm/js/css files) with the one of my XWiki instance to avoid errors when I copy past my changes (and get benefit of my git ecosystem). The second track is a good introduction to some XWiki concepts, I don't have much to say for this one. A link to a real application could maybe give a better understanding. Thanks again for the help I had! <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 6

[xwiki-devs] [Proposal] Solutions to hide some pages from the navigation panel
by Marius Dumitru Florea 09 May '18

09 May '18

Hi devs, Some users have complained that the navigation panel shows top level pages that they don't need/want to navigate to, most importantly the XWiki page. There are multiple ways in which we can fix this. Solution 1: Content Page Create a top level "Content" page for user content and configure the navigation panel to show the contents of this page. Pros: * Namespace isolation (no conflicts between user pages and application pages) Cons: * The user may want to navigate to a top level application page (although it's better to use the application panel for this instead) * All the paths / references used to access the user content will start with this "Content" page Solution 2: Blacklisting Add support for specifying a list of (top level) pages to exclude from the navigation panel. Pros: * The user (top level) pages created later on will be visible in the navigation panel * The blacklist could be used to filter not only top level pages but also any nested page from the navigation panel. Cons: * The blacklist depends on the installed apps. The administrator may have to update the blacklist when new applications are installed * The blacklist depends on whether you view hidden pages or not. If you don't view hidden pages then the blacklist probably contains 4 pages: Help, Menu, Sandbox, XWiki (there is an application panel entry for each of them except XWiki), which is manageable. If you view hidden pages then you need to black list 28+ pages which is hard to manage and maintain. * The filtering needs to happen on the database (otherwise we break the pagination) so the database queries will become a bit more complex, which could led to some performance penalty, depending on how long the blacklist is. Solution 3: Whitelisting Add support for controlling the list of top level pages that are displayed in the navigation panel. Pros: * the whitelist doesn't depend on the installed extensions or hidden pages so it's easier to maintain. * the whitelist can be used to order the top level pages visible in the navigation panel. * the whitelist can be used to show at the top level (for navigation purpose) a page that is not really a top level page * No performance penalty Cons: * The user (top level) pages created later on will not be visible in the navigation panel. The administrator will have to add them to the whitelist if they are useful for the navigation. Although creating top level pages should happen less often than creating nested pages under the existing top level pages. * the whitelist controls only the first level in the tree. The next levels will be dynamic (database queries) and with the default order. Solution 4: Exclude extension pages Exclude from the navigation panel the top level pages that belong to an installed extension, allowing the administrator to make some exceptions (e.g. keep the home page). The rationale is that if an installed extension has a top level page then that page is most probably the application home page which should be accessible from the application panel. This can be implemented on top of solution 3 (the whitelist is basically dynamic: we collect the top level pages that don't belong to an extension). Pros: * It does a clear separation between applications (accessible from the application panel) and content (accessible from the navigation panel). The navigation panel is currently mixing application pages and (user) content pages. * The administrator doesn't need to update the navigation panel configuration to exclude a top level application home page each time an application is installed * The hidden top level extension code pages are not shown even when "show hidden pages" is set to true * The user top level pages created later on appear in the tree automatically Cons: * The user won't be able to navigate easily to an application home page: ** if the application panel is not shown ** or if the application doesn't provide an application panel entry ** or if the administrator has removed the entry from the application panel I prefer solution 4. WDYT? Thanks, Marius

6 20

[xwiki-devs] Repository request for "application-relations"
by Stéphane Laurière 07 May '18

07 May '18

Hi all, I'd like to request a repository for a new application allowing to create relations between pages and to show direct / inverse relations. It's similar to the use of links / backlinks except that in the case of this application, the links to other pages can be added as objects rather than in the content itself. Also, in the future, we may consider the option to name each relation, so as to have something similar to what RDF proposes. Here's the name of the repository I would like to request, if you agree: "application-relations". I saw there was an issue with the JIRA contrib project template plugin, there's no need for a JIRA project right now. Thanks a lot, Stéphane -- Stéphane Laurière XWiki www.xwiki.com +33 645 816 202 @slauriere

3 5

[xwiki-devs] Repository for AppWithinMinutes Charts
by Ludovic Dubost 07 May '18

07 May '18

Hi, I would like to publish an extension to add charts and statistics to AppWithinMinutes. Could I have the repo appwithinminutes-charts Thanks Ludovic -- *Ludovic Dubost* *Founder and CEO* ludovic(a)xwiki.com skype: ldubost Blog: http://blog.ludovic.orgTry XWiki on the cloud <http://www.xwiki.com/en/products/try-xwiki-cloud> - Try Cryptpad: Secure realtime Wysiwyg Editing <https://cryptpad.fr>

2 2

[xwiki-devs] [NEW API] XAR entry type
by Thomas Mortagne 07 May '18

07 May '18

Hi devs, When dealing with extension pages protection we ended up with a very visible issue: EVERYONE customize the home page so it does not make much sense to warn every user trying to edit it that it's dangerous and might break the extensions. Since it's not the only use case 10.3 introduce the concept of XAR entry type which allow controlling a bit more edit/delete and upgrade behavior. See http://extensions.xwiki.org/xwiki/bin/view/Extension/XAR+Module+Specificati… for more details. On component side it's possible to decide the default type of a page reference (that's where "Main.WebHome" type come from currently). It's also possible to override the upgrade behavior for a specific type or even a specific reference for more exotic use cases. So it's now possible to control the type you want for a page at XAR descriptor level. I already typed a few page, for example "Main.WebHome" is now of type "home" which means "it's OK to edit it and you should only upgrade it if no customization have been made". Cool home page is covered but we now entered a new era of endless debates to decide of what type some page should be and what other types to introduce :) We are not going to discuss all these in this mail so everyone with a doubt should start a discussion for a standard page (or a set of standard page which are obviously very similar like color themes). Currently, protected page produce a warning that you can force. The plan in 10.4 is to keep the warning only for advanced completely prevent basic user to modify protected pages by default and also allow configuring all that (indicate in your profile that you don't want to be bothered with that, override edit/delete right even for advanced users, etc.). But before that we need to make sure basic users are allowed to edit all the pages they are supposed to edit. Happy tuning :) -- Thomas Mortagne

4 12

[xwiki-devs] [Vote] Assignee for PR: Contributor or Committer?
by Ecaterina Moraru (Valica) 07 May '18

07 May '18

Hi, We have discussed this subject multiple times, but we don't have an official vote and conclusion on the topic. Problem: In JIRA who is the Assignee of an issue fixed by a Pull Request? 1: Contributor - he provided the solution - giving the attributions, the contributor might feel encouraged to contribute more - we could do some JIRA statistics on external contributions, but this use case can be covered by GitHub statistics 2: Committer - he does the merging on his account and he becomes responsible for the committed code. - in case there are problems, the committer needs to find solution, since we can't rely on contributors availability - in doing the PR review, the committer spends a lot of time analyzing and testing the provided solution We are talking here about complete solutions provided by the PR, since in case of partial solutions, the committer can assign himself on the issue (depends on the quantity of modification he does). Let me know what you think, Caty

9 11

[xwiki-devs] Release new version of the Publication Workflow Application ?
by Clemens Robbenhaar 07 May '18

07 May '18

Hi devs, Hi Anca Luca especially :) I have been working on some issues with the Publication Workflow Application lately (on a branch called XAWORKFLOW-37 ... which ended up containing several other fixes, too.) I'd like to merge these fixes into the master and make a new release 1.9 soon, preferably near the end of the next week. The list of fixes so far are in this list: https://jira.xwiki.org/browse/XAWORKFLOW-20?jql=project%20%3D%20XAWORKFLOW%… Also this will raise the required XWiki version to 7.2, mainly as I did not want to test if it still works with a pre-"nested pages" XWiki :-/ Any objections? Or anyone sees the need and want to do a code review? I am still in the process of testing if everything works with the latest XWiki version (I had developed it against an old 8.0-instance that I had lying around). I know a few folks who will test the release and I am prepared to shoot out a 1.8.1 in case I seriously goofed up something. ;) Thanks, Clemens

3 2

[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