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

[xwiki-devs] [Proposal] Use JSON in Wiki Components

by Guillaume Delhumeau

Hi devs. In XWiki, we have the ability to create wiki components. It means that each extension can define a custom XClass which is used to create a component when a corresponding XObject exists. Sometimes, this XObject contains a textarea where the developer could write velocity code. The velocity code is rendered, and the result is parsed in order to complete other actions. For example, velocity can render a boolean, or a list of documents, etc... The reason why Velocity is used is because it does not require programming rights. On the other-side, it can only return a string: the rendered content. My use-case is to generate a specific list of users when an event is triggered, to perform some actions with these users. Currently, we have no recommended practice about this "velocity-rendered-fields". That's what I propose to always use JSON when velocity is used to render data in a wiki component. The reason is that JSON is standard and easy to parse. Use case: In the Event Stream module [1], the XClass "XWiki.EventStream.Code.EventClass" is used to trigger custom events when some event occurs. Example: if a DocumentUpdatedEvent is triggered and that event contains an XObject of type "Meeting", you can send a new "Meeting Created" event. There is a "Validation Expression" field used to determine either or not the custom event should be sent. Now I need to add an other field to determine which user should receive the event notifications. For example: if userA and userB have been invited to MeetingC, I need to send an event "Meeting Created" only for user A and user B. Here is my +1, Thanks, [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Event%20Stream%20Modul… -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

7 years, 8 months

2
3
0 0

[xwiki-devs] [Brainstorming] Implementing multi-environment tests - Take 2

by Vincent Massol

Hi devs, I wanted to give you some info on what I’m doing for implementing multi environment testing on XWiki. Initially I thought about this architecture (let’s call it the "running maven inside docker” strategy): http://massol.myxwiki.org/xwiki/bin/view/Blog/DockerJenkinsConfigurationTes… However after more thinking, I think it’s not the best solution. I’m now exploring the “‘running docker inside maven” strategy which works as follows: The generation of the docker image + the start/stop of the docker containers is done by the maven build itself. This has the following advantages: * It’s not dependent on the CI system used * It allows the build to be reproduced locally on dev machines (only prerequisite is to have docker installed - note that right now the prerequisite is to have FF installed locally and we would swap this req. in favor of docker) * We’ll generate the official xwiki docker images as part of our build and not anymore as some external build/steps to execute * The build will be done fully with Maven (no more gradle) FYI, the plugin I’m exploring for this is the fabric8.io one: https://dmp.fabric8.io/#introduction I’ve started the work locally and I’ll commit once I have something ready enough. Let me know if you have some opinion or questions about this. Thanks -Vincent

7 years, 8 months

2
5
0 0

[xwiki-devs] A subtle problem with the Workflow Application and nested pages

by Clemens Robbenhaar

Hi Devs, some users reported a problem to me concerning the Publication Workflow Application and the nested pages feature. The problem is as follows: In their old instance (some 6.4.x) they had a draft space and a public space and workflows attaching each page in the draft space with a page in the public space in an 1:1 manner, like: Draft.WebHome --> Public.WebHome Draft.PageA --> Public.PageA Draft.PageB --> Public.PageB Now if a link in, say, PageA in the Draft space points to another page, e.g. PageB, this is done via a relative link like [[link text>>doc:PageB]] After publishing PageA, the link of the published variant points to the published variant of PageB (and not the variant in the Draft space), which is the desired effect from the users point of view. Now after migration to 9.10 the situation is as follows: Draft.WebHome --> Public.WebHome Draft.PageA.WebHome --> Public.PageA.WebHome Draft.PageB.WebHome --> Public.PageB.WebHome Now a link to PageB in PageA looks like: [[link text>>doc:Draft.PageB.WebHome]] because both pages are no longer in the same space, but each in their own space. Publishing the draft makes the link in the published variant point back to the Draft space, of course. However this is different from the behavior before nested pages and the users experience this as a bug. A manual solution would be to edit all pages and make the links point to the published variant of the pages. However this is not only a cumbersome and error prone task, but also the users are used to the "automatic" link conversion that made links in the published variant point to published pages and are wont to continue setting links to pages in the draft space, expecting them to point to the "right place" after publishing. The fact that now titles are used throughout in the navigation tree, and the titles of the draft and published variant are usually the same and thus indistinguishable complicates the problem even more. To fix this I could write a separate extension that listens to Publish events send from the Workflow extension, and which converts the links in the published variant before it gets saved. However I remember that I once experienced strange issues where the events were sometimes not send to the event listener in question, probably due some class loader issues or the like. (I only experienced these problems in a production instance and was not able to hunt them down in a development instance.) Also I cannot think of a use case where users want to link from a published variant back into the draft space (except for pointing to the draft version of the page itself, which is provided by the panel, however.) Thus I would like to implement the link transformation in the extension itself. If a link in a page points to a page in the draft space of that workflow, I would change that link in the published variant to point to the corresponding published variant of the link target. I could add a checkbox to the workflow class so people can switch of that link transformation if they do not want it. What do you think? Are there any objections to implementing such a feature? Or do you have different ideas how to solve the problem? Best Regards Clemens

7 years, 8 months

4
8
0 0

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

by Alex Cotiugă

Hello devs, This Thursday is BFD#159, the last one for this year: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status is: * -12 bugs over 120 days (4 months), i.e. we need to close 12 bugs to have created bugs # = closed bugs # * -56 bugs over 365 days (1 year) * -53 bugs over 500 days (between 1 and 2 years) * -237 bugs over 1600 days (4.3 years) * -684 bugs since the beginning of XWiki See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#159 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13934 Happy Bug Fixing Day, Alex

7 years, 8 months

1
0
0 0

[xwiki-devs] Next version for 9.x cycle

by Vincent Massol

Hi devs, We need to decide what’s our next version for 9.x. Since 9.11 is supposed to be the last release (actually 9.10 was even supposed to be the last one according to http://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractices… we might need to change that). We still have some stuff to stabilize: notifications, shortcuts, etc. So I’m proposing that the next version be 9.11.1 and not 9.12 to keep the strategy of 12 main releases per year, and to start stabilizing the 9.x cycle. WDYT? Thanks -Vincent

7 years, 8 months

5
7
0 0

[xwiki-devs] [ANN] XWiki 9.11 released

by Marius Dumitru Florea

The XWiki development team is proud to announce the availability of XWiki 9.11. This release brings some final touches to the notifications module by improving the look and feel of the notification center and the notification emails. Some optimizations have also been made in order to speed up the loading time of the notifications tray. 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/9.11 Thanks for your support -The XWiki dev team

7 years, 8 months

2
2
0 0

[xwiki-devs] Will XWiki Activity Stream deprecation affect activitystream_events table?

by ktc

Hi devs, Right now we are building a feature based on XWiki Activity Stream and get data from activitystream_events table from database. We've heard that XWiki will replace Activity Stream with Notification. Does this mean activitystream_events table will be deprecated as well? If it is, do you have any suggestions for replacement like where we can get similar data from database and which application/extension with similar support features that we can rely on? Thanks a lot! -- Sent from: http://xwiki.475771.n2.nabble.com/XWiki-Dev-f475773.html

7 years, 9 months

2
1
0 0

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

by Alex Cotiugă

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

7 years, 9 months

1
1
0 0

[xwiki-devs] [Proposal] Login button for desktop

by Guillaume Delhumeau

Hi Devs, Currently, the login button is inside the drawer menu, which is quite standard on mobile phones. However, on desktop, a lot of people are confused and cannot find how to login/register. I propose to add a login button in the top menu, like this: https://jira.xwiki.org/secure/attachment/34731/Proposition3.png Related JIRA: https://jira.xwiki.org/browse/XWIKI-14881# That could be nice to have it in addition to the current links, for 9.11. Note: we also need to put a "register" link in the login form, so that people can register from there without the need to also add a register button on the top menu (that would be too much IMO). WDYT? Thanks, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

7 years, 9 months

6
12
0 0

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

by Clément Aubin

The XWiki development team is proud to announce the availability of XWiki 9.11-rc-1! This release brings some final touches to the notifications module by improving the look and feel of the notification center and the notification emails. Some optimizations have also been made in order to speed up the loading time of the notifications tray. See the full release notes here: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/9.11RC1/.

7 years, 9 months

1
0
0 0

[xwiki-devs] [Contrib] Request repository for "icon-themes"

by Ecaterina Moraru (Valica)

Hello devs, I want to publish additional IconThemes inside the Contrib organisation. These themes will be complementary to the xwiki-platform-icon [1] module, and in the future we could move deprecated themes from platform there (for example Silk, FA). I will want to contribute IconThemes for Glyphicon (icon-themes-glyphicons) and Material (icon-themes-material) icon sets. I would need: - a repository on xwiki-contrib called "icon-themes" - a JIRA project called "ICONTHEMES" - no e.x.o page yet - username: evalica Let me know if you have any questions. Thanks, Caty [1] https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwi…

7 years, 9 months

2
3
0 0

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

by Alex Cotiugă

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

7 years, 9 months

1
1
0 0

[xwiki-devs] [PROPOSAL] So what do we do about HashCodeBuilder parameters ?

by Thomas Mortagne

Hi devs, Most Object#hashCode() are implemented using HashCodeBuilder. HashCodeBuilder provide an empty constructor and also allow setting "random" numbers. http://dev.xwiki.org/xwiki/bin/view/Community/JavaCodeStyle#HEquals2FHashCo… does not really say anything about what do do and when currently so I would like to have a clear rule about it. On my side when I don't plan to use different types of objects in a hash key I usually simply use the empty HashCodeBuilder constructor. The only point of setting different numbers is when you might end up comparing different object types (and even in that case you have the #equals() safeguard anyway so it's mostly about performances in practice). So here is a proposal: it's OK to use empty HashCodeBuilder constructor except: * when overwriting the hachCode of a super class you should use different numbers than the super class (since there is big chance to have that super class used as a hash key) * as a best effect in general if you know that you are going to have several different types as hash key, try to make sure they use different random numbers, your proc will thank you :) WDYT ? -- Thomas Mortagne

7 years, 9 months

3
3
0 0

[xwiki-devs] Notifications final steps

by Guillaume Delhumeau

Hello devs community, As you know, my main focus this year was on the notifications. My objective has been to replace the Watchlist with the notification emails. Today, we are almost there. The 2 remaining issues are: * https://jira.xwiki.org/browse/XWIKI-14844 (Live emails notifications should be grouped by XWiki pages) and * https://jira.xwiki.org/browse/XWIKI-14891 (Introduce a notifications macro to replace the Watchlist macro) I have updated the design page about this replacement: http://design.xwiki.org/xwiki/bin/view/Proposal/ReplacetheWatchlistbyNotifi… . I am confident that these issues will be implemented for 9.12. Proposition: * we encourage users to enable the notifications on 9.11 and to test it * for 9.12, we enable all notification features by default * for 9.12, we don't bundle the Watchlist in XWiki Standard anymore. What do you think ? Thanks, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

7 years, 9 months

5
5
0 0

[xwiki-devs] [Proposal] Agree on en_US vs en_GB

by Vincent Massol

Hi devs, By default the xwiki core committers maintain an “en” version of all translations and the other languages are left to the community to maintain on l10n.xwiki.org This mail is about deciding if our “en” version is “en_US” or “en_GB”. I propose that we standardize on “en_US”. for example ApplicationResources.properties would correspond to en_US. I also propose that we add en_GB on l10n so that the community could maintain a UK version if they want (it would fall back to en_US when there are no translations, which is a good thing). WDYT? Thanks -Vincent

7 years, 9 months

10
16
0 0

[xwiki-devs] [ANN] XWiki 9.10.1 released

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki 9.10.1. This is a bug fix release that bring corrections for important issues we have discovered since 9.10 has been released. 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/9.10.1 Thanks for your support -The XWiki dev team

7 years, 9 months

1
0
0 0

[xwiki-devs] [Proposal] Roadmap for XWiki 9.11

by Vincent Massol

Hi devs, We’ve just released XWiki 9.10. Let’s now define what we’ll do till the end of the year, i.e. for XWiki 9.11. The proposal is to have 9.11 be mostly a stabilization release. Here’s a proposal: * Finish FS-based attachments but don’t turn it on by default. It’ll be turned on in XWiki 10.0. Thomas already started on this in XWiki 9.10. - Thomas * Protect edition of pages coming from Extensions, in order to try improving upgrades. - Thomas * Polishing of Notifications and performance check/improvemnt (It's very important to disable it and recheck the perf report to compare with 8.4.5 to see if the problem comes from notifs for ex). - Guillaume * Generally, bug fixes/stabilization - All Dates: * 9.11RC1: 11 Dec * 9.11Final: 18 Dec (as a target but could go till end of the year) Note: * Knowing that Guillaume won’t have much during this period, it’s likely that Notifications won’t be polished enough to be marked as production level ready in 9.11 and we’ll probably need a 9.12 or 9.11.1 release in January for that. WDYT? Anything else someone would like to do? As usual please update http://www.xwiki.org/xwiki/bin/view/Roadmaps/ with the detailed list of JIRA tasks for each topic. Thanks -Vincent

7 years, 9 months

2
1
0 0

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

by Alex Cotiugă

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

7 years, 9 months

1
0
0 0

[xwiki-devs] [ANN] XWiki 9.10 released

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki 9.10. This is mostly a release focusing on improving the new Notifications feature, in order to make it as polished and usable as possible before the end of the year (i.e. before the end of the Cycle and before we elect a new LTS release). It also contains several bug fixes. 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/9.10 Thanks for your support -The XWiki dev team

7 years, 9 months

1
0
0 0

[xwiki-devs] [Contrib] New extension request

by Clément Aubin

Hi devs, For the next few months, on my free time, I would like to create an XWiki extension that allows document import using OCR (Optical Character Recognition). I think that I'll be able to create the JIRA project myself, but could someone create the repository for this project on XWiki Contrib ? Here are some usual infos: * Repository name / Application name: `application-ocrimport` * Application description: `Creates Wiki documents from images or scanned PDFs using optical character recognition` * GitHub username: `aubincleme` Please let me know if you need something else. Thanks, Clément

7 years, 9 months

3
3
0 0

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

by Alex Cotiugă

Hello devs, Today is BFD#155: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status is: * -22 bugs over 120 days (4 months), i.e. we need to close 28 bugs to have created bugs # = closed bugs # * -64 bugs over 365 days (1 year) * -45 bugs over 500 days (between 1 and 2 years) * -215 bugs over 1600 days (4.3 years) * -677 bugs since the beginning of XWiki See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#155 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13927 Happy Bug Fixing Day, Alex

7 years, 10 months

2
2
0 0

[xwiki-devs] [ANN] XWiki 9.10RC1 released

by Vincent Massol

The XWiki development team is proud to announce the availability of XWiki 9.10RC1. This is mostly a release focusing on improving the new Notifications feature, in order to make it as polished and usable as possible before the end of the year (i.e. before the end of the Cycle and before we elect a new LTS release). It also contains several bug fixes. 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/9.10RC1/ Thanks for your support -The XWiki dev team

7 years, 10 months

1
0
0 0

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

by Alex Cotiugă

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

7 years, 10 months

1
1
0 0

[xwiki-devs] Extension documents edit protection and Main.WebHome

by Thomas Mortagne

Hi devs, We started to think about https://jira.xwiki.org/browse/XWIKI-14377 with Caty and she noticed that it might not be as simple as "all extensions pages are protected" because there is extensions pages that are almost always supposed to be modified: first example is Main.WebHome which is modified 99% of the time but another good one is Sandbox or Quicklinks panel. So what do we do about it ? I'm not fully sure yet but here are some ideas : 1) So what ? It's still extension pages and you might still have conflicts during next upgrade. If you want standard pages to be modified then generate them during install. 2) Only show the warning when a page is hidden and consider all non hidden pages as OK to modify 3) Explicitly mark each standard page that is OK to be modified with some xobject 3.a) EM XAR handler behave with these pages as it always did 3.b) EM XAR handler has a special support for these pages controlled by one of the xobject fields (skip the document from any merge if there is any customization, always overwrite any customization, etc.) WDYT ? 1) might be too harsh, generating Main.WebHome might be doable (but still a pain to maintain) but it's quite a pain to generate the whole Sandbox space (and not even talking about maintaining it...) 2) we might still want to see some application home pages in the search result and most of them should really not be modified 3.a) will still have the "what should I do" effect sometime for pages that user is allowed to modify 3.b) has my preference right now, sounds like the nicest from user and author point of view, can even be used for other use cases than edit protection control -- Thomas Mortagne

7 years, 10 months

3
7
0 0

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

by Alexandru Cotiuga

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

7 years, 10 months

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