xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] [Brainstorming] What XAR file type for Mail Template pages?

by Vincent Massol

Hi, It seems we forgot to handle mail template pages. For example XWiki.ResetPasswordMailContent We need to decide the type: demo, default, etc. WDYT about demo (i.e. as soon as the user starts modifying it, we don’t upgrade it anymore)? Thanks -Vincent

7 years, 1 month

[xwiki-devs] New extensions for querying XWiki data and generating Charts

by Ludovic Dubost

Hi, I've created a new extension (appwithinminutes-charts) and updated an older one (application-querygenerator). http://extensions.xwiki.org/xwiki/bin/view/Extension/Query%20Generator http://extensions.xwiki.org/xwiki/bin/view/Extension/AppWithin%20Minutes%20… These extensions allow to query XWiki data in a simpler way for non technical users and help create a macro allowing to display a sub-set of XWiki data as well as a chart to count or sum data. The query generator extension in adding to the "querymacro" now includes a "livetable" macro. This livetable extension wraps the velocity #livetable macro in an XWiki macro. The livetable macro is using a modified version of the AppWithinMinute livetable generator. The query macro supports XWQL and HQL queries and displays the data as HTML tables. The chart macro allows to display a 2 columns aggregation as a table and as a chart. The chart package also includes a small UI to generate a chart of a specific AWM application. The query generator is the most complex code as it allows to create an XWQL or HQL query with restrictions on the different field types (string, date, number, list) and also generate the syntax for the livetable, query and chart macros. It is quite useful to generate the right XWQL and HQL syntax based on the restrictions you want to do. It allows to preview the result in the same screen. The chart package includes french and english translation, however the query generator is not translated at all and the code is not very clean. It includes quite some groovy code to generate the UI and includes the XWQL and HQL query generator. 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>

7 years, 1 month

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

by Alex Cotiugă

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

7 years, 1 month

[xwiki-devs] Onboarding feedback

by Adel Atallah

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

7 years, 1 month

[xwiki-devs] [Proposal] Solutions to hide some pages from the navigation panel

by Marius Dumitru Florea

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

7 years, 1 month

[xwiki-devs] Repository request for "application-relations"

by Stéphane Laurière

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

7 years, 1 month

[xwiki-devs] Repository for AppWithinMinutes Charts

by Ludovic Dubost

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>

7 years, 1 month

[xwiki-devs] [NEW API] XAR entry type

by Thomas Mortagne

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

7 years, 1 month

[xwiki-devs] [Vote] Assignee for PR: Contributor or Committer?

by Ecaterina Moraru (Valica)

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

7 years, 1 month

[xwiki-devs] Release new version of the Publication Workflow Application ?

by Clemens Robbenhaar

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

7 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs