January 2014 - xwiki-devs@xwiki.org

[xwiki-devs] [Contrib] New repository for the "Mocca Calendar" Application
by Clemens Klein-Robbenhaar 24 Jan '14

24 Jan '14

Hi dev's, I would like to create a repository on xwiki-contrib for the "Mocca Calendar" extension: http://extensions.xwiki.org/xwiki/bin/view/Extension/MoccaCalendar The current Git-Repo is at https://github.com/espresto/xwiki-application-moccacalendar (Of course when moving the groupId in the pom.xml will need to be updated, too) I have the following questions: - Looking at the naming conventions I guess instead of "xwiki-application-moccacalendar" the repo should be named "application-moccacalendar", right? - GitHub user "nedgot" (aka Denis Gotthans, who has actually glued the application together) would like to have write access for that repository, too, if possible. I guess have to make him member of xwiki-contrib at large for that to work, right? - As I have heard rumours that is application might have bugs worth reporting ;) could someone please set up a project on jira.xwiki.org for that? I am not sure what the naming conventions are here, maybe "MOCCACAL" might be a good project name, but I will be happy with anything else that I could point bug spotters too. - Denis Gotthans also has an account on the jira, this time "gotthans" for a change. If the project is set up, could someone give him access to edit issues? Best Regards, Clemens

3 3

[xwiki-devs] [Brainstorming] Document's Hidden flag behaviour with translations?
by vincent＠massol.net 24 Jan '14

24 Jan '14

Hi devs, I’m working to fix http://jira.xwiki.org/browse/XWIKI-9910 but before I can fix it we need to decide something since we have 2 possibilities. - Option 1: The hidden flag is set at document translation level which means when the user check the hidden flag it’s only for the current translation - Option 2: The hidden flag is set at the default document level (not set at translated doc level) which means there’s a single hidden flag ATM the problem with XWIKI-9910 is that when the user checks the hidden flag, it’s set at the translation level but when a translation is displayed the value shown is the one from the default document. Option 1 offers more use cases but: - users may be surprised - users need to be careful to edit the default doc if they wish to set the doc as hidden for all translations I’m not sure what option I prefer. Initially I was more for option 2 but I’m now hesitating and leaning more towards option 1. Note that option 2 means one more DB upate when saving a translated doc. WDYT? Thanks -Vincent

7 12

[xwiki-devs] help for communication ajax with script velocity
by le bihan matthieu 23 Jan '14

23 Jan '14

Hello, For a wiki, I 'd use the ajax but I do not see how it works with velocity . Background: In one of my forms I use two metadata "Database List " type. The first is a list of specialties. The second is a list of people. To make a link between the two lists , I defined a person as follows : specialty_name . Example for a person : his specialty : "test" Name: "toto" The value specified in the second list is " test_toto " My need : Whenever the user changes the state of the form of the first list ( specialty ) I would like to use a velocity script that returns me the list of people associated with this specialty. The parameter passed to the velocity script is the name of the specialty. How do I create the velocity script? You just create a new page , is not it ? If not for the script, there must be specific information to indicate that he must retrieve a value and return a list of users. Regards -- View this message in context: http://xwiki.475771.n2.nabble.com/help-for-communication-ajax-with-script-v… Sent from the XWiki- Dev mailing list archive at Nabble.com.

1 1

[xwiki-devs] [ANN] XWiki 5.2.3 released
by vincent＠massol.net 22 Jan '14

22 Jan '14

The XWiki development team is proud to announce the availability of XWiki 5.2.3. This is a bugfix release fixing a security issue allowing unregistered users some access under some circumstances. We recommend anyone using XWiki 5.0+ to upgrade to it, especially if your wiki is a public wiki. 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/ReleaseNotesXWiki523 Thanks -The XWiki dev team

1 0

[xwiki-devs] Delay 5.4RC1
by Thomas Mortagne 21 Jan '14

21 Jan '14

Hi devs, 5.4RC1 is due today but as far as I can see in http://jira.xwiki.org/issues/?jql=fixVersion%20in%20%28%225.4-rc-1%22%29%20… we are quite a bit short on that. I know at least that for XWIKI-9720 and XWIKI-9579 I will need at least several days then there is BFD and ci is not all blue (as always when being close to a release...). We could say it's ok we actually have one more week before final release but I would prefer that Release Candidate to actually be a release candidate for once so I propose to delay all that to 1 week later which would give us: * 5.4RC1: 27th of January 2014 * 5.4: 3rd of Feb 2014 WDYT ? Here is my +1. -- Thomas Mortagne

5 4

[xwiki-devs] debugging sheets applications
by Paul Libbrecht 20 Jan '14

20 Jan '14

Hello fellow developers, we have met a fairly hard bug on www.curriki.org which has almost delayed our release and required a last minute removal of our new discussions feature: the trigger of the sheet application has not been consistent. It has been inconsistent between servers (development, staging, production) and has been inconsistent between syntaxes. For a while I thought that the lack of the class XWiki.ClassSheetBinding was guilty, but adding it did not change anything. I then went through the XWiki core pages and added as much as possible that could have something related… then it started to work on pages in old syntax but failed with newly created pages (which are copies of a template page). Where could I look to debug this? There seems to be *something* applied, since the rendered page is empty and the content is ignored. Thanks for hints. Paul PS: we're now running xwiki 3.5.1

3 5

[xwiki-devs] [VOTE] Allow adding new link/images resource types in XWiki Syntax 2.1 or not
by vincent＠massol.net 16 Jan '14

16 Jan '14

Hi devs, I’ve just committed support for http://jira.xwiki.org/browse/XRENDERING-278 (which allows copy pasting images in the WYSIWYG editor btw). However I’ve just realized (had forgotten) that my code will break image attachments to a subwiki named “data”: image:data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAO9JREFUOE+lUrsNwjAUdCyWIBXjIEokVoCejgkyQ2gYAIkSsQUrUIUxwrund5bjX4OlyPG9u3v22Z2rjM1uWEtpkq//PC/fCs35UoHi/WGL8mTrErVsAJGJHU2KagGzHUi3I8iP+0s1nInXjBSPSfI/n2/vGTNFJZOVCRkYltdGl1FMRqmHYL0FFM6MjnFXaxCwNJMOZAbW6JyVkI1cbwcD3T5MGBjZLQxi8Lw9kp5iFFikUYwZr2dNQzQT7EavsDFOwl2ErNuIh5kgaX1E0bEyMTiZAcA0WAa26GSL7CUaHjJJz1wyqWLpe6gS/yn8AD9tcjFN7/ajAAAAAElFTkSuQmCC Of course the solution for a user is to prefix with “attach:”, to show that it’s an image coming from an attachment: image:attach:data:…. We discussed this previously: * Original thread: http://markmail.org/thread/vw3derowozijqalr * This lead to this first VOTE which was not conclusive: http://markmail.org/thread/vw3derowozijqalr * Which lead to another VOTE which was also not conclusive: http://markmail.org/thread/t2wb2xq7534qsshg (note that this thread contains 2 proposals, the last one beeing a choice between A) and B)). However we kind of agreed at the end that it would be acceptable to break backward compatibility (solution A in the last thread). So the question here: * Should I revert my change that I did for 5.4? * Is it ok to break backward compatibility and thus add this in XWiki Syntax 2.1 as I did and document it on the release notes? Note that I could also relatively easily implement a new rendering configuration option (e.g. rendering.ignoreResourceTypes=user,data) which would be optional and that would allow to ignore some resource types (IMO this is slightly overkill). WDYT? Thanks -Vincent

3 5

[xwiki-devs] Moving xwiki-platform-wiki-manager to contrib
by Guillaume "Louis-Marie" Delhumeau 16 Jan '14

16 Jan '14

Hi. Since I have implemented a REST api for the creation of subwiki using the new wiki API [1], we can remove wiki-manager from platform [2]. But there is a problem: the new implementation has the exact same interface and the same path than the old one, so we can not have both the new api and xwiki-platform-wiki-manager in the classpath anymore. A solution is to release a new version of xwiki-platform-wiki-manager without its own REST api. I see 2 ways to acheive this: 1/ remove the REST api of wiki-manager and remove wiki-manager in 6.0 or 2/ remove wiki-manager in 5.4 and release a new wiki-manager without the REST api in contrib. What do you prefer? Thanks Louis-Marie [1] : http://jira.xwiki.org/browse/XWIKI-9670 [2] : http://jira.xwiki.org/browse/XWIKI-9671

2 2

[xwiki-devs] Rights issue with new Struts action
by Mircea Staicu 16 Jan '14

16 Jan '14

Hello, I am having some issues with a new custom action that I did to solve a platform issue. My work was done a new branch created from the master branch of xwiki on github. I added the new Action class and the form bean to the 'web' module in the xwiki-platform-oldcore @com.xpn.xwiki.web and I mapped the new action in struts-config.xml. I've build the oldcore, followed by the build on the legacy-oldcore, deployed the legacy-oldcore artifact to my local 5.4-SNAPSHOT instance and deployed the struts-config.xml with the new modifications to the WEB-INF/lib. On accessing my action from the wiki, I get the following: You are not allowed to view this document or perform this action. Is there a mapping of the non-default actions and the rights that one must have in order to run them?

3 4

[xwiki-devs] [Reminder] BFD#51
by vincent＠massol.net 16 Jan '14

16 Jan '14

Hi devs, Today is Bug Fixing Day 51! We're currently at -82 bugs for the 1600 days period: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#51 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11993 Let’s crush those nasties! Happy BFD! -Vincent

1 0