xwiki-devs August 2013

xwiki-devs@xwiki.org

32 participants
61 discussions

[xwiki-devs] Bug with global user profile in sub wiki and support for empty servlet path

by Christian Meunier

Hi All, I sent 2 emails to the users list without much success and I am hoping that I might find a more suitable audience for my somewhat technical issues with the devs. 1) Global users in sub wiki. In the system I am trying to setup, all the users are created using a custom auth module in the main wiki (Global users), so there will be no local users. The issue is that on a sub wiki, when you click on a user to bring up its profile, you end up on a document not found. From the auth module, the principal returned is prefixed with the 'XWiki.' so the system should be able to differentiate between local and global users and act accordingly. I checked that I could reproduce the issue even if i am not using any custom authentication. Should i log this as a bug in Jira ? 2) Empty servlet path support The second thing I am struggling with is shortening the urls. I am following this guide: > http://platform.xwiki.org/xwiki/bin/view/Main/ShortURLs But no matter what I try, I cannot make it work without the '/bin/ prefix. Please note that the xwiki is running under Jetty as the main context (mapped as '/') so the url I have is: server.com/WebHome which according to the short urls document should work. it appears that the issue comes from StandardXWikiURLFactory: -------------------- String type = extendedURL.getSegments().get(0); if (type.equals("bin") || type.equals(this.configuration.getWikiPathPrefix())) { xwikiURL = this.entityURLFactory.createURL(extendedURL, parameters); } else { throw new UnsupportedURLException(String.format("URL type [%s] are not yet supported!", type)); } ---------------- So basically for server.com/WebHome, what is happening is that type above equals to "WebHome" and so the condition obviously fails and throws the UnsupportedURLException. Given the above code, I am either forgetting something in the xwiki.cfg or it simply cannot work out of the box... If i were to provide my own custom XWikiUrlFactory, would it solve entirely the issue or some other parts of the system will nevertheless fails because they have the same assumption regarding the presence of the bin or the PathPrefix in the url ? Thanks in advance for your help ! -- Chris

11 years, 4 months

[xwiki-devs] [Reminder] BFD#30

by Marius Dumitru Florea

Hi everyone, Today is BFD 30. Our goal is still to have more bugs closed than created for the past 1300 days! http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 As of now we're 16 bugs behind! Let's close the gap! Here's the BFD#30 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11609 Thanks Marius

11 years, 4 months

[xwiki-devs] [Proposal] Workspace as a Flavor

by Ecaterina Moraru (Valica)

Hi devs, So this is a proposal to have Workspaces as a Flavor and NOT integrated by default. IMO Workspace is a real nice use case and we should definitely promote it. This is how I envision the main homepage (Home) http://incubator.myxwiki.org/xwiki/bin/download/Improvements/WorkspaceHomep… and this is how the homepage of a workspace would look like http://incubator.myxwiki.org/xwiki/bin/download/Improvements/WorkspaceHomep… For more mockups please check the full proposal: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/WorkspaceHomepage The problem is that Workspace Flavor is a use case on it's own and IMO in this particular use case you will not want to have isolated wikis, and plus you will don't want to have lots of the features that are currently by default, so it's really obvious that the Workspace flavor is a specialization of XWiki and will not be anyone's cup of tee. For example, the other Flavors proposed are: - Public Website: you definitely don't need workspaces here - Documentation: same, no need - Application Development: this is intended for development, no need for workspaces See Flavors proposal http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Flavours So Workspaces Flavors is exactly the Groupware Flavor (just I proposed it with another name) http://incubator.myxwiki.org/xwiki/bin/view/Improvements/GroupwareFlavor What I think we should do in 5.2 is indeed have by default the ability to create multiple wikis (so XEM integration, bu without Workspaces). So: - Have 'Add - Wiki' only shown to admins (until we decide otherwise) http://incubator.myxwiki.org/xwiki/bin/download/Improvements/CreateWikiImpr… - Have main wiki homepage defined as 'Home' (using the icon and with a customizable title) - Have a consistent create step for wikis, spaces and pages (in just one step, since Members has sense only for Workspaces) http://incubator.myxwiki.org/xwiki/bin/download/Improvements/CreateWikiImpr… - Integrate Wiki Manager inside Administration (since it's information related to administrator and should not be public as it is now) We could improve the UI by using a livetable http://incubator.myxwiki.org/xwiki/bin/download/Improvements/CreateWikiImpr… All stated above is default functionality that doesn't break backwards compatibility and that is shared between all Flavors. Some base concepts related to Flavors: - Let's consider that what we currently have is a 'Default Flavor' (XE) - We could have a 'Base Flavor' in the future that will consist of 'Default Flavor' minus all the extensions that are not share between all flavors. It will contain just base features and the common denominator for all Flavors. Every time you want to create a new Flavor you could start from this Flavor. - Extra: for test purposes we could also have a 'Full Flavor' containing all the extensions supported by XWiki Development Team. This would be helpful to run the integration tests on it and see if there are possible problems when installing combinations of extensions. Also could serve as a demo flavor of what is possible in XWiki. - There will also be the 'Standard Flavors': Workspaces, Public Website, etc. (proposed and supported by XWiki Development Team) Having this is mind: - Flavors should have the ability to "remove" or alter some pages from the 'Base Flavor' (currently our 'Default Flavor'). For example the Workspace Flavor needs its custom main homepage that list the existing workspace (this doesn't make any sense to any other Flavor). Another example is removing 'Wiki Manager' from 'Default Flavor' and replace it with 'Workspaces Index' that is visible for all users. - Flavors could have their own skin (might need some changed .vm) + preferences (different layout, etc.). In the Workspace Flavor we will want to promote the creation of Workspaces and not Wikis (that is found in the Base Flavor). - Flavors need to integrate other Flavors. For example: 'Workspace Flavor' = 'Base Flavor' + extensions. Also we could have a 'Product Management Flavor' = 'Workspace Flavor' + custom applications installed like: Projects, Deliverables, Meetings, etc. So what we could also do in 5.2 (or 5.3) is: * Flavor definition (from a technical perspective), extensions collections, ability to integrate also pages in the list, etc. * Work separately on the 'Workspace Flavor' which could be our first proposed Flavor (besides the current 'Default Flavor' which is a version of Knowledge Base). This means improving the current 'Workspace Application' with the above proposed Homepages improvements. Let me know what you think, Caty

11 years, 4 months

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs August 2013