April 2013 - xwiki-devs@xwiki.org

[xwiki-devs] [Proposal] Add CLA for contributions + Foundation
by Vincent Massol 27 Aug '13

27 Aug '13

Hi devs, I'd like to propose the following: * That we start asking for a CLA for contributions (and also for current committers) * That we keep the process lightweight in order to not make it harder to contribute to the xwiki project. For this I propose to use http://www.clahub.com/ In order to understand why we need a CLA read: * http://www.oss-watch.ac.uk/resources/cla * http://en.wikipedia.org/wiki/Contributor_License_Agreement If we agree we then need to define our CLA. I think a good starting point could be the Node.js one: http://nodejs.org/cla.html Now I don't think the CLA will have any legal value if we cannot define "the XWiki project" as a legal entity. Thus I believe we need to start by joining some foundation or creating one. I'll list some easy possibilities: * SF Conservancy: http://sfconservancy.org/members/current/ * SPI: http://www.spi-inc.org/projects/ * Create our own Not for profit association Harder possibilities (need to change license, rename project, etc): * Join ASF * Join Eclipse (and be forced to use bugzilla as the issue tracker ;)) We also need to check if OW2 could offer that service of being a legal entity for XWiki. Personally I'm tempted more by our own association (it's quite easy to create one if we don't need to accept money and a bit more complex if we want to accept money but still doable). My second choice goes to SFC. WDYT? Thanks -Vincent

5 8

[xwiki-devs] [Proposal] Add new API to ModelConfiguration to get the default syntax
by Vincent Massol 01 Aug '13

01 Aug '13

Hi, I'd like to add: public interface ModelConfiguration { … Syntax getDefaultSyntax(); } And the configuration key would be: model.defaultSyntax=xwiki/2.1 This also means deprecating CoreConfiguration.getDefaultDocumentSyntax() in oldcore The goal is to have a clean way for getting the default syntax for documents for example without having to use oldcore. I need this to fix http://jira.xwiki.org/browse/XWIKI-9074 for example. WDYT? Thanks -Vincent

4 4

[xwiki-devs] [Idea] XWiki Project Development Flavor
by Vincent Massol 04 Jul '13

04 Jul '13

Hi devs, I've noticed Apache BloodHound (https://issues.apache.org/bloodhound/) and this reminded of this idea I've had several times in the past: Creating a Project Development Flavor of XE. I mentioned it in some other email already but I wanted to see if this excites you as much as it does for me and maybe we could brainstorm in this thread about what it could be like . Some scattered thoughts: * First, from the point of view of the XWiki project I believe it could be a game changer if we did it right since it has the potential of being adopted by projects around the world and thus making them discover xwiki as a result. And since they're developers they would be able to take advantage of XWiki's development features and contribute back to the project through extensions for example. * Ideally it would be awesome that this project be started independently of the XWiki project I think and just use XWiki as the platform since it's a full fledged project with a different goal than the XWiki project itself. * We need to finish the Flavor idea by allowing the DM to list flavors. * Some ideas of content for this Development Project flavor: ** A home page dashboard about metrics of your project. These metrics would be retried from external sources. Examples: *** Statistics about commits using Git/GitHub *** Latest emails (taken from mailman or other mailing list software, possibly by subscribing the project to a mailing list so that it gets the emails) *** Latest issues (taken from JIRA for example) *** Screenshot example: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgProposal2#… ** A Release application to help perform releases ** A forum application, for example the Mail Archive Application done by Jeremie which would need to be improved to add ability to post from it ** A Release notes application ** The Blog application ** Ability to generate a whole PDF for the project's documentation for a given version ** A modern and nice skin (either Lyrebird or the new Skin proposal: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4x) ** A layout configured for the flavor ** Future: a simple issue tracker (or integrate one) for those who want an all-in-one solution. However keep the external issue tracker possibility for those already having an issue tracker ** Some predefined templates for creating well known project pages: source repository, build, hall in fame, project documentation home page, etc ** The IRC Bot application ** Bundle the JIRA macro ** Bundle the FAQ application ** A Roadmap application * Of course we should use this flavor on xwiki.org itself. And we could move some of the modules we currently have in platform and that would make more sense there (jira macro, IRC Bot application, FAQ application, etc). WDYT? Add your ideas to this email thread or, better, on http://dev.xwiki.org/xwiki/bin/view/Design/DevelopmentFlavor Thanks -Vincent

8 16

[xwiki-devs] [Feedback] Activity Stream
by Ecaterina Moraru (Valica) 02 Jul '13

02 Jul '13

Hi, We introduced the Activity Stream macro in XE 2.6 http://extensions.xwiki.org/xwiki/bin/view/Extension/Activity+Macro We are investigating ways to improve our Activity Stream, but in order to do that we would want to know your feedback about it (both from a technology and an user experience pov): - Is Activity Stream a macro you use? - What features you most miss about it? Maybe filtering? Maybe pagination? - Would you like to see more event types, like events generated by applications? - Are you using the "Send Message" functionality? - Other opinions about it. Your feedback will help us improve the macro by adding needed functionality and not breaking used one. I'll gather ideas on http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ActivityStreamFeed… Thanks, Caty

2 4

[xwiki-devs] New version of the Mobile App Code
by Ludovic Dubost 07 Jun '13

07 Jun '13

Hi, I've made some progress on the mobile application code. Here is a demo of the application embedded in a page: http://dev.xwiki.org/xwiki/bin/view/Design/MobileClientDemoV2-201304?view=i… More info about the Mobile app development http://dev.xwiki.org/xwiki/bin/view/Design/MobileClient What's new in this version is a refactoring of the code so that it's easier to write a screen in one block of code. This will help modularization and even will allow screens to be provided by the wiki on which you connect. This will be great to do "custom" experiences in the Mobile application, which is a lot what XWiki is about. Also some additional screens have been implemented: - configuration (which allows to add a wiki and store the config locally) - applications view - search view - improvements to the page view (links are working now, there is an open in safari button) We are getting closer to something releasable. What I believe is still necessary is: - the page list view needs to be improved - the buttons needs to be displayed properly - the page view should get some way to zoom/scroll correctly - the should be a way to paginate or ask for more results Any other comments of what blockers could be to make a v1 release are welcome. Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

3 11

[xwiki-devs] Redirect to a space
by Bruno Amaro Almeida 04 Jun '13

04 Jun '13

Hi How can i redirect the users after login to a space ? I`m looking at login.vm but i have no clue to do this Thanks

4 6

[xwiki-devs] User Directory - Organogram
by Hamster 16 May '13

16 May '13

It is possible to use the XWikiUserClass for an organogram? Example <http://blog.i-love-it.be/useruploads/18/images/organogram_5bi.png> I would love to make an organogram, and populate it with the profile picture and other info (department, phone number, ect) This way, new people in our organisation can just look at the organogram to see who is who! :-) -- View this message in context: http://xwiki.475771.n2.nabble.com/User-Directory-Organogram-tp7584711.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

3 6

[xwiki-devs] [Feedback] Search Requirements
by Ecaterina Moraru (Valica) 14 May '13

14 May '13

Hi, We introduced in XWiki 4.3 a new experimental search based on Apache Solr [A] . Right now our Solr Search [B] is marked as experimental and I don't know how many of you got a chance to play a bit with it. In order for it to become default we need to make sure we are covering the major use cases. So in this mail we should provide some feedback on what is really needed from a relevance, user experience, performance, etc. point of view. I am very interested also in some general feedback on the Lucene Search: major problems you had with it and limitations. The following questions are mostly related to Solr Search: 1) The Solr implementation adds a 'Filtered Search'. Are all filters that are available now needed (wiki, space, type, filetype)? Are we missing some? What is the most important one? Should we have multiple select? >From a technical point of view we could add a lot of things (object properties, query boost, etc.) but I'm more interested, in production, what are some advanced or common use cases of search usage. IMO our Lucene implementation is too simplistic, but it would be a shame to add useless complexity to the Solr one if we really don't need it. On the other hand having a customizable search is a really nice thing. The customization part is kind of complex, but also the most powerful. I want to know how much would we need the ability to explicitly mention the types of results we want vs. excluding things, etc. 2) The Solr search adds a 'Sort' feature. What do you think about that? 3) Search result metadatas: should we display the relevance? What other information should be displayed besides name, location, type? 4) Other mentions. Having a generic search is more complex, than knowing exactly what your search needs to return. We need to make sure we don't add too many niche things while keeping the functionality satisfiable for general use cases. Thanks, Caty --------------- [A] http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki43#HExper… [B] http://extensions.xwiki.org/xwiki/bin/view/Extension/Solr+Search+Application

4 3

[xwiki-devs] [Proposal] Introduce a new API method in order to be able to check an user password
by Thomas Delafosse 13 May '13

13 May '13

Hello all, I've been working on some improvements on user changing password (see XWiki-6882). In particular, I tried to make mandatory, for an user wanting to change his password, to submit also his current password, so that I could check it. The problem is that there is no way to make this check through velocity. I tried to use some groovy instead, but it breaks the functional tests. So I need to introduce a new method "checkPassword" accessible from velocity scripts. The question is, where should I implement it ? There are two possibilities 1) Wrote a new component 2) Add this method in an existing API. I don't really like 1), as I feel it would be strange to introduce a new service with only one method. In the meanwhile, for 2), I don't really know in which API this method could fit. Sergiu told me that I could perhaps put it in com.xpn.xwiki.plugin.rightsmanager.RightsManagerPluginApi, but that it wasn't really good either. Any ideas ? Cheers, Thomas

5 12

[xwiki-devs] [VOTE] New Link and Image syntax for XWiki Syntax 2.2
by Vincent Massol 08 May '13

08 May '13

Hi devs, Following this thread http://markmail.org/thread/vw3derowozijqalr it seems clear that we need to introduce a better syntax for links and images in XWiki Syntax 2.2 (in order to cope with use cases such as http://jira.xwiki.org/jira/browse/XRENDERING-290) The need is to be able to plug new reference type handlers without breaking backward compatibility in XWiki Syntax 2.2 (since right now with XWiki Syntax 2.0 and 2.1 adding a new type reference handler would break backward compatibility). So here are various proposals to that effect for XWiki Syntax 2.2 (I've only kept the interesting proposals from the previous thread). Please vote for the one you prefer or add new solutions if you have other better ideas. Proposal 1 ========= Force XWiki Syntax 2.2 to *ALWAYS* use the full form when creating a link or image, i.e. all links would need to be written: [[label>>type:reference]] Examples: * [[label>>doc:space.page]] * [[label>>doc:wiki:space.page]] * [[label>>path:/some/path]] * [[label>>url:http://xwiki.org]] * [[label>>user:evalica]] * [[image:doc:wiki:[email protected]]] * [[image:icon:someicon.png]] CONS: * Harder to write links to documents which is the main use case Proposal 2 ========= Same as with XWiki Syntax 2.1 but for links or images to subwikis force the user to use the "doc:" notation Examples: * [[label>>space.page]] or [[label>>doc:space.page]] * [[label>>doc:wiki:space.page]] * [[label>>>path:/some/path]] * [[label>>http://xwiki.org]] or [[label>>>url:http://xwiki.org]] * [[label>>user:evalica]] * [[image:doc:wiki:[email protected]]] * [[image:icon:someicon.png]] PRO: * Still easy to reference docs and images in the current wiki * Close to current XWiki Syntax 2.1 CONS: * Harder to write links to documents in subwikis (for workspaces users for example, see example of xwiki.org) Proposal 3 ========= Always define the type as a link or image parameter, i.e. separate subwiki notation from type. Examples: * [[label>>space.page]] or [[label>>space.page||type="doc"]] * [[label>>wiki:space.page]] or [[label>>wiki:space.page||type="doc"]] * [[label>>>/some/path||type="path"]] * [[label>>http://xwiki.org]] or [[label>>>http://xwiki.org||type="url"]] * [[label>>evalica||type="user"]] * [[image:wiki:[email protected]]] or [[image:wiki:[email protected]||type="doc"]] * [[image:someicon.png||type="icon"]] PRO: * Still easy to reference docs * Clear separation between subwiki and types CONS: * Harder to write typed links * Harder to write references in non xwiki/2.x syntax that would not support link parameters Thanks -Vincent

7 22