xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] [Proposal] Forking jodconverter in the xwiki organization on github

by Vincent Massol

Hi devs, Jodconvert is dead and has been moved to https://github.com/mirkonasato/jodconverter (as its author says: "WARNING! This project is no longer maintained The code has been moved to GitHub in the hope that somebody else will fork and maintain it.") We currently have patches and our sources are in our maven repo at http://maven.xwiki.org/externals/org/artofsolving/jodconverter/jodconverter… I'm proposing to: * fork https://github.com/mirkonasato/jodconverter in our xwiki organization * update the READM to explain why we've forked it * apply our sources from http://maven.xwiki.org/externals/org/artofsolving/jodconverter/jodconverter… on it * work on fixing http://jira.xwiki.org/browse/XWIKI-9380 (this is the real reason I'm proposing all this :)). WDYT? Thanks -Vincent

11 years, 5 months

[xwiki-devs] [Proposal] Who has the right to create a new subwiki/workspace ?

by Guillaume "Louis-Marie" Delhumeau

Since we are integrating Workspaces to XE, I propose to add a new parameter to set who has the right to create a new subwiki. -------------- Proposal A: -------------- We had a new item in the administration menu. This item is used to know what level of right is needed to create a new wiki. Examples: * any user who have the 'edit' rights on the main wiki also has the right to create new wikis * any user who have the 'admin' rights on the main wiki also has the right to create new wikis -------------- Proposal B: -------------- We create a new right (since we can thanks to Denis) called "SubWiki creation right", and this right is needed to create a new subwiki. Then we can add it to XWikiAllGroup or XWikiAdminGroup. -------------- Proposal C: -------------- We create a new group called 'XWikiAllowSubWikiCreationGroup', and everybody who is on this group can create new wikis. ---- WDYT? Thanks, Louis-Marie

11 years, 5 months

Re: [xwiki-devs] How to call a workspace?

by Jean Coury

Hello, Firstly I couldn't read everything because there is a lot of off topics so forgive me if some of the following should not be here. If you have no time go the last line directly. I've been struggling with client with all those terms wich look like the same (e.g. Main wiki, sub-wiki and then Workspace, Space) and the fact that Workspace have "Work" into it and so is not really friendly to the client's users. My first proposal would have been "Portal > Wiki > Space > Page" in order to keep the basics and to find an easy way to describe the main wiki. Then I read multiple threads and have a look to the competitors and find-out that Home as a first term would be great and less technical than Portal. Moreover Portal is full of connotations and do not show the possibility to customize it. "There is no place like Home" don't you think? Proposal : Home > Wiki > Space > Page Then I looked at the proposal made by Cathy on http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImprovem… I would have picked B but I strongly dislike the fact that the product can be two things at a time and so* => I vote for* *D*. Regards, -- Jean Coury

11 years, 5 months

[xwiki-devs] [Contrib] New repository for Task Manager Application

by Sorin Burjan

Hello devs, I'd like to start working on improving the Task Manager Application found at http://extensions.xwiki.org/xwiki/bin/view/Extension/Task+Manager+Applicati… This application is very old and broken, and it does not work on recent XWiki versions. What I want to do is to commit the old code in a separate branch, and redo the application using AWM technologies. Also, I'd need a JIRA component for it with the first version being 2.0. Version 1.0 is the old code. Regards, Sorin B.

11 years, 5 months

[xwiki-devs] [Proposal] Add new API to ModelConfiguration to get the default syntax

by Vincent Massol

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

11 years, 5 months

[xwiki-devs] [Proposal] Integrate both "xwiki.org" and "myxwiki.org" use cases to XE by default in 5.2

by Vincent Massol

Hi devs, I sent a VOTE email not long ago entitled "[VOTE] Integrate Workspaces by default in XWiki's default XAR". So far I didn't get much responses (Vincent +1, Denis +1, Sergiu -0) and the thread was hijacked by Caty, transforming it as a proposal of various implementations while the goal of the mail was just to get an agreement about integration of the workspaces feature in XE in 5.2. Edy commented in https://github.com/xwiki/xwiki-enterprise/pull/38 that he wasn't sure that everyone understood that the idea was to integrate all the subwiki usecases in 5.2 (i.e. myxwiki.org and xwiki.org uses cases, aka farm mode and workspaces mode). Thus with this email I'd like to ensure that we agree to integrate both use cases. IMO integrating only one is just asking for trouble and we need to take into account both use cases to make sure we have something consistent. Is anyone disagreeing? We need an answer on this for Guillaume to progress on https://github.com/xwiki/xwiki-enterprise/pull/38 Thanks -Vincent

11 years, 5 months

[xwiki-devs] [Fun] Is XWiki a fruit-eating or a cake-eating app?

by Vincent Massol

Interesting article: http://seriouspony.com/blog/2013/7/24/your-app-makes-me-fat Not exactly sure what we can make of it, except that it goes in the same direction as the "Don't make me think" book (http://www.amazon.com/Dont-Make-Me-Think-Usability/dp/0321344758), which I recommend too btw. I'd say XWiki is a cake-eating app ;) Thanks -Vincent

11 years, 5 months

[xwiki-devs] [NEW API] New way to remove attachments from XWikiDocument

by Thomas Mortagne

Hi devs, Just a note to indicate that just deprecated XWikiDocument#deleteAttachment methods in favor of the combination of the new method XWikiDocument#removeAttachment and XWiki#saveDocument. This make attachment deletion follow the same behavior as xobject and among other things allow doing all sort of modifications to a XWikiDocument without touching the database until we decide to apply them by saving the document. Thanks, -- Thomas Mortagne

11 years, 5 months

[xwiki-devs] custom struts action rights

by jordiduran

Dear community, I developed a custom action called 'exporttandem', it works well and performs (Java component) a new kind of format export. But this action is allowed by registered users only. Is there any way to open to the rest of users, including unregistered users? Thanks, Jordi Duran -- View this message in context: http://xwiki.475771.n2.nabble.com/custom-struts-action-rights-tp7586458.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

11 years, 5 months

[xwiki-devs] [VOTE] Relax checkstyle rule about javadoc on non-public class members.

by Caleb James DeLisle

Hi, To promote contribution and encourage code brevity, I would like to remove the rule that we fail the build over a missing javadoc on a non-public field. It's important to understand, this is *not* about encouraging developers to skimp on documentation! There are obvious cases such as 'logger' where the role of the field is blatantly clear and forced documentation is at best useless and at worst counterproductive because it creates an information overload for the code reader and hides the comments which the author really wanted to be seen. +1 for dropping this rule Thanks, Caleb

11 years, 5 months

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