xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] Proposal for the new Administration

by Evelina Slatineanu

Hi Guys, I am working on XE-14 (the new Administration UI) http://dev.xwiki.org/xwiki/bin/view/Design/ImproveWikiAdministration . Since the admin templates will be deleted and replaced by an AdminSheet which will be included by default in XwikiPreferences (wiki level) and WebPreferences (space level), I need to create the WebPreferences document for each space, attach an Xwiki.XwikiPreferences object to it and include the AdminSheet. To do that, I need to write some java code in the core . So , here's my proposal: - At xwiki intitialization create all the WebPreferences for the currently existing spaces in the wiki (this should be done for all the wikis, if in a multi-wiki). - Then, use a notification system to create the WebPreferences for any new space in the wiki in one of two ways: a) When calling the "view" action on AnySpace.WebPreferences, check if it exists, if not create it, attach the obj. and include the sheet b) When calling the "save" action on AnySpace.AnyDoc, check if AnySpace.WebPreferences exists, if not, create it etc. I am for the second one, since the 'view' is much more often performed than 'save'. So, my questions: what should I use for the notifications? I found this function in the Stats notification system: // Adding the rule which will allow this module to be called on each page view context.getWiki().getNotificationManager().addGeneralRule( new XWikiActionRule(this, true, true)); But Thomas said the method above registers all types of notifs, not only on page view. There is also: notify(XWikiNotificationRule rule, XWikiDocument doc, String action, XWikiContext context) and I can perform an if(action == "save") to use the notif system for the "save" action. Thomas Mortagne also told me that this notif system is a little bit outdated and would be replaced by the observation component, but I have no idea which I should use. Also, according to the specifs in the draft above, so far I created the Xwiki.AdminSheet, that will display the main categories (General, Presentation, Rights, Users, Groups, Import/Export etc). For each section of this menu I created a sheet (General - > Xwiki.GeneralSheet etc.) in which I can personalize the display. I also created Xwiki.AdminSectionSheet which contains the common code to display the fields necessary from the Xwiki.XwikiPreferences object and this sheet will be included in the sections where is needed (Genera, Presentation etc.) The reason I created separated sheets for each section of the menu (which are fixed as number) is to keep the code clean and allow the possibility to display something else than fields from the xwiki prefs. object (for example for rights, users, groups, import/export). I would really really appreciate some feedback for this 2 proposals. Thanks, Evelina

16 years, 9 months

[xwiki-devs] [VOTE] Convention for packaging naming

by Vincent Massol

Hi, I think it would be a good idea to standardize on package naming. I've seen Jerome's commit for the new invitation manager plugin and this prompted me to send this email. I propose the following: * org.xwiki.<module name>.* : user public APIs * org.xwiki.<module name>.internal.* : non user public classes - This means no "impl" package (which IMO doesn't mean much since it doesn't say if it's public or not). - This also means no "api" package (which IMO is not necessary since it should be the default and makes it more complex to use). - I also don't think we need a "spi" package since we have components. I'm also proposing to generally follow the rules defined here: http://www.eclipse.org/articles/article.php?file=Article-API-Use/index.html (see also http://jakarta.apache.org/cactus/participating/apis.html) Here's my +1 Thanks -Vincent

16 years, 9 months

[xwiki-devs] [vote] Release XE 1.4 RC1

by Thomas Mortagne

hi, I'd like to release XE 1.4RC1 tomorrow. It's the first (and hopping the last) release candidate before XE 1.4 final. See http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise14RC1 for details on changes. Here is my +1 -- Thomas Mortagne

16 years, 9 months

[xwiki-devs] Using the rightsmanager API

by Kamna Jain

Hi, I tried the following script but, I do not get anything displayed on my page wen I save it: [xwiki version: 1.3.2.9174] #set($rightsAPI=$xwiki.rightsmanager) #set($groupsAPI=$rightsAPI.getGroupsAPI()) - (I hope this is right!) #set($list=$groupsAPI.getAllLocalGroupsNames()) - (I do not know if this is working or not...I tried all methods available..Global, Local, normal..) ##set($list=$rightsAPI.getAllGroupsNamesForMember($context.getUser())) - (This works) #set($temp =$xwiki.getUser()) ##$temp #foreach($grp in $list) * [$grp ] #end Nothing displayed on the page...whats the mistake? Thanks

16 years, 9 months

[xwiki-devs] [Proposal] Standardize on Maven 2.0.9 for our build

by Vincent Massol

Hi, Since Maven 2.0.9 is now released and it works with our build we should standardize on it rather than using a"non-official" 2.1 snapshot version. I'm thus proposing to move the maven version we use for Continuum on Maven 2.0.9 and to change the Building page to remove our snapshot version and change the text to say that to build XWiki you need Maven 2.0.9 or greater. WDYT? Thanks -Vincent

16 years, 9 months

[xwiki-devs] [ANN] XWiki Community Farm is now online

by Vincent Massol

Hi everyone, A few months ago we had discussed the possibility of offering a free community-managed farm for non-business critical projects. See http://tinyurl.com/69blgy In short the ideas are: 1) No support guarantee. All support done on the xwiki.org user mailing list by the community. 2) No stability guarantee. We would always install the latest Platform/ XE/XEM version on it and it would serve as a stability test for the xwiki development team. Obviously the community will always try to make it as stable as possible but that's not guaranteed. It's also possible that the farm will be down a few days now and then. We'll try to reduce this but no warranties. 3) There will be several members of the community who'll have admin access on the farm. 4) It will be open to anyone. However the target users will be technical people who can support themselves to some extent. We won't control that but it'll be mentioned on the registration page. In any case points 1) and 2) make it obvious that it shouldn't be used for any business-critical wiki. We're now announcing the myxwiki.org community farm at http://myxwiki.org Note that the machine was donated by the XPertNet company (http://xwiki.com ). Thanks XPertNet! :) Right now the following persons are admin on this farm: * ThomasMortagne * Marta * Sergiu * GuillaumeLerouge * amelentev (Artem) * Jerome Velociter * jvdrean (Jean-Vincent) * VincentMassol Please note that all these people are doing this in their free time and thus we're looking for more admins. If you're interested in helping us manage this farm (and we hope there'll be plenty of you interested) then please register a user and let me know and I'll make you admin. Here's what admins should do: * work on improving the community farm content in general * work on improving the way information is presented and navigation * watch the recent changes and undo graffitis where needed * create wikis for people who request them (there's a HTML form to fill) - we'll need to decide if we want to make that self service or not. Right now I suggest that people interested in getting a wiki there send an email to the xwiki users list explaining what they want to do with their new wiki and then one admin creates it for them. * watch out for security holes * suggest ideas to improve the farm What everyone can do: * edit and improve content for the non admins parts of the farm * spread the word, blog about it, etc Thanks -Vincent on behalf of the XWiki community

16 years, 9 months

[xwiki-devs] [VOTE] Release XWiki Workspaces 1.1M1

by Jerome Velociter

Dear devs, With a little delay already, I would like to release XWiki Workspaces 1.1 Milestone 1 tomorrow, with the following changes : http://tinyurl.com/4slals. (planned roadmap for the 1.1 cycle is here http://workspaces.xwiki.org/xwiki/bin/view/Main/Roadmap#H11) I will too have to release xwiki-plugin-activitystream 1.1 with the following changes : http://tinyurl.com/3s49gk Here is my +1 for all this. Regards, Jerome.

16 years, 9 months

Re: [xwiki-devs] Requesting Commite rights for Niels Mayer

by Niels Mayer

Ludovic: I agree to commit only into the Curriki portions of the trunk. I will await separate permissions/voting to commit into the Xwiki platform portions, should the need arise in the future. For example, I would hope that some "refactoring" of curriki features becomes new core functionality in Xwiki. As I better understand the combined code-base (I just started at curriki) I will be in a better position to understand what such refactoring may entail. At that point, I would be happy to make some proposals and engage in discussion, in case such code reorganization proves mutually beneficial to xwiki and curriki. I am experienced with revision control systems (I was there when subversion<http://svnbook.red-bean.com/en/1.1/ch01s02.html>was being planned, and shaped a number of the features based on collabnet's needs back in the early days of the company when we were developing svn and SourceCast, after our experiences building-in SSL-based 2-factor authentication for cvs&web for http://ipssources.net ). I also fess up to my mistakes when I do make them, e.g.: http://markmail.org/message/2nj5sipyi3qpib4x and also fess up to not having filed a bug report on aforementioned issue ... I admit that sometimes things I like to do with code make it live on the edge-condition, but I'm not one to break the build with it. Thank you for the vote! -- Niels Mayer, http://curriki.org Curriki: The Global Education and Learning Community Ludovic Dubost <ludovic(a)xwiki.org> wrote: +1 with the reminder that Curriki commit access is full commit access but without allowance to commit in the XWiki platform part Joshua Marks wrote: > Dear Devs, > > Niels, who has comment on the list before, is taking on development tasks > for Curriki. As such he will need commit access to SVN. Please cast your > vote to accept this request.

16 years, 9 months

Re: [xwiki-devs] Related to XWIKI-2361 and XWIKI-2362 ( adding users and groups in an empty wiki)

by Sergiu Dumitriu

Evelina Slatineanu wrote: > Hi guys, > > > > I am trying to solve XWIKI-2361 and XWIKI-2362. First was easy but I am > facing the following problem for the second issue: > > > > When trying to add a new user using the UI in an empty wiki, I am being > redirected to /register/ and for that I need register right. Since by > default I have only edit right, it redirects me to /login/ and since is an > empty wiki.you realize it doesn't work. So, wouldn't it be logical to have > register right for an empty wiki (since I have edit right)? If not, could > anyone tell me a solution (I guess I will need to digg deep into the core > for that and I am not sure I'm the best person to do that :P) I am +1 for granting registration rights in an empty wiki. -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 9 months

by Evelina Slatineanu

Hi guys, I am trying to solve XWIKI-2361 and XWIKI-2362. First was easy but I am facing the following problem for the second issue: When trying to add a new user using the UI in an empty wiki, I am being redirected to /register/ and for that I need register right. Since by default I have only edit right, it redirects me to /login/ and since is an empty wiki.you realize it doesn't work. So, wouldn't it be logical to have register right for an empty wiki (since I have edit right)? If not, could anyone tell me a solution (I guess I will need to digg deep into the core for that and I am not sure I'm the best person to do that :P) Thanks in advance, Evelina

16 years, 9 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