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

[xwiki-devs] [Brainstorming] Should we keep the current translation naming rules for class property translations?

by Vincent Massol

Hi devs, Context: I had some quick discussion on this PR () and it led to discussing our current naming rule for class property translations. Right now our rule is: http://dev.xwiki.org/xwiki/bin/view/Community/L10N%20Conventions#HTranslati… I.e. for example: Gardening.Code.GardeningScriptConfigurationClass_activeQueryScripts I see at least 2 problems with this: 1) Problem 1: It’s not consistent with how we name other translations (we use lowercase everywhere and the prefix is the module name, not the space name). For example: gardening.wiki.selectScripts=Sélectionnez les scripts de jardinage actifs gardening.wiki.startJob=Démarrer le jardinage gardening.wiki.start=Jardiner ! gardening.job.success=Terminé ! gardening.job.error=Une erreur est survenue, consultez les journaux pour plus d'information. Gardening.Code.GardeningScriptConfigurationClass_activeQueryScripts=Scripts de requête actifs 2) Problem 2: It’s fragile as it depends on the location of the class. BTW just realizing that we may have broken lots of translations (and still are) when we moved code pages under the Code space… Did we check that? FTR, the LT solves this by offering a translation prefix that can be specified by the dev. WDYT? Do you agree with the problems? Do you see any other problem? Do you have any solution to propose? Note: I’m not suggesting to change this right now but I’d like that we come to an agreement to what we’d like to have in the future. Thanks -Vincent

7 years, 3 months

2
2
0 0

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

by Alex Cotiugă

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

7 years, 3 months

1
0
0 0

[xwiki-devs] [XAR entry type] What about Mail.MailConfig

by Thomas Mortagne

Hi xwikiers, Denis expressed to me some concerns about the type that should be associated to Mail.MailConfig since it contains configuration data. One important issue I see if that this page is primarily an admin configuration UI which happen to also contains configuration data (would have been much cleaner to store the data in a generated document...) so I think the best for now is to keep the default type. Since you are not supposed to go trough edit more to modify those configuration data, the edit protection should not really affect users in practice (no warning when using admin UI). WDYT ? -- Thomas Mortagne

7 years, 4 months

3
5
0 0

[xwiki-devs] GSoC Goals for Improving Dokuwiki importer

by Neha Gupta

Hey everyone, I’m working on improving dokuwiki importer this GSoC and have designed a proposal defining goals according to the current issues and some proposed ideas, for this summer. I’ll be glad if developers can share their views and let me know if you feel something more can be added to it or changed for better. Thanks to Thomas Mortagne and Shubham Jain for mentoring me on this project. You can find the proposal here http://design.xwiki.org/xwiki/bin/view/Improve%20dokuwiki%20Extension/ <http://design.xwiki.org/xwiki/bin/view/Improve%20dokuwiki%20Extension/> Best, Neha

7 years, 4 months

2
1
0 0

[xwiki-devs] [GSOC] Coding period has started

by Eduard Moraru

Hello to our GSoC 2018 students, The GSoC 2018 coding period has officially started. I hope you have taken advantage of the bonding period to get up to speed with the XWiki project, its code and documentation, and that you have a pretty good idea of what you need to do to turn your project into a success. As for tips and things that you need to do in the following (coding) period, please make sure you read carefully the these 2 dedicated sections [1][2] in the student guidelines [3], particularly: * keeping your progress report page up to date [4] * creating your design page as instructed [5] * making your contribution to the XWiki project (pull request) Working on your project is great, but it`s only half of the work that GSoC involves. The other half is integrating into the community, letting people know what your are working on, asking for help and learning to ask the right questions, and generally communicating about yourself and your work. In order to keep in touch, additionally to reading and being active on the mailing list, you also need to be present on IRC as much as possible (at least while you are working on your project) so that: * people see you and can quickly get a hold of you * you are exposed to everyday community activity that might spark your interest * get more occasions to ask questions * get more occasions to help others with their problems should you know the answer * etc. Hope you are finding XWiki to be an interesting project and that you are enjoying your GSoC so far. -The XWiki Development Team ---------- [1] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines#HSuggeste… [2] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines#HConditio… [3] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines [4] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/DocumentingStudentPr… [5] http://design.xwiki.org/

7 years, 4 months

1
0
0 0

[xwiki-devs] [ANN] XWiki 10.4 Release Candidate 1 Released

by Ecaterina Moraru (Valica)

The XWiki development team is proud to announce the availability of XWiki 10.4-rc-1. In this version we've improved the Navigation panel by allowing pages to be excluded from the listing. We've added a new macro for Notifications that allows it to be embedded in other pages. We've also improved the History's Changes view by providing more navigation options between versions. We've continued to tweak the edit protection, added in the previous version, for some default extension pages (like Skin, Color Themes, Dashboard, Sandbox, etc.). 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.4RC1/ Thanks for your support -The XWiki dev team

7 years, 4 months

1
0
0 0

[xwiki-devs] Clover TPC evolution

by Vincent Massol

Hi devs, I’ve recomputed the global Clover TPC by excluding all tests from the result and found the following results: * 2012-07-02: 62.21% * 2016-12-20: 65.29% => +3.08% * 2017-11-09: 68.59% => +3.3% * 2018-04-03: 68.34% => -0.25% * 2018-05-11: 68.77% => +0.43% So: * From mid 2012 to end of 2016 (4.5 years) => +3.08% * From 2016 to 2017 (11 months, almost 1 year) => +3.3% ** Big increase compared to before where it took 4.5 years to get a similar results * From 2017 to 2018 (6 months) => +0.18% ** We’re doing quite bad in 2018 so far. My next step is to find out the biggest offenders by sorting the packages having lost the most TPC while having the most covered elements (a package with one class that goes from 80% to 50% is less important than a package with 10 classes going from 80% to 70%). Thanks -Vincent

7 years, 4 months

2
1
0 0

[xwiki-devs] Fwd: Get started with XWiki

by Vincent Massol

Hi devs, here’s a feedback we received, FYI. Ideas? Thanks -Vincent > Begin forwarded message: > > From: Vincent Massol > Subject: Re: Get started with XWiki > Date: 14 May 2018 at 09:10:06 CEST > To: XXX > Cc: XXX > > Hi Christian, > >> On 12 May 2018, at 14:25, Christian XXX wrote: >> >> It's not working. >> >> And as usual ith java, the log does not help. Maybe if I were an expert? But an app is supposed to be installed by just 'smart' users, not experts. > > If you choose the easy installation methods we propose then it’s easy and you have nothing to do. > > Which distribution did you choose and use? > >> And there is no help from the website. >> >> Oracle Linux 7. >> Linux localhost.localdomain 4.1.12-124.14.5.el7uek.x86_64 #2 SMP Fri May 4 15:26:53 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux >> Java 10 >> Xwiki 10.3 >> tomcat. >> >> If it is not compatible whith this java. It should not install. > > It’s just not been tested with Java 10 yet. It’s not even fully working with Java 9. > > Note that it’s hard to check for the java version for all the distributions since XWiki is a webapp and the XWiki WAR can just be dropped in a servlet container and thus we don’t have a startup script and a place where we can put a check. All we could do is have a Servlet Listener that would emit a big stack trace (like the one you got) and that would say at the innermost level that XWiki requires Java <= 8. But even that wouldn’t be good since it would prevent testing in Java 9+. We want feedback from users about what works/what doesn’t work so improve support for Java 9 and 10. > >> If it is compatible with only one version of java, which one? > > You need to read the installation page ;) > > See http://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/ and especially: > http://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/#… > >> Here is the error: >> >> >> Error number 4001 in 4: Error while evaluating velocity template colorThemeInit.vm >> Error number 4001 in 4: Error while evaluating velocity template colorThemeInit.vm >> com.xpn.xwiki.XWikiException: Error number 4001 in 4: Error while evaluating velocity template colorThemeInit.vm > > [snip] > >> Caused by: java.lang.IllegalStateException: No standard field found for reverse order comparator! >> at org.jboss.marshalling.river.Protocol.<clinit>(Protocol.java:276) >> ... 249 mor > > [snip > >> Caused by: java.lang.IllegalStateException: No standard field found for reverse order comparator! >> at org.jboss.marshalling.river.Protocol.<clinit>(Protocol.java:276) >> ... 249 mor > > What this says is that JBoss Infinispan (which we use) is not compatible with Java 10. Apparently this is fixed in recent version of JBoss Marshalling: https://issues.jboss.org/browse/JBMAR-216. We probably just need to wait for JBoss Infinispan to release a new version that uses JBoss Marshalling 2.1.0.Final. > > What would be awesome would be for you to report the problem of using XWiki with Java 10 on https://jira.xwiki.org so that we can have an issue for it and work to make it work. > > Note that I’m replying to this message to help you out but it’s not the right place to post a question and get help normally. For that we have a user forum at https://forum.xwiki.org/. > > I’m sorry you had some issues. OTOH you’re looking for trouble by trying with Java 10. There are very few (if any!) java app that currently work with Java 9 and 10. You’d be much better off using Java 8. On the positive side, if you raise the issue on https://jira.xwiki.org, then you will transform your negative experience into a positive one, by contributing to the development of XWiki and helping out future users. > > Thanks > -Vincent Massol [snip]

7 years, 4 months

3
12
0 0

[xwiki-devs] [Proposal] Improve our Test Coverage strategy

by Vincent Massol

Hi devs, Our current Test coverage strategy is to fail the build when new code added results in a coverage lower than the threshold for the module, using jacoco. This has 2 limitations causing our global TPC to go down from time to time (see https://markmail.org/message/hqumkdiz7jm76ya6 ). Thus I’d like to propose the following addition to our strategy: * We already have a jenkins pipeline to automatically compute the full TPC using Clover. See http://dev.xwiki.org/xwiki/bin/view/Community/Testing#HUsingClover2BJenkins * Make it run more often (it’s currently executed once per month, see http://ci.xwiki.org/view/Tools/job/Clover/). Takes about 5-6 hours to execute. Thus we could run it once per week or even once per day during the night. * Add some groovy logic in the pipeline to perform an analysis after the Clover report has been generated. Perform 2 checks by comparing the previous report with the one that just executed: ** Find new packages introduced that have a TPC < the average computed TPC ** Find packages and/or files having a TPC lower than the previous TPC ** Find removed packages that had a TPC higher than the average computed TPC * Save a report in the directory for the Clover report at http://ci.xwiki.org/view/Tools/job/Clover/ * For all failures, send an email to notifications(a)xwiki.org with details and a link to the saved report * Ideally, and if we can do it, call the github API to find the authors of commits for those packages and add them in the report. Examples of APIs we could use: ** https://api.github.com/repos/xwiki/xwiki-platform/commits?since=2018-05-07T… (there’s a path parameter that could be used to filter but I don’t think it’ll work ** https://github.com/xwiki/xwiki-platform/compare/master@%7B2018-05-07%7D...m… (the committers/authors need to be extracted from the HTML which is a bit fragile) * Add a step in the Release process to ensure that the global TPC has not been lowered. This would be a way to ensure we pay attention to that and fix it when we lower it. We would need to tune this to find something that helps keep the TPC increasing while not putting too much pressure at the same time on the release date. It doesn’t have to be in the release process but we need some checkpoint to make sure we look at it and that all devs fix the tests when they lower the global TPC, or at the very least that an analysis is done in case where it’s hard to keep the TPC (for example, removing existing code that had a lot of tests will lower the TPC ;)). WDYT? As a dev, would you be willing to pay attention to not lower the global TPC and work to fix it when it happens? Thanks -Vincent

7 years, 4 months

3
8
0 0

[xwiki-devs] [Proposal] New extension point: content header

by Stéphane Laurière

Hi all, I'd like to propose a new UI extension point: content header (or before content). My current motivation for it relates to the page-relations application that will display the pages related to the current one: it can be handy to have the relations displayed in the content header for navigation purpose (even though other areas in the UI would make sense, such as a dedicated navigation panel). Other usages I have in mind: display content licensing information, content warning, display that the page is currently not editable as the wiki is read only, let the user choose between displaying tags before or after content... Note that Caty already proposed an extension point for the customizing the content footer: http://jira.xwiki.org/browse/XWIKI-13081 I created the following issue: https://jira.xwiki.org/browse/XWIKI-15252 What do you think? Cheers Stéphane -- Stéphane Laurière XWiki www.xwiki.com @slauriere

7 years, 4 months

6
6
0 0

[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, 4 months

4
10
0 0

[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, 4 months

2
1
0 0

[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, 4 months

1
1
0 0

[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, 4 months

6
6
0 0

[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, 4 months

6
20
0 0

[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, 4 months

3
5
0 0

[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, 4 months

2
2
0 0

[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, 4 months

4
12
0 0

[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, 4 months

9
11
0 0

[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, 4 months

3
2
0 0

[xwiki-devs] XWiki GSoC Blockly Editor

by Vivek Iyer

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

7 years, 4 months

3
4
0 0

[xwiki-devs] [Proposal] Improve the Ratings UI

by Alex Cotiugă

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

7 years, 4 months

2
1
0 0

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

by Alex Cotiugă

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

7 years, 4 months

1
1
0 0

[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

7 years, 4 months

5
13
0 0

Re: [xwiki-devs] [GSoC] Community Bonding Period ending on 14th of May. PRs needed!

by Eduard Moraru

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 >> >

7 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs