- xwiki-users@xwiki.org - lists.xwiki.org

Re: [xwiki-users] Workspace manager, WYSIWYG editor + 3-rd "new idea"

by Haru Mamburu

Hi, All, As we have now workspaces in addition to virtual spaces, it looks logic to provide following scenario in UI of WYSIWYG editor: select virtual wiki/workspace -> Space -> Page -> Anchor It would help much in multiworkspace environment. Is it difficult to implement? Please, vote if it looks useful for you at http://jira.xwiki.org/browse/XEM-209 Kind Regards, Dmitry 01 февраля 2012, 15:36 от Eduard Moraru <enygma2002(a)gmail.com>: > Hi Dmitry, > > I understand your concerns about programming rights. It has been and it > still is a subject of debate. > > However, please note that you do not need programming rights to do velocity > scripting inside XWiki (whether it is on the main wiki or on a subwiki). > You need PR only for groovy scripting (since it has access to the core java > layer) and for some velocity methods that request access to the same core > java layer that you should normally not need to access. Even so, there are > rare times when you want to do some complex stuff that *really* needs > groovy or privileged velocity APIs, so you can not completely escape the > need of PR. > > I`m not sure the PR wiki-level encapsulation you desire is easy to perform, > since PR (as they are currently defined) are too powerful to be contained > inside a wiki and generally tend to have access to everything. The current > PR would need serious rethinking and maybe redefinition in order to obtain > that, but it's good to have this encapsulation in consideration when it > will come to that. > > My 2 cents on the issue :) > > Thanks, > Eduard > > On Wed, Feb 1, 2012 at 8:42 AM, Haru Mamburu <haru_mamburu(a)mail.ru> wrote: > > > Hi, Eduard, > > > > Sorry to be unclear first time. > > > > Let's end it up: > > > > E.g. I set up my workspace AND I need to do some scripting on it. If I got > > everything right, looks not possible without GLOBAL programming rights. > > Programming rights actually should work even without admin rights. For now > > we have no tool to "encapsulate" programming rights of user with > > programming rights niether inside his own workspace (as a global user), nor > > inside virtual wiki. > > > > "Ideal XWiki world" runs everything independently. It's how I understand > > words "platform" and "engine". > > > > So, this "encapsulation" engine is another "new feature request". I'd like > > to ask. Is it easy to implement? > > > > Finally: > > http://jira.xwiki.org/browse/XEM-207 - second level of virtualization > > http://jira.xwiki.org/browse/XEM-208 - programming rights incapsulation > > inside workspaces and virtual wikis > > > > Hope, it helps. > > > > Kind Regards. > > > > Dmitry > > > > > > 30 января 2012, 18:21 от Eduard Moraru <enygma2002(a)gmail.com>: > > > > > > Hi Dmitry, > > > > I`m not sure I fully understand your proposal or concerns. > > > > 1. You are saying that global admins are dangerous because they can get > > programming rights and kill everything. > > > > They don`t need programming rights to kill everything if they have global > > admin rights :) They just use the UI to delete everything. Also, I don`t > > think XWiki`s scope is to protect you from yourself or from your trusted > > people. If you assign global admin rights to someone, you`d better do it > > carefully. The same goes with every collaborative system. > > > > 2. You are describing a usecase where only subwikis/workspaces are > > launched in production and that the main wiki is restricted to regular > > users, in an attempt to avoid global admins. > > > > Well... sure, but how is this different from you being the only main wiki > > admin and the other users to be only subwiki admins (at best)? I`m not sure > > it's ok to impose such a usecase to users instead of applying it only when > > needed. Workspaces is already designed to fulfil this usecase by not > > assigning any main wiki admins. It allows global users to create their own > > workspaces (subwikis) and play as they wish inside them, no programming > > rights or global admins involved. > > > > 3. I`m not sure I understand the proposed "flexible solution". > > > > If by "virtual wiki 2 -> workspaces -> workspaces (probably)" you mean to > > allow subwikis to be created inside subwikis, then this, indeed is the "new > > feature request" that I was referring to when suggesting that you create a > > new jira. The idea is more general than your particular use case and can be > > applied to various usecases. > > > > Though I still think that one level of virtualization is enough for XWiki > > (as things are working right now), I accept the idea that some people might > > need more complex scenarios. > > > > Thanks, > > Eduard > > > > > > On Sat, Jan 28, 2012 at 7:41 PM, Haru Mamburu <haru_mamburu(a)mail.ru> > > wrote: > > Hi Eduard, > > > > Thanks for explnation. I'm very happy to issue a "new idea", but idea > > itself is a bit wider and deeper, then described below. I would like to > > point out some reasons and effects to be more clear before "jiraing" it :-) > > > > "Security leak" XE/XEM Usecase > > > > XE/XEM + Workspace Manager. One main Wiki and let's say, hundreds of > > workspaces. To be more real we'd add Wiki Manager and tens of virtual wikis > > running on the same engine (something like XWiki.com running) > > > > As my humble experience shows, nearly never in natural way XWiki would > > have only one User with Admin Rights on the Wiki level. > > It's human to be all the time in a hurry and meanwhile XWiki becomes messy > > inside. It's not the big problem yet. :-) > > > > As an Admin User on wiki level, I can easily gain programming rights. For > > now, it's completely uncontrolled and will run unnoticed. > > > > So, let's imagine that all stars in solar system lined up in a bad way and > > one Admin became an AngryAdmin with a revenge as a primary goal of life. > > Let's make it even worth: AngryAdmin knows XWiki quite good and scripting > > for him is an open book. To make it more real: AngryAdmin doesn't have root > > access to the server. :-) > > > > At this stage he has all necessary knowledge and access rights to ruin ALL > > WIKIs onboard. I didn't dig much in it, but if Workspace Manager has > > appropriate tools, then it's possible: one short script and it's over :-) > > > > I didn't met such occasions before, but heard a lot of similar usecases > > (not with XWiki :-) > > > > Thus, I NEVER run production on MAIN wiki! > > > > It looks dangerous for me. I'd better be paranoic admin rather embarrased > > admin. If somebody will become an "angry-beaver-admin", he would be able to > > ruin only one space (now he has a front-end tool for this :-)) or more, but > > only inside one project and all running wikis will stay alive. Such > > workflow keeps my paranoia quiet :-) > > > > SO, at last "new idea": escape MAIN WIKI from production completely. > > > > As only global users has programming rights, it looks very logic to leave > > Main Wiki to "Core and instances" management and keep it safe from local > > admins. When U have a lot of users it sounds reasonable for me. > > > > Let's return to our Case 1-3 described below. The most flexible solution > > looks as following: > > > > | virtual wiki 1 -> workspaces > > | virtual wiki 2 -> workspaces -> workspaces > > (probably) > > Main Wiki | > > .................................................. > > | virtual wiki N - "Solo" - No Workspace > > Manager onboard > > (administration) (production) > > > > Such a way we can run everything simultaneously on the same server. No > > need to run a lot of instances. > > If someone want's programming rights, he could be isolated locally and > > won't affect other wikis. Looks safe for me. > > > > Bad news: > > - Nobody, besides MySQL users would be happy, XEM is MySQL dependent still > > :-( > > > > So, before I'd "jira" an idea, I'd like to know community opinion to keep > > it comprehensive. > > > > Hope, it would be nice idea for 4.0 roadmap to think over :-) > > > > Best Regards, > > > > Dmitry > > > > > > 28 января 2012, 00:53 от Eduard Moraru <enygma2002(a)gmail.com>: > > > > > > Hello again, > > > > Please see below... > > > > On Fri, Jan 27, 2012 at 3:17 PM, Haru Mamburu <haru_mamburu(a)mail.ru> > > wrote: > > Thanks a lot for clarification. > > > > It makes sence now from explained point of view, but I still can't get WHY > > as global user on NON-workspace wiki I should see Workspace Manager menus? > > > > As I tried to explain in my previous mail, the idea is that you are a > > global user, coming from a global context (the main wiki). In that global > > context, you have the Workspace application installed and available for you > > to use. This means that, the Workspace > > application offers you the possibility to create a new workspace, jump > > to the main wiki or view existing workspaces trough the top-menu. > > > > From the Workspace application's point of view, it is only natural to > > allow you to perform these actions, regardless of your current location > > (that means even if you are viewing a non-workspace subwiki). As long as > > the Workspace application is installed, it will perform as designed :) > > > > Anyhow I can't use Workspace Manager INSIDE virtual Wiki. It makes sence > > if you would extend Workspace manager and make it completely independent on > > each and every virtual wiki. > > > > So, the main reason why: it's just useles inside virtual wiki (for now) > > > > Again, the extra menus are not about what you can do on the current wiki, > > but they are about what you can do on the whole XWiki, since this is a > > feature that spans cross wikis and is not restricted to an individual wiki > > (even if it is installed on the main wiki). > > > > > > For me, e.g., ideal workflow looks like: > > > > Case 1. XEM -> virtual wiki isolated, no Workspace Manager on board > > > > This is perfectly doable right now. If you think about the reasons for > > which you are creating a regular subwiki and not a workspace, you`ll notice > > that the main one is that you want local users. But since local users do > > not see any extra menus, you are good to go. Only you, as a global user (or > > admin) will see those menus, but that is just because the main wiki is > > offering you this possibility (since you are its member). > > > > Case 2. XEM -> virtual wiki isolated, WITH Workspace Manager on board. > > Each virtual wiki in this case will be able to produce it's own workspaces > > isolated from each other (like independent projects on the same server). > > Only Local Users can take part in workspace management. > > > > As you might already know, XWiki currently supports only *one level* of > > virtualisation and only one main wiki. You can not currently create a > > subwiki within a subwiki, not even with the WikiManager application. This > > means that you can not do this with Workspaces either. > > > > If you wish to obtain this scenario, you will have to set up multiple > > instances of XWiki. > > > > Having a subwiki within another subwiki might be an interesting new > > feature for the WikiManager application (and for Workspaces too). Please > > feel free to add a new feature request on jira.xwiki.org for the > > WikiManager component. > > > > > > Case 3. XEM -> virtual wiki isolated + Workspace manager on board. Same as > > Case 2, but Local Users can log once in any virtual/workspace wiki they > > allowed AND via this login have access to each and every wiki they > > registered/invited. > > > > If I understand correctly, this usecase would imply that local users > > (created in regular subwikis or, specifically for your case, in subwikis of > > subwikis) have a mechanism that allows them to escape from the isolation of > > the current subwiki of which they are part of and gain access to other > > subwikis or workspaces. > > > > Maybe you could do this by promoting the local user as a global user, > > optionally putting him in a special group to better manage rights. This way > > he/she can create/join workspaces and join other wikis. > > > > > > For current purposes I would prefer Case 1 behaviour. Soon I'd like to use > > Case 2 then 3 scenario, but for now - no way :-( > > > > Hope it would be useful for futher development. > > > > Yes, as I said, having subwikis within subwikis is a good idea that might > > actually be not so hard to implement (as far as Thomas tells me). > > > > Hope this helped. > > > > Thanks, > > Eduard > > > > Kind Regards, > > > > Dmitry > > > > > > > > > > 27 января 2012, 16:48 от Eduard Moraru <enygma2002(a)gmail.com>: > > > > > > Oh, I see now. > > > > The way it works now when visiting a normal subwiki (not a workspace) is > > that: > > > > 1) If you are a global user (user of the main wiki), the menus will be > > displayed to you (and you will be thus exposed to the global context of > > which you are part of). > > > > 2) If you are a local user (user of a subwiki that is part of a wiki > > *farm*), you don`t see the menus any more and are isolated inside the wiki > > (and not exposed to the global context). > > > > So, as a conclusion, the menus appear to you based on your user type and > > not on the type of wiki you are currently viewing. > > > > Does that make sense now? Does this fit your usecase? If not, can you > > please elaborate on the reason why you would like global users not to be > > able to see the global context when viewing a regular subwiki? > > > > Thanks, > > Eduard > > > > On Fri, Jan 27, 2012 at 1:32 PM, Haru Mamburu <haru_mamburu(a)mail.ru> > > wrote: > > Thank you Eduard, > > > > Sorry, probably I wasn't clear in my questions... > > > > - I want to use WORKSPACE Manager on MAIN Wiki and manage them as designed. > > - BUT, the same time I want to use WIKI Manager to have completely > > independent from main wiki and other workspaces virtual wikis. > > > > So, I set up XEM, installed Workspace manager to play around AND with Wiki > > Manager created virtual Wiki. > > Now I completely stuck how to get rid of all Workspace Manager links in > > wiki farm (!) (not workspaces). I would prefer to keep running Workspace > > Manager on main Wiki AND Wiki farm simultaneously, if possible. > > > > Is there any simple solution? > > > > The only thing I suppose should work is to take *.vm files from XE and > > attach them to the skin file. Looks wierd and unpredictable for me :-( > > > > Kind Regards, > > > > Dmitry > > > > > > 27 января 2012, 14:26 от Eduard Moraru <enygma2002(a)gmail.com>: > > > > > > Hi Dmitry, > > > > Starting with 3.3, XEM has moved the main usecase for subwikis from farm > > to workspaces. This means that, additionally to the WikiManager application > > [1], now XEM also contains the Workspace Application [2]. > > > > The encouraged way of for creating a wiki farm right now (if that is > > really what you need) is to get XE, install WikiManager [1] and create your > > farm. > > > > If you *insist* on using XEM for creating a wiki farm, all you have to do > > is delete the WorkspaceManager space, thus removing the Workspaces > > application and disabling the extra menus that were getting in your way. > > Additionally, you should also remove the > > xwiki-platform-workspace-api-<version>.jar file from the > > /webapps/xwiki/WEB-INF/lib/ folder, since you don`t want to use it anymore > > and you have removed the UI. > > > > However, if your plan is to have global users that work on different > > subwikis (like an intranet with departments mapped to subwikis or a place > > where you work on projects mapped to subwikis, etc.), you might reconsider > > using Workspaces. > > > > In any case, I hope this solves your problem. > > > > Thanks, > > Eduard > > > > ----------------- > > References: > > [1] > > http://extensions.xwiki.org/xwiki/bin/view/Extension/Wiki+Manager+Applicati… > > [2] > > http://extensions.xwiki.org/xwiki/bin/view/Extension/Workspace+Application > > > > On Fri, Jan 27, 2012 at 11:57 AM, Haru Mamburu <haru_mamburu(a)mail.ru> > > wrote: > > Ooops, wrong solution. The problem is still active: is there a right way > > to get rid of Workspace Manager's links in virtual wikis in 3.4? > > > > > > 27 января 2012, 13:46 от Haru Mamburu <haru_mamburu(a)mail.ru>: > > > Hi All, > > > > > > By accident I found a soluion. For me it looks a bit wierd. > > > > > > If you set in xwiki.cfg xwiki.virtual.usepath to 0, then all menus > > become Workspace Manager links free. > > > > > > For now, if I want to use usepath and don't want to use Workspace > > Manager, there is no an "one click solution" :-( > > > > > > Is it a bug or it's a feature? Should I report it? > > > > > > Kind regards, > > > > > > Dmitry > > > > > > 27 января 2012, 01:34 от Haru Mamburu <haru_mamburu(a)mail.ru>: > > > > Hi. all! > > > > > > > > XEM 3.4. Main Wiki works fine. > > > > > > > > I want to set up virtual wiki without Workspace Manager application > > inside and it's links in menu, because as far as I inderstood it is useless > > in virtual wikis. > > > > > > > > What is right way to get rid of Workspace Manager and it's links in > > top menu in virtual wiki? > > > > > > > > Kind regards, > > > > > > > > Dmitry > > _______________________________________________ > > users mailing list > > users(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/users > > > > > > _______________________________________________ > > users mailing list > > users(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/users > > > > > > _______________________________________________ > > users mailing list > > users(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/users > > > > > > _______________________________________________ > > users mailing list > > users(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/users > > > > > > _______________________________________________ > > users mailing list > > users(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/users > > > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users >

13 years, 10 months

1
0
0 0

Re: [xwiki-users] Workspace manager free default pages set + "new idea"

by Haru Mamburu

Hi Eduard, Thanks for explnation. I'm very happy to issue a "new idea", but idea itself is a bit wider and deeper, then described below. I would like to point out some reasons and effects to be more clear before "jiraing" it :-) "Security leak" XE/XEM Usecase XE/XEM + Workspace Manager. One main Wiki and let's say, hundreds of workspaces. To be more real we'd add Wiki Manager and tens of virtual wikis running on the same engine (something like XWiki.com running) As my humble experience shows, nearly never in natural way XWiki would have only one User with Admin Rights on the Wiki level. It's human to be all the time in a hurry and meanwhile XWiki becomes messy inside. It's not the big problem yet. :-) As an Admin User on wiki level, I can easily gain programming rights. For now, it's completely uncontrolled and will run unnoticed. So, let's imagine that all stars in solar system lined up in a bad way and one Admin became an AngryAdmin with a revenge as a primary goal of life. Let's make it even worth: AngryAdmin knows XWiki quite good and scripting for him is an open book. To make it more real: AngryAdmin doesn't have root access to the server. :-) At this stage he has all necessary knowledge and access rights to ruin ALL WIKIs onboard. I didn't dig much in it, but if Workspace Manager has appropriate tools, then it's possible: one short script and it's over :-) I didn't met such occasions before, but heard a lot of similar usecases (not with XWiki :-) Thus, I NEVER run production on MAIN wiki! It looks dangerous for me. I'd better be paranoic admin rather embarrased admin. If somebody will become an "angry-beaver-admin", he would be able to ruin only one space (now he has a front-end tool for this :-)) or more, but only inside one project and all running wikis will stay alive. Such workflow keeps my paranoia quiet :-) SO, at last "new idea": escape MAIN WIKI from production completely. As only global users has programming rights, it looks very logic to leave Main Wiki to "Core and instances" management and keep it safe from local admins. When U have a lot of users it sounds reasonable for me. Let's return to our Case 1-3 described below. The most flexible solution looks as following: | virtual wiki 1 -> workspaces | virtual wiki 2 -> workspaces -> workspaces (probably) Main Wiki | .................................................. | virtual wiki N - "Solo" - No Workspace Manager onboard (administration) (production) Such a way we can run everything simultaneously on the same server. No need to run a lot of instances. If someone want's programming rights, he could be isolated locally and won't affect other wikis. Looks safe for me. Bad news: - Nobody, besides MySQL users would be happy, XEM is MySQL dependent still :-( So, before I'd "jira" an idea, I'd like to know community opinion to keep it comprehensive. Hope, it would be nice idea for 4.0 roadmap to think over :-) Best Regards, Dmitry 28 января 2012, 00:53 от Eduard Moraru <enygma2002(a)gmail.com>: Hello again, Please see below... On Fri, Jan 27, 2012 at 3:17 PM, Haru Mamburu <haru_mamburu(a)mail.ru> wrote: Thanks a lot for clarification. It makes sence now from explained point of view, but I still can't get WHY as global user on NON-workspace wiki I should see Workspace Manager menus? As I tried to explain in my previous mail, the idea is that you are a global user, coming from a global context (the main wiki). In that global context, you have the Workspace application installed and available for you to use. This means that, the Workspace application offers you the possibility to create a new workspace, jump to the main wiki or view existing workspaces trough the top-menu. From the Workspace application's point of view, it is only natural to allow you to perform these actions, regardless of your current location (that means even if you are viewing a non-workspace subwiki). As long as the Workspace application is installed, it will perform as designed :) Anyhow I can't use Workspace Manager INSIDE virtual Wiki. It makes sence if you would extend Workspace manager and make it completely independent on each and every virtual wiki. So, the main reason why: it's just useles inside virtual wiki (for now) Again, the extra menus are not about what you can do on the current wiki, but they are about what you can do on the whole XWiki, since this is a feature that spans cross wikis and is not restricted to an individual wiki (even if it is installed on the main wiki). For me, e.g., ideal workflow looks like: Case 1. XEM -> virtual wiki isolated, no Workspace Manager on board This is perfectly doable right now. If you think about the reasons for which you are creating a regular subwiki and not a workspace, you`ll notice that the main one is that you want local users. But since local users do not see any extra menus, you are good to go. Only you, as a global user (or admin) will see those menus, but that is just because the main wiki is offering you this possibility (since you are its member). Case 2. XEM -> virtual wiki isolated, WITH Workspace Manager on board. Each virtual wiki in this case will be able to produce it's own workspaces isolated from each other (like independent projects on the same server). Only Local Users can take part in workspace management. As you might already know, XWiki currently supports only *one level* of virtualisation and only one main wiki. You can not currently create a subwiki within a subwiki, not even with the WikiManager application. This means that you can not do this with Workspaces either. If you wish to obtain this scenario, you will have to set up multiple instances of XWiki. Having a subwiki within another subwiki might be an interesting new feature for the WikiManager application (and for Workspaces too). Please feel free to add a new feature request on jira.xwiki.org for the WikiManager component. Case 3. XEM -> virtual wiki isolated + Workspace manager on board. Same as Case 2, but Local Users can log once in any virtual/workspace wiki they allowed AND via this login have access to each and every wiki they registered/invited. If I understand correctly, this usecase would imply that local users (created in regular subwikis or, specifically for your case, in subwikis of subwikis) have a mechanism that allows them to escape from the isolation of the current subwiki of which they are part of and gain access to other subwikis or workspaces. Maybe you could do this by promoting the local user as a global user, optionally putting him in a special group to better manage rights. This way he/she can create/join workspaces and join other wikis. For current purposes I would prefer Case 1 behaviour. Soon I'd like to use Case 2 then 3 scenario, but for now - no way :-( Hope it would be useful for futher development. Yes, as I said, having subwikis within subwikis is a good idea that might actually be not so hard to implement (as far as Thomas tells me). Hope this helped. Thanks, Eduard Kind Regards, Dmitry 27 января 2012, 16:48 от Eduard Moraru <enygma2002(a)gmail.com>: Oh, I see now. The way it works now when visiting a normal subwiki (not a workspace) is that: 1) If you are a global user (user of the main wiki), the menus will be displayed to you (and you will be thus exposed to the global context of which you are part of). 2) If you are a local user (user of a subwiki that is part of a wiki *farm*), you don`t see the menus any more and are isolated inside the wiki (and not exposed to the global context). So, as a conclusion, the menus appear to you based on your user type and not on the type of wiki you are currently viewing. Does that make sense now? Does this fit your usecase? If not, can you please elaborate on the reason why you would like global users not to be able to see the global context when viewing a regular subwiki? Thanks, Eduard On Fri, Jan 27, 2012 at 1:32 PM, Haru Mamburu <haru_mamburu(a)mail.ru> wrote: Thank you Eduard, Sorry, probably I wasn't clear in my questions... - I want to use WORKSPACE Manager on MAIN Wiki and manage them as designed. - BUT, the same time I want to use WIKI Manager to have completely independent from main wiki and other workspaces virtual wikis. So, I set up XEM, installed Workspace manager to play around AND with Wiki Manager created virtual Wiki. Now I completely stuck how to get rid of all Workspace Manager links in wiki farm (!) (not workspaces). I would prefer to keep running Workspace Manager on main Wiki AND Wiki farm simultaneously, if possible. Is there any simple solution? The only thing I suppose should work is to take *.vm files from XE and attach them to the skin file. Looks wierd and unpredictable for me :-( Kind Regards, Dmitry 27 января 2012, 14:26 от Eduard Moraru <enygma2002(a)gmail.com>: Hi Dmitry, Starting with 3.3, XEM has moved the main usecase for subwikis from farm to workspaces. This means that, additionally to the WikiManager application [1], now XEM also contains the Workspace Application [2]. The encouraged way of for creating a wiki farm right now (if that is really what you need) is to get XE, install WikiManager [1] and create your farm. If you *insist* on using XEM for creating a wiki farm, all you have to do is delete the WorkspaceManager space, thus removing the Workspaces application and disabling the extra menus that were getting in your way. Additionally, you should also remove the xwiki-platform-workspace-api-<version>.jar file from the /webapps/xwiki/WEB-INF/lib/ folder, since you don`t want to use it anymore and you have removed the UI. However, if your plan is to have global users that work on different subwikis (like an intranet with departments mapped to subwikis or a place where you work on projects mapped to subwikis, etc.), you might reconsider using Workspaces. In any case, I hope this solves your problem. Thanks, Eduard ----------------- References: [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Wiki+Manager+Applicati… [2] http://extensions.xwiki.org/xwiki/bin/view/Extension/Workspace+Application On Fri, Jan 27, 2012 at 11:57 AM, Haru Mamburu <haru_mamburu(a)mail.ru> wrote: Ooops, wrong solution. The problem is still active: is there a right way to get rid of Workspace Manager's links in virtual wikis in 3.4? 27 января 2012, 13:46 от Haru Mamburu <haru_mamburu(a)mail.ru>: > Hi All, > > By accident I found a soluion. For me it looks a bit wierd. > > If you set in xwiki.cfg xwiki.virtual.usepath to 0, then all menus become Workspace Manager links free. > > For now, if I want to use usepath and don't want to use Workspace Manager, there is no an "one click solution" :-( > > Is it a bug or it's a feature? Should I report it? > > Kind regards, > > Dmitry > > 27 января 2012, 01:34 от Haru Mamburu <haru_mamburu(a)mail.ru>: > > Hi. all! > > > > XEM 3.4. Main Wiki works fine. > > > > I want to set up virtual wiki without Workspace Manager application inside and it's links in menu, because as far as I inderstood it is useless in virtual wikis. > > > > What is right way to get rid of Workspace Manager and it's links in top menu in virtual wiki? > > > > Kind regards, > > > > Dmitry _______________________________________________ users mailing list users(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/users _______________________________________________ users mailing list users(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/users _______________________________________________ users mailing list users(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/users

13 years, 10 months

2
3
0 0

[xwiki-users] Tag cloud with only 'viewable' tags

by Joris Dirks

I'm not sure if this is possible in the current configuration: My issue is this: A (anonymous) user can see tags used only in 'private' pages, e.g. pages the current user has no view acces to. If he clicks a tag, he can see the page "Tags?do=viewTag&tag=DeadlyIncidents" showing him no pages with this tag. The problem is threefold: - The tagcloud is cluttered with tags that are of no use to the current user - The user can become confused if he tries to look for a page with that tag - Information existing in a page is leaked. A tag is just a tag, but it can tells something about information on one or more pages. In my opinion, the user should only be able to see tags that are used in pages he has view right to. I can imagine it would put a heavy load on a system to check for every tag if it's used in viewable pages, though. Any thoughts? Sincerily, Joris

13 years, 10 months

1
0
0 0

[xwiki-users] procedure steps

by Jinyan Su

Hi. I'm trying to write a set of procedures in xwiki. Something like: 1. Add the LDOM to the lab dhcp tables. {{code}}blah{{/code}} 2. ssh to the system {{code}}blah{{/code}} I tried using: 1. Add the LDOM 1. ssh to the system But, it saw these as different numbered lists. Is there a standard/preferred way of writing procedures in xwiki? Maybe using groupings {{{ }}}? Thanks.

13 years, 10 months

2
1
0 0

[xwiki-users] Page title bugs when using objects in XE 3.4?

by Mark Wallace

Are these bugs in XE 3.4? When I create a new class and then objects of that class, the page title is the name of the class sheet, not the name I entered for the page (which is what I'd expect and what you'd see in earlier versions such as XE 3.1). I call this BUG 2 in the steps to reproduce, below. While we're at it, there is also what I call BUG 1 in the steps below, where it appears the name of the class does not show up in the "bread crumbs" trail (or whatever you call that) at the top of the page. Steps to reproduce: 1.Log in as Administrator 2.Go to /Data types/ page (http://localhost:8080/xwiki/bin/view/XWiki/XWikiClasses) 3.Enter class name /TitleTest/ and click /Create This Class/; (system shows an edit page) 4.Click /Save & View/; (system shows the class page) 5.Click on /class editor/ link; (system shows editing class page) 6.Enter property name /aString/ with type /String/ and click /ADD/ button 7.Click /Save & View/ 8.*BUG 1*: Note that at top of page, says Wiki Home >> XWiki Space >> Data Types >> (blank).Shouldn't there be the class name here?) 9.Click /Create the Document Sheet/ 10.Click /Bind the sheet to the class/ 11.Click /Create the Class Template/ 12.Click /Add a TitleTest object to the template/ 13.Under /Create a new document/, enter Document name /TestDoc1/ and click /Create this Document/ 14.Enter the value /some value/ for the /aString/ property and click /Save & View/ 15.*BUG 2*(?): Note that the largest text on the page is /TitleTestClass Sheet/ --shouldn't this be the page name we used to create the new document, the same name that is at the end of the URL (http://localhost:8080/xwiki/bin/view/Main/TestDoc1), which is TestDoc1?? 16.Click /Edit > Wiki/, and enter the title /TestDoc1/ and click /Save & View/. 17.Note that the largest text on the page still says /TitleTestClass Sheet/ --shouldn't this be the title we just entered?? -- Mark Wallace Principal Engineer, Semantic Applications Modus Operandi, Inc.

13 years, 10 months

3
2
0 0

Re: [xwiki-users] dafault DB name change

by Haru Mamburu

Here it is... Timestamp Jan 30, 2012 17:56:30.064 Log Level INFO Logger javax.enterprise.system.std.com.sun.enterprise.server.logging Name-Value Pairs _ThreadID=25;_ThreadName=Thread-2; Record Number 72 Message ID Complete Message 2012-01-30 17:56:30,064 [http://mydomain.com:8180/xwiki/bin/view/Main/] WARN c.x.x.XWiki - Exception while getting wiki preference [xwiki.plugin.activitystream.daystokeepevents] com.xpn.xwiki.XWikiException: Error number 3202 in 3: Exception while reading document [name = [XWikiPreferences], type = [DOCUMENT], parent = [name = [XWiki], type = [SPACE], parent = [name = [xwiki], type = [WIKI], parent = [null]]]] Wrapped Exception: Error number 3301 in 3: Exception while switching to database xwiki Wrapped Exception: Access denied for user 'test'@'localhost' to database 'xwiki' at com.xpn.xwiki.store.XWikiHibernateStore.loadXWikiDoc(XWikiHibernateStore.java:856) ~[xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.store.XWikiCacheStore.loadXWikiDoc(XWikiCacheStore.java:283) ~[xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.XWiki.getDocument(XWiki.java:1427) [xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.XWiki.getDocument(XWiki.java:1470) [xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.XWiki.getXWikiPreference(XWiki.java:2207) [xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.plugin.activitystream.plugin.ActivityStreamPlugin.getActivityStreamPreference(ActivityStreamPlugin.java:111) [xwiki-platform-activitystream-3.4.jar:na] at com.xpn.xwiki.plugin.activitystream.impl.ActivityStreamCleaner.getNumberOfDaysToKeep(ActivityStreamCleaner.java:106) [xwiki-platform-activitystream-3.4.jar:na] at com.xpn.xwiki.plugin.activitystream.impl.ActivityStreamCleaner.init(ActivityStreamCleaner.java:215) [xwiki-platform-activitystream-3.4.jar:na] at com.xpn.xwiki.plugin.activitystream.impl.ActivityStreamImpl.init(ActivityStreamImpl.java:230) [xwiki-platform-activitystream-3.4.jar:na] at com.xpn.xwiki.plugin.activitystream.plugin.ActivityStreamPlugin.init(ActivityStreamPlugin.java:124) [xwiki-platform-activitystream-3.4.jar:na] at com.xpn.xwiki.plugin.XWikiPluginManager.initPlugin(XWikiPluginManager.java:152) [xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.plugin.XWikiPluginManager.addPlugin(XWikiPluginManager.java:88) [xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.plugin.XWikiPluginManager.addPlugins(XWikiPluginManager.java:116) [xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.XWiki.preparePlugins(XWiki.java:1111) [xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.XWiki.initXWiki(XWiki.java:792) [xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.XWiki.<init>(XWiki.java:739) [xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.XWiki.getMainXWiki(XWiki.java:401) [xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.XWiki.getXWiki(XWiki.java:487) [xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:136) [xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:116) [xwiki-platform-legacy-oldcore-3.4.jar:na] at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) [struts-1.2.9.jar:1.2.9] at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) [struts-1.2.9.jar:1.2.9] at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) [struts-1.2.9.jar:1.2.9] at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414) [struts-1.2.9.jar:1.2.9] at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [javax.servlet.jar:na] at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [javax.servlet.jar:na] at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539) [web-core.jar:3.1.1] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343) [web-core.jar:3.1.1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) [web-core.jar:3.1.1] at com.xpn.xwiki.web.ActionFilter.doFilter(ActionFilter.java:128) [xwiki-platform-legacy-oldcore-3.4.jar:na] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) [web-core.jar:3.1.1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) [web-core.jar:3.1.1] at org.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:144) [xwiki-platform-wysiwyg-server-3.4.jar:na] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) [web-core.jar:3.1.1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) [web-core.jar:3.1.1] at com.xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java:68) [xwiki-platform-webdav-server-3.4.jar:na] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) [web-core.jar:3.1.1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) [web-core.jar:3.1.1] at org.xwiki.container.servlet.filters.internal.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:217) [xwiki-platform-container-servlet-3.4.jar:na] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) [web-core.jar:3.1.1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) [web-core.jar:3.1.1] at org.xwiki.container.servlet.filters.internal.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:109) [xwiki-platform-container-servlet-3.4.jar:na] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) [web-core.jar:3.1.1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) [web-core.jar:3.1.1] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279) [web-core.jar:3.1.1] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) [web-core.jar:3.1.1] at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655) [web-core.jar:3.1.1] at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595) [web-core.jar:3.1.1] at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98) [web-glue.jar:3.1.1] at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91) [web-glue.jar:3.1.1] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162) [web-core.jar:3.1.1] at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:330) [web-core.jar:3.1.1] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231) [web-core.jar:3.1.1] at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174) [kernel.jar:3.1.1] at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828) [grizzly-http.jar:1.9.36] at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725) [grizzly-http.jar:1.9.36] at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019) [grizzly-http.jar:1.9.36] at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225) [grizzly-http.jar:1.9.36] at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) [grizzly-framework.jar:1.9.36] at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) [grizzly-framework.jar:1.9.36] at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) [grizzly-framework.jar:1.9.36] at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) [grizzly-http.jar:1.9.36] at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) [grizzly-framework.jar:1.9.36] at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) [grizzly-framework.jar:1.9.36] at com.sun.grizzly.ContextTask.run(ContextTask.java:71) [grizzly-framework.jar:1.9.36] at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) [grizzly-utils.jar:1.9.36] at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) [grizzly-utils.jar:1.9.36] at java.lang.Thread.run(Thread.java:662) [na:1.6.0_26] Caused by: com.xpn.xwiki.XWikiException: Error number 3301 in 3: Exception while switching to database xwiki Wrapped Exception: Access denied for user 'test'@'localhost' to database 'xwiki' at com.xpn.xwiki.store.XWikiHibernateBaseStore.setDatabase(XWikiHibernateBaseStore.java:631) ~[xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.store.XWikiHibernateBaseStore.beginTransaction(XWikiHibernateBaseStore.java:767) ~[xwiki-platform-legacy-oldcore-3.4.jar:na] at com.xpn.xwiki.store.XWikiHibernateStore.loadXWikiDoc(XWikiHibernateStore.java:731) ~[xwiki-platform-legacy-oldcore-3.4.jar:na] ... 67 common frames omitted Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Access denied for user 'test'@'localhost' to database 'xwiki' at sun.reflect.GeneratedConstructorAccessor162.newInstance(Unknown Source) ~[na:na] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) ~[na:1.6.0_26] at java.lang.reflect.Constructor.newInstance(Constructor.java:513) ~[na:1.6.0_26] at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) ~[mysql-connector-java-5.1.18-bin.jar:na] at com.mysql.jdbc.Util.getInstance(Util.java:386) ~[mysql-connector-java-5.1.18-bin.jar:na] at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1052) ~[mysql-connector-java-5.1.18-bin.jar:na] at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3609) ~[mysql-connector-java-5.1.18-bin.jar:na] at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3541) ~[mysql-connector-java-5.1.18-bin.jar:na] at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2002) ~[mysql-connector-java-5.1.18-bin.jar:na] at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2163) ~[mysql-connector-java-5.1.18-bin.jar:na] at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2618) ~[mysql-connector-java-5.1.18-bin.jar:na] at com.mysql.jdbc.ConnectionImpl.setCatalog(ConnectionImpl.java:5086) ~[mysql-connector-java-5.1.18-bin.jar:na] at org.apache.commons.dbcp.DelegatingConnection.setCatalog(DelegatingConnection.java:374) ~[commons-dbcp-1.3.jar:1.3] at org.apache.commons.dbcp.DelegatingConnection.setCatalog(DelegatingConnection.java:374) ~[commons-dbcp-1.3.jar:1.3] at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.setCatalog(PoolingDataSource.java:333) ~[commons-dbcp-1.3.jar:1.3] at sun.reflect.GeneratedMethodAccessor164.invoke(Unknown Source) ~[na:na] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) ~[na:1.6.0_26] at java.lang.reflect.Method.invoke(Method.java:597) ~[na:1.6.0_26] at org.hibernate.jdbc.BorrowedConnectionProxy.invoke(BorrowedConnectionProxy.java:74) ~[hibernate-core-3.6.9.Final.jar:3.6.9.Final] at $Proxy213.setCatalog(Unknown Source) ~[na:na] at com.xpn.xwiki.store.XWikiHibernateBaseStore.setDatabase(XWikiHibernateBaseStore.java:620) ~[xwiki-platform-legacy-oldcore-3.4.jar:na] ... 69 common frames omitted 30 января 2012, 21:29 от Thomas Mortagne <thomas.mortagne(a)xwiki.com>: > On Mon, Jan 30, 2012 at 6:10 PM, Haru Mamburu <haru_mamburu(a)mail.ru> wrote: > > Yes, I did. :-( > > > > XEM 3.4 > > > > javax.servlet.ServletException: com.xpn.xwiki.XWikiException: Error number 3 in 0: Could not initialize main XWiki context > > Wrapped Exception: Error number 3202 in 3: Exception while reading document [name = [XWikiPreferences], type = [DOCUMENT], parent = [name = [XWiki], type = [SPACE], parent = [name = [xwiki], type = [WIKI], parent = [null]]]] > > Wrapped Exception: Error number 3301 in 3: Exception while switching to database xwiki > > Wrapped Exception: Access denied for user 'test'@'localhost' to database 'xwiki' > > Do you have more ? Would be nice to get the full stack trace. > > > > > And actually there is no DB xwiki in Mysql. Xwiki is completely right. > > The rest settings in xwiki.cfg are intact. > > > > Kind regards > > > > Dmitry > > > > PS. Sorry for the private mailing > >> > >> 30 января 2012, 20:46 от Thomas Mortagne <thomas.mortagne(a)xwiki.com>: > >> > On Mon, Jan 30, 2012 at 5:06 PM, Haru Mamburu <haru_mamburu(a)mail.ru> wrote: > >> > > Hi, All! > >> > > > >> > > Does anyone know, is it possible to change default DB name xwiki to smth else? > >> > > > >> > > I changed in config.cfg, > >> > > > >> > > xwiki.db=test > >> > > > >> > > in hibernate.cfg.xml > >> > > > >> > > <property name="connection.url">jdbc:mysql://localhost/test</property> > >> > > > >> > > After XWiki reload it tries to access xwiki db still. :-( > >> > > > >> > > What is correct way to do it? > >> > > >> > Well that's supposed to be the correct way actually. You sure you > >> > uncommented xwiki.db ? > >> > > >> > > > >> > > Thanks in advance, > >> > > > >> > > Dmitry > >> > > _______________________________________________ > >> > > users mailing list > >> > > users(a)xwiki.org > >> > > http://lists.xwiki.org/mailman/listinfo/users > >> > > >> > -- > >> > Thomas Mortagne > >> > > > _______________________________________________ > > users mailing list > > users(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/users > > -- > Thomas Mortagne >

13 years, 10 months

2
1
0 0

[xwiki-users] [Poll] What features would you like to have in XWiki 4.x?

by Vincent Massol

Hi XWiki users, In 2009 we launched a survey on xwiki.org about features would like to have in XWiki in priority: http://www.xwiki.org/xwiki/bin/view/Main/SurveyXWikiFeatures2009 The results were published here: - http://www.xwiki.org/xwiki/bin/view/Blog/Features+Survey+Results - http://www.xwiki.org/xwiki/bin/view/Blog/FeatureStatus20120119 The idea is to do that same with a new survey in order to give us some information to prepare our XWiki 4.x roadmaps. Thus it would help us a lot if you could go the following URL and answer the survey there: http://www.xwiki.org/xwiki/bin/view/Main/SurveyXWikiFeatures2012 Please answer as soon as possible since the earliest we get feedback the earliest we can start using it to decide what's put in the roadmaps! :) Results will be published on xwiki.org. Thanks -Vincent on behalf of the XWiki Committers

13 years, 10 months

2
1
0 0

Re: [xwiki-users] dafault DB name change

by Haru Mamburu

Yes, I did. :-( XEM 3.4 javax.servlet.ServletException: com.xpn.xwiki.XWikiException: Error number 3 in 0: Could not initialize main XWiki context Wrapped Exception: Error number 3202 in 3: Exception while reading document [name = [XWikiPreferences], type = [DOCUMENT], parent = [name = [XWiki], type = [SPACE], parent = [name = [xwiki], type = [WIKI], parent = [null]]]] Wrapped Exception: Error number 3301 in 3: Exception while switching to database xwiki Wrapped Exception: Access denied for user 'test'@'localhost' to database 'xwiki' And actually there is no DB xwiki in Mysql. Xwiki is completely right. The rest settings in xwiki.cfg are intact. Kind regards Dmitry PS. Sorry for the private mailing > > 30 января 2012, 20:46 от Thomas Mortagne <thomas.mortagne(a)xwiki.com>: > > On Mon, Jan 30, 2012 at 5:06 PM, Haru Mamburu <haru_mamburu(a)mail.ru> wrote: > > > Hi, All! > > > > > > Does anyone know, is it possible to change default DB name xwiki to smth else? > > > > > > I changed in config.cfg, > > > > > > xwiki.db=test > > > > > > in hibernate.cfg.xml > > > > > > <property name="connection.url">jdbc:mysql://localhost/test</property> > > > > > > After XWiki reload it tries to access xwiki db still. :-( > > > > > > What is correct way to do it? > > > > Well that's supposed to be the correct way actually. You sure you > > uncommented xwiki.db ? > > > > > > > > Thanks in advance, > > > > > > Dmitry > > > _______________________________________________ > > > users mailing list > > > users(a)xwiki.org > > > http://lists.xwiki.org/mailman/listinfo/users > > > > -- > > Thomas Mortagne > >

13 years, 10 months

2
1
0 0

[xwiki-users] dafault DB name change

by Haru Mamburu

Hi, All! Does anyone know, is it possible to change default DB name xwiki to smth else? I changed in config.cfg, xwiki.db=test in hibernate.cfg.xml <property name="connection.url">jdbc:mysql://localhost/test</property> After XWiki reload it tries to access xwiki db still. :-( What is correct way to do it? Thanks in advance, Dmitry

13 years, 10 months

2
1
0 0

[xwiki-users] What is happening with xcontext object through process of creating a new page?

by Ozren Lasić

Hi, In order to customize WYSIWYSG editor only on some pages I have made following changes in wysiwyg_storeConfig macro: #macro(wysiwyg_storeConfig $parameters $editedDocument $fieldId $full) ... #if($xcontext.contains('wysiwyg_overriding_parameters')) #set($ok = $parameters.putAll($xcontext.putAll('wysiwyg_overriding_parameters'))) #end ... #end Part of sheet for these pages looks like this: #set($overriding_parameters = $util.hashMap) #set($ok = $overriding_parameters.put('plugins', ...)) #set($ok = $overriding_parameters.put('menu', ...)) #set($ok = $overriding_parameters.put('toolbar', ...)) #set($ok = $xcontext.put('wysiwyg_overriding_parameters', $overriding_parameters)) This is good enough for editors on previously created pages. Editors look (in inline mode) just the way I want. But, on new pages editors always use default configuration. To test these unexpected result I added following two lines in the sheet: #set($ok = $xcontext.put('foo', 'bar')) $xcontext.get('foo') On new pages $xcontext.get('foo') is displayed, and on existing ones it is bar. (Version 3.1) Thanks, Ozren

13 years, 11 months

2
1
0 0

Re: [xwiki-users] Workspace manager free default pages set

by Haru Mamburu

Thanks a lot for clarification. It makes sence now from explained point of view, but I still can't get WHY as global user on NON-workspace wiki I should see Workspace Manager menus? Anyhow I can't use Workspace Manager INSIDE virtual Wiki. It makes sence if you would extend Workspace manager and make it completely independent on each and every virtual wiki. So, the main reason why: it's just useles inside virtual wiki (for now) For me, e.g., ideal workflow looks like: Case 1. XEM -> virtual wiki isolated, no Workspace Manager on board Case 2. XEM -> virtual wiki isolated, WITH Workspace Manager on board. Each virtual wiki in this case will be able to produce it's own workspaces isolated from each other (like independent projects on the same server). Only Local Users can take part in workspace management. Case 3. XEM -> virtual wiki isolated + Workspace manager on board. Same as Case 2, but Local Users can log once in any virtual/workspace wiki they allowed AND via this login have access to each and every wiki they registered/invited. For current purposes I would prefer Case 1 behaviour. Soon I'd like to use Case 2 then 3 scenario, but for now - no way :-( Hope it would be useful for futher development. Kind Regards, Dmitry 27 января 2012, 16:48 от Eduard Moraru <enygma2002(a)gmail.com>: Oh, I see now. The way it works now when visiting a normal subwiki (not a workspace) is that: 1) If you are a global user (user of the main wiki), the menus will be displayed to you (and you will be thus exposed to the global context of which you are part of). 2) If you are a local user (user of a subwiki that is part of a wiki *farm*), you don`t see the menus any more and are isolated inside the wiki (and not exposed to the global context). So, as a conclusion, the menus appear to you based on your user type and not on the type of wiki you are currently viewing. Does that make sense now? Does this fit your usecase? If not, can you please elaborate on the reason why you would like global users not to be able to see the global context when viewing a regular subwiki? Thanks, Eduard On Fri, Jan 27, 2012 at 1:32 PM, Haru Mamburu <haru_mamburu(a)mail.ru> wrote: Thank you Eduard, Sorry, probably I wasn't clear in my questions... - I want to use WORKSPACE Manager on MAIN Wiki and manage them as designed. - BUT, the same time I want to use WIKI Manager to have completely independent from main wiki and other workspaces virtual wikis. So, I set up XEM, installed Workspace manager to play around AND with Wiki Manager created virtual Wiki. Now I completely stuck how to get rid of all Workspace Manager links in wiki farm (!) (not workspaces). I would prefer to keep running Workspace Manager on main Wiki AND Wiki farm simultaneously, if possible. Is there any simple solution? The only thing I suppose should work is to take *.vm files from XE and attach them to the skin file. Looks wierd and unpredictable for me :-( Kind Regards, Dmitry 27 января 2012, 14:26 от Eduard Moraru <enygma2002(a)gmail.com>: Hi Dmitry, Starting with 3.3, XEM has moved the main usecase for subwikis from farm to workspaces. This means that, additionally to the WikiManager application [1], now XEM also contains the Workspace Application [2]. The encouraged way of for creating a wiki farm right now (if that is really what you need) is to get XE, install WikiManager [1] and create your farm. If you *insist* on using XEM for creating a wiki farm, all you have to do is delete the WorkspaceManager space, thus removing the Workspaces application and disabling the extra menus that were getting in your way. Additionally, you should also remove the xwiki-platform-workspace-api-<version>.jar file from the /webapps/xwiki/WEB-INF/lib/ folder, since you don`t want to use it anymore and you have removed the UI. However, if your plan is to have global users that work on different subwikis (like an intranet with departments mapped to subwikis or a place where you work on projects mapped to subwikis, etc.), you might reconsider using Workspaces. In any case, I hope this solves your problem. Thanks, Eduard ----------------- References: [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Wiki+Manager+Applicati… [2] http://extensions.xwiki.org/xwiki/bin/view/Extension/Workspace+Application On Fri, Jan 27, 2012 at 11:57 AM, Haru Mamburu <haru_mamburu(a)mail.ru> wrote: Ooops, wrong solution. The problem is still active: is there a right way to get rid of Workspace Manager's links in virtual wikis in 3.4? 27 января 2012, 13:46 от Haru Mamburu <haru_mamburu(a)mail.ru>: > Hi All, > > By accident I found a soluion. For me it looks a bit wierd. > > If you set in xwiki.cfg xwiki.virtual.usepath to 0, then all menus become Workspace Manager links free. > > For now, if I want to use usepath and don't want to use Workspace Manager, there is no an "one click solution" :-( > > Is it a bug or it's a feature? Should I report it? > > Kind regards, > > Dmitry > > 27 января 2012, 01:34 от Haru Mamburu <haru_mamburu(a)mail.ru>: > > Hi. all! > > > > XEM 3.4. Main Wiki works fine. > > > > I want to set up virtual wiki without Workspace Manager application inside and it's links in menu, because as far as I inderstood it is useless in virtual wikis. > > > > What is right way to get rid of Workspace Manager and it's links in top menu in virtual wiki? > > > > Kind regards, > > > > Dmitry _______________________________________________ users mailing list users(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/users _______________________________________________ users mailing list users(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/users

13 years, 11 months

2
1
0 0

[xwiki-users] Issues upgrading to 3.4 from 3.1

by Chris Meyer

Hi All, I am trying to upgrade our existing xwiki implementation of version 3.1 to 3.4 and I am running into an error when attempting to start up the server. Environment: 1. OS: Redhat Linux 2. Container: Jboss 5.1 3. DB: Hypersonic At this point, I am just tying to get it to launch with the out-of-the-box configurations (no customization). Below is the stack dump I am receiving: 2012-01-27 10:45:52,759 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (main) deploy, ctxPath=/xwiki 2012-01-27 10:45:53,146 ERROR [STDERR] (main) SLF4J: Class path contains multiple SLF4J bindings. 2012-01-27 10:45:53,146 ERROR [STDERR] (main) SLF4J: Found binding in [vfszip:/apps/jboss/ jboss-5.1.0.GA/server/default/deploy/xwiki.war/WEB-INF/lib/logback-classic-1.0.0.jar/org/slf4j/impl/StaticLoggerBinder.class ] 2012-01-27 10:45:53,146 ERROR [STDERR] (main) SLF4J: Found binding in [vfszip:/apps/jboss/ jboss-5.1.0.GA/common/lib/slf4j-jboss-logging.jar/org/slf4j/impl/StaticLoggerBinder.class ] 2012-01-27 10:45:53,146 ERROR [STDERR] (main) SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. 2012-01-27 10:45:57,830 INFO [STDOUT] (main) 2012-01-27 10:45:57,811 [main] ERROR o.r.Reflections - could not create Vfs.Dir from url. ignoring the exception and continuing org.reflections.ReflectionsException: could not create Vfs.Dir from url, no matching UrlType was found [vfszip:/apps/jboss/ jboss-5.1.0.GA/server/default/deploy/xwiki.war/WEB-INF/lib/xwiki-platform-extension-api-3.4.jar/ ] either use fromURL(final URL url, final List<UrlType> urlTypes) or use the static setDefaultURLTypes(final List<UrlType> urlTypes) or addDefaultURLTypes(UrlType urlType) with your specialized UrlType. at org.reflections.vfs.Vfs.fromURL(Vfs.java:105) ~[reflections-0.9.6.jar!/:na] at org.reflections.vfs.Vfs.fromURL(Vfs.java:90) ~[reflections-0.9.6.jar!/:na] at org.reflections.Reflections.scan(Reflections.java:211) [reflections-0.9.6.jar!/:na] at org.reflections.Reflections.<init>(Reflections.java:103) [reflections-0.9.6.jar!/:na] at org.xwiki.extension.internal.DefaultExtensionLicenseManager.initialize(DefaultExtensionLicenseManager.java:84) [xwiki-platform-extension-api-3.4.jar!/:na] at org.xwiki.component.embed.InitializableLifecycleHandler.handle(InitializableLifecycleHandler.java:39) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:295) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:358) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:324) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:147) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:281) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:358) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:324) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:147) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:281) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:358) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:324) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:147) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:281) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:358) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:324) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:147) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:281) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:358) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:324) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:147) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:281) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:358) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.lookupMap(EmbeddableComponentManager.java:171) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.lookupList(EmbeddableComponentManager.java:155) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.internal.DefaultComponentManager.lookupList(DefaultComponentManager.java:84) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.observation.internal.DefaultObservationManager.initialize(DefaultObservationManager.java:142) [xwiki-commons-observation-local-3.4.jar!/:na] at org.xwiki.component.embed.InitializableLifecycleHandler.handle(InitializableLifecycleHandler.java:39) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:295) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:358) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:324) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:141) [xwiki-commons-component-default-3.4.jar!/:na] at org.xwiki.container.servlet.XWikiServletContextListener.contextInitialized(XWikiServletContextListener.java:73) [xwiki-platform-container-servlet-3.4.jar!/:na] at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910) [jbossweb.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.apache.catalina.core.StandardContext.start(StandardContext.java:4393) [jbossweb.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:310) [jboss-web-service.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142) [jboss-web-service.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461) [jboss.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118) [jboss.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.jboss.web.deployers.WebModule.start(WebModule.java:97) [jboss.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.6.0_16] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) ~[na:1.6.0_16] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) ~[na:1.6.0_16] at java.lang.reflect.Method.invoke(Method.java:597) ~[na:1.6.0_16] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) [jboss-mbeans.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [jboss-mbeans.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [jboss-mbeans.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) [jboss-mbeans.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) [jboss-jmx.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206) [jboss-system-jmx.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at $Proxy38.start(Unknown Source) [na:na] at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42) [jboss-system-jmx.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37) [jboss-system-jmx.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.0.6.GA] at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.0.6.GA] at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.0.6.GA] at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) [jboss-dependency.jar:2.0.6.GA] at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:286) [jboss-system-jmx.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631) [jboss-dependency.jar:2.0.6.GA] at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934) [jboss-dependency.jar:2.0.6.GA] at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082) [jboss-dependency.jar:2.0.6.GA] at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984) [jboss-dependency.jar:2.0.6.GA] at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822) [jboss-dependency.jar:2.0.6.GA] at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) [jboss-dependency.jar:2.0.6.GA] at org.jboss.system.ServiceController.doChange(ServiceController.java:688) [jboss-system-jmx.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.jboss.system.ServiceController.start(ServiceController.java:460) [jboss-system-jmx.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163) [jboss-system-jmx.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99) [jboss-system-jmx.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46) [jboss-system-jmx.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) [jboss-deployers-spi.jar!/:2.0.7.GA] at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50) [jboss-deployers-spi.jar!/:2.0.7.GA] at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171) [jboss-deployers-impl.jar!/:2.0.7.GA] at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439) [jboss-deployers-impl.jar!/:2.0.7.GA] at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157) [jboss-deployers-impl.jar!/:2.0.7.GA] at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178) [jboss-deployers-impl.jar!/:2.0.7.GA] at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098) [jboss-deployers-impl.jar!/:2.0.7.GA] at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) [jboss-dependency.jar:2.0.6.GA] at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631) [jboss-dependency.jar:2.0.6.GA] at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934) [jboss-dependency.jar:2.0.6.GA] at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082) [jboss-dependency.jar:2.0.6.GA] at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984) [jboss-dependency.jar:2.0.6.GA] at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822) [jboss-dependency.jar:2.0.6.GA] at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) [jboss-dependency.jar:2.0.6.GA] at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781) [jboss-deployers-impl.jar!/:2.0.7.GA] at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702) [jboss-deployers-impl.jar!/:2.0.7.GA] at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117) [jboss-system.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70) [jboss-system.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53) [jboss-system.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361) [jboss-system.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) [jboss-dependency.jar:2.0.6.GA] at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631) [jboss-dependency.jar:2.0.6.GA] at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934) [jboss-dependency.jar:2.0.6.GA] at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082) [jboss-dependency.jar:2.0.6.GA] at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984) [jboss-dependency.jar:2.0.6.GA] at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822) [jboss-dependency.jar:2.0.6.GA] at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) [jboss-dependency.jar:2.0.6.GA] at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306) [jboss-system.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271) [jboss-system.jar!/:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461) [jboss-bootstrap.jar:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.jboss.Main.boot(Main.java:221) [run.jar:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at org.jboss.Main$1.run(Main.java:556) [run.jar:5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] at java.lang.Thread.run(Thread.java:619) [na:1.6.0_16]

13 years, 11 months

1
0
0 0

Re: [xwiki-users] Workspace manager free default pages set

by Haru Mamburu

Thank you Eduard, Sorry, probably I wasn't clear in my questions... - I want to use WORKSPACE Manager on MAIN Wiki and manage them as designed. - BUT, the same time I want to use WIKI Manager to have completely independent from main wiki and other workspaces virtual wikis. So, I set up XEM, installed Workspace manager to play around AND with Wiki Manager created virtual Wiki. Now I completely stuck how to get rid of all Workspace Manager links in wiki farm (!) (not workspaces). I would prefer to keep running Workspace Manager on main Wiki AND Wiki farm simultaneously, if possible. Is there any simple solution? The only thing I suppose should work is to take *.vm files from XE and attach them to the skin file. Looks wierd and unpredictable for me :-( Kind Regards, Dmitry 27 января 2012, 14:26 от Eduard Moraru <enygma2002(a)gmail.com>: Hi Dmitry, Starting with 3.3, XEM has moved the main usecase for subwikis from farm to workspaces. This means that, additionally to the WikiManager application [1], now XEM also contains the Workspace Application [2]. The encouraged way of for creating a wiki farm right now (if that is really what you need) is to get XE, install WikiManager [1] and create your farm. If you *insist* on using XEM for creating a wiki farm, all you have to do is delete the WorkspaceManager space, thus removing the Workspaces application and disabling the extra menus that were getting in your way. Additionally, you should also remove the xwiki-platform-workspace-api-<version>.jar file from the /webapps/xwiki/WEB-INF/lib/ folder, since you don`t want to use it anymore and you have removed the UI. However, if your plan is to have global users that work on different subwikis (like an intranet with departments mapped to subwikis or a place where you work on projects mapped to subwikis, etc.), you might reconsider using Workspaces. In any case, I hope this solves your problem. Thanks, Eduard ----------------- References: [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Wiki+Manager+Applicati… [2] http://extensions.xwiki.org/xwiki/bin/view/Extension/Workspace+Application On Fri, Jan 27, 2012 at 11:57 AM, Haru Mamburu <haru_mamburu(a)mail.ru> wrote: Ooops, wrong solution. The problem is still active: is there a right way to get rid of Workspace Manager's links in virtual wikis in 3.4? 27 января 2012, 13:46 от Haru Mamburu <haru_mamburu(a)mail.ru>: > Hi All, > > By accident I found a soluion. For me it looks a bit wierd. > > If you set in xwiki.cfg xwiki.virtual.usepath to 0, then all menus become Workspace Manager links free. > > For now, if I want to use usepath and don't want to use Workspace Manager, there is no an "one click solution" :-( > > Is it a bug or it's a feature? Should I report it? > > Kind regards, > > Dmitry > > 27 января 2012, 01:34 от Haru Mamburu <haru_mamburu(a)mail.ru>: > > Hi. all! > > > > XEM 3.4. Main Wiki works fine. > > > > I want to set up virtual wiki without Workspace Manager application inside and it's links in menu, because as far as I inderstood it is useless in virtual wikis. > > > > What is right way to get rid of Workspace Manager and it's links in top menu in virtual wiki? > > > > Kind regards, > > > > Dmitry _______________________________________________ users mailing list users(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/users

13 years, 11 months

3
2
0 0

Re: [xwiki-users] Workspace manager free default pages set

by Haru Mamburu

Ooops, wrong solution. The problem is still active: is there a right way to get rid of Workspace Manager's links in virtual wikis in 3.4? 27 января 2012, 13:46 от Haru Mamburu <haru_mamburu(a)mail.ru>: > Hi All, > > By accident I found a soluion. For me it looks a bit wierd. > > If you set in xwiki.cfg xwiki.virtual.usepath to 0, then all menus become Workspace Manager links free. > > For now, if I want to use usepath and don't want to use Workspace Manager, there is no an "one click solution" :-( > > Is it a bug or it's a feature? Should I report it? > > Kind regards, > > Dmitry > > 27 января 2012, 01:34 от Haru Mamburu <haru_mamburu(a)mail.ru>: > > Hi. all! > > > > XEM 3.4. Main Wiki works fine. > > > > I want to set up virtual wiki without Workspace Manager application inside and it's links in menu, because as far as I inderstood it is useless in virtual wikis. > > > > What is right way to get rid of Workspace Manager and it's links in top menu in virtual wiki? > > > > Kind regards, > > > > Dmitry

13 years, 11 months

2
1
0 0

Re: [xwiki-users] Workspace manager free default pages set

by Haru Mamburu

Hi All, By accident I found a soluion. For me it looks a bit wierd. If you set in xwiki.cfg xwiki.virtual.usepath to 0, then all menus become Workspace Manager links free. For now, if I want to use usepath and don't want to use Workspace Manager, there is no an "one click solution" :-( Is it a bug or it's a feature? Should I report it? Kind regards, Dmitry 27 января 2012, 01:34 от Haru Mamburu <haru_mamburu(a)mail.ru>: > Hi. all! > > XEM 3.4. Main Wiki works fine. > > I want to set up virtual wiki without Workspace Manager application inside and it's links in menu, because as far as I inderstood it is useless in virtual wikis. > > What is right way to get rid of Workspace Manager and it's links in top menu in virtual wiki? > > Kind regards, > > Dmitry

13 years, 11 months

1
0
0 0

[xwiki-users] Workspace manager free default pages set

by Haru Mamburu

Hi. all! XEM 3.4. Main Wiki works fine. I want to set up virtual wiki without Workspace Manager application inside and it's links in menu, because as far as I inderstood it is useless in virtual wikis. What is right way to get rid of Workspace Manager and it's links in top menu in virtual wiki? Kind regards, Dmitry

13 years, 11 months

1
0
0 0

[xwiki-users] Call for test Extension Manager

by Thomas Mortagne

Hi xwikiers, I just add clustering support which was the last big peace of framework that was blocking a first fully functional version of Extension Manager. I will now dedicate my time to write tests and fix bugs and small improvements I find and try to fix some UI bugs too if Sergiu does not have time. I also have some improvement work in XWiki Repository and finally make extension.xwiki.org fully based on standard XWiki Repository and not have custom version anymore. During the 3.5 and 4.0 timeframe it would be nice to get as much tests and reports as possible on what is not working or still blocker in term or usability so that we get a nice and strong first version we can advertise in 4.0. There is obviously lots of possible improvements some of which you can find on http://dev.xwiki.org/xwiki/bin/view/Design/ExtensionManager (and I need to add more things in there) but I would like to limit to a fully working minimum for 4.0 and then do a priority survey on the many new features and improvements ideas. Here are the grey areas I know about and on which I'm going to concentrate on writing tests: * automatic xar merging is a quick implementation not excessively tested. Also the string properties content merging is not able to merge modification done on the same line which is not nice when things like the title is customized in the wiki and also changed in the new version of the xar. Right now in doubt the merge always take the new version when there is a conflict so that nothing is lost since it's easy to get back the previous version from the history. Also I'm not going to have time to work on a real manual conflict resolution UI for this timeframe, not alone at least. * clustering is a bit young ;) Also it expect all members to have the exact same constraints, if for any reason an extension is installed to a member and fail on another it could create quite a mess if that's an important extension. * it's not very hard to add versions and dependencies in XWiki Repository but it require using object editor which is not very nice for all profiles of users (now it's generally done by the developer of the extension so not a basic user either). Will try to work on that if I have some time left. Thanks, -- Thomas Mortagne

13 years, 11 months

1
1
0 0

Re: [xwiki-users] Inserting links to files on network drives

by goldring, richard

Still can't open the attachments using WebDAV in Windows Explorer - can see the files BUT there's no Open menu option when I right click them. Have tried goggling this but haven't yet found anything on why this is or how to enable it so can open the attachment .... Anyone any idea what to do??? Richard -----Original Message----- From: users-bounces(a)xwiki.org [mailto:users-bounces@xwiki.org] On Behalf Of goldring, richard Sent: 25 January 2012 12:06 To: 'XWiki Users' Subject: Re: [xwiki-users] Inserting links to files on network drives Vincent, Thanks for the suggestion - I've managed to view the attachments in Windows XP file browser ... but I can't edit them - how do I config it so I can edit the file??? Regards, Richard -----Original Message----- From: users-bounces(a)xwiki.org [mailto:users-bounces@xwiki.org] On Behalf Of Vincent Massol Sent: 25 January 2012 10:50 To: XWiki Users Subject: Re: [xwiki-users] Inserting links to files on network drives Hi Richard, On Jan 25, 2012, at 11:28 AM, goldring, richard wrote: > Hi, > > Managers and other users at my company like to update excel > spreadsheets on work progress. These spreadsheets get updated quite > frequently by many users so attaching them to the wiki isn't so > practical because of the overhead of checking checking the attachments > in and out. > > So I'd like to make it easier for managers to put in links to these > spreadsheets from a wiki page: So the users can (from the wiki > WYSIWYG > editor) browse to the spreadsheet files and insert them without having > to workout the syntax e.g. file:// and the network drive, etc. > > How might I go about editing/adding macros to do this? The solution we propose for this is WebDAV (search xwiki.org on webdav). Mount your wiki as a webdav driver. This allows you to see the attachments for example. Work in your favorite editor for those attachments. When you save in your editor the attachment is updated remotely. The only possible issue is with concurrent locking. It's possible that if one has the lock others will only be able to open the attachment in read only. To be tested. Let us know! Thanks -Vincent _______________________________________________ users mailing list users(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/users _______________________________________________ users mailing list users(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/users

13 years, 11 months

1
0
0 0

[xwiki-users] Inserting links to files on network drives

by goldring, richard

Hi, Managers and other users at my company like to update excel spreadsheets on work progress. These spreadsheets get updated quite frequently by many users so attaching them to the wiki isn't so practical because of the overhead of checking checking the attachments in and out. So I'd like to make it easier for managers to put in links to these spreadsheets from a wiki page: So the users can (from the wiki WYSIWYG editor) browse to the spreadsheet files and insert them without having to workout the syntax e.g. file:// and the network drive, etc. How might I go about editing/adding macros to do this? Thanks. Regards, Richard

13 years, 11 months

5
4
0 0

Re: [xwiki-users] Inserting links to files on network drives

by goldring, richard

Vincent, Thanks for the suggestion - I've managed to view the attachments in Windows XP file browser ... but I can't edit them - how do I config it so I can edit the file??? Regards, Richard -----Original Message----- From: users-bounces(a)xwiki.org [mailto:users-bounces@xwiki.org] On Behalf Of Vincent Massol Sent: 25 January 2012 10:50 To: XWiki Users Subject: Re: [xwiki-users] Inserting links to files on network drives Hi Richard, On Jan 25, 2012, at 11:28 AM, goldring, richard wrote: > Hi, > > Managers and other users at my company like to update excel > spreadsheets on work progress. These spreadsheets get updated quite > frequently by many users so attaching them to the wiki isn't so > practical because of the overhead of checking checking the attachments in and out. > > So I'd like to make it easier for managers to put in links to these > spreadsheets from a wiki page: So the users can (from the wiki > WYSIWYG > editor) browse to the spreadsheet files and insert them without having > to workout the syntax e.g. file:// and the network drive, etc. > > How might I go about editing/adding macros to do this? The solution we propose for this is WebDAV (search xwiki.org on webdav). Mount your wiki as a webdav driver. This allows you to see the attachments for example. Work in your favorite editor for those attachments. When you save in your editor the attachment is updated remotely. The only possible issue is with concurrent locking. It's possible that if one has the lock others will only be able to open the attachment in read only. To be tested. Let us know! Thanks -Vincent _______________________________________________ users mailing list users(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/users

13 years, 11 months

1
0
0 0

[xwiki-users] Status of filesystem attachment storage.

by Ryszard Łach

Hi. Could anyone, please, give any info about status of filesystem attachment storage? Is it stable? Does it deal with non-ascii filenames prolerply? If so - why in 3.4 versions default storage for attachments will be hibernate? Cheers, R. --

13 years, 11 months

6
6
0 0

Re: [xwiki-users] Font size, heading, section colouring

by goldring, richard

Thanks - tried the bug but didn't seem to work - tried editing the object directly and got it working - thanks!!! Is this fixed in the next release?? R -----Original Message----- From: users-bounces(a)xwiki.org [mailto:users-bounces@xwiki.org] On Behalf Of Marius Dumitru Florea Sent: 24 January 2012 17:11 To: XWiki Users Subject: Re: [xwiki-users] Font size, heading, section colouring 2012/1/24 goldring, richard <richard.goldring(a)uk.thalesgroup.com>: > Thanks > > I've tried setting the WYSIWYS editor settings for the font and color > plugins on the Administation section in the wiki and saved the page > but when I go back the settings for font and color have disappeared - > what am I doing wrong?? You probably hit http://jira.xwiki.org/browse/XWIKI-7121 . Besides the fix specified in the comment you can edit directly in object mode the page holding the WYSIWYG editor configuration, XWiki.WysiwygEditorConfig, and change the configuration. Hope this helps, Marius > > -----Original Message----- > From: users-bounces(a)xwiki.org [mailto:users-bounces@xwiki.org] On > Behalf Of Marius Dumitru Florea > Sent: 23 January 2012 17:42 > To: XWiki Users > Subject: Re: [xwiki-users] Font size, heading, section colouring > > 2012/1/23 goldring, richard <richard.goldring(a)uk.thalesgroup.com>: >> Hi, >> > >> Does anyone know how or if its possible to change fonts sizes, style, >> colour and colour headings or sections to make them stand out on the page. > > Yes. Either through wiki syntax > http://platform.xwiki.org/xwiki/bin/view/Main/XWikiSyntax#HParameters > or through the WYSIWYG editor > http://platform.xwiki.org/xwiki/bin/view/Features/WysiwygEditor#HTextF > ormatt > ing > . For the later option you need to activate some WYSIWYG editor > plugins (e.g. font and color, see > http://platform.xwiki.org/xwiki/bin/view/AdminGuide/WysiwygEditor#HPlu > ginsan > dFeatures > for the full list) from the administration and add some features on > the WYSIWYG editor tool bar (e.g. fontname or forecolor). > > Hope this helps, > Marius > > P.S.: Next time please don't highjack someone else's thread. > >> >> Regards, >> >> Richard >> >> -----Original Message----- >> From: users-bounces(a)xwiki.org [mailto:users-bounces@xwiki.org] On >> Behalf Of Haru Mamburu >> Sent: 23 January 2012 16:14 >> To: XWiki Users >> Subject: Re: [xwiki-users] Version Error >> >> Looks like >> http://platform.xwiki.org/xwiki/bin/view/AdminGuide/InstallationMySQL >> # >> HHTTP5 >> 00Error >> >> Try this. Hope it will help. >> >> Kind Regards, >> >> Dmitry >> >> >> 23 января 2012, 20:10 от eparent_pk <eparent(a)photonicknowledge.com>: >>> Hi, >>> >>> I'm having the http://pastebin.com/k5V6mBha same error . >>> >>> My xwiki installation is Enterprise 3.3, on Ubuntu 11.10 (x64) >>> with tomcat6. >>> >>> I installed following the instructions on this >>> http://blog.dontneedcoffee.com/2010/02/install-xwiki-22-on-ubuntu-91 >>> 0 >>> - >>> mysql.html >>> site . >>> >>> Here is an example of my http://pastebin.com/HEPmAAeQ >>> hibernate.cfg.xml . >>> >>> I created MySQL user 'xwiki' who was granted with create, >>> insert, alter, delete entries for the xwiki database. >>> >>> All the setup tutorials I've seen are quite straight forward >>> but, for some reason, I just can't get it to work. Any hint / advice >>> will be appreciated. >>> >>> Cheers, >>> >>> - Eric >>> >>> -- >>> View this message in context: >>> http://xwiki.475771.n2.nabble.com/Version-Error-tp6480013p7216532.ht >>> m l Sent from the XWiki- Users mailing list archive at Nabble.com. >>> _______________________________________________ >>> users mailing list >>> users(a)xwiki.org >>> http://lists.xwiki.org/mailman/listinfo/users >>> >> _______________________________________________ >> users mailing list >> users(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/users >> _______________________________________________ >> users mailing list >> users(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/users > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users _______________________________________________ users mailing list users(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/users

13 years, 11 months

2
1
0 0

Re: [xwiki-users] Font size, heading, section colouring

by goldring, richard

Thanks I've tried setting the WYSIWYS editor settings for the font and color plugins on the Administation section in the wiki and saved the page but when I go back the settings for font and color have disappeared - what am I doing wrong?? -----Original Message----- From: users-bounces(a)xwiki.org [mailto:users-bounces@xwiki.org] On Behalf Of Marius Dumitru Florea Sent: 23 January 2012 17:42 To: XWiki Users Subject: Re: [xwiki-users] Font size, heading, section colouring 2012/1/23 goldring, richard <richard.goldring(a)uk.thalesgroup.com>: > Hi, > > Does anyone know how or if its possible to change fonts sizes, style, > colour and colour headings or sections to make them stand out on the page. Yes. Either through wiki syntax http://platform.xwiki.org/xwiki/bin/view/Main/XWikiSyntax#HParameters or through the WYSIWYG editor http://platform.xwiki.org/xwiki/bin/view/Features/WysiwygEditor#HTextFormatt ing . For the later option you need to activate some WYSIWYG editor plugins (e.g. font and color, see http://platform.xwiki.org/xwiki/bin/view/AdminGuide/WysiwygEditor#HPluginsan dFeatures for the full list) from the administration and add some features on the WYSIWYG editor tool bar (e.g. fontname or forecolor). Hope this helps, Marius P.S.: Next time please don't highjack someone else's thread. > > Regards, > > Richard > > -----Original Message----- > From: users-bounces(a)xwiki.org [mailto:users-bounces@xwiki.org] On > Behalf Of Haru Mamburu > Sent: 23 January 2012 16:14 > To: XWiki Users > Subject: Re: [xwiki-users] Version Error > > Looks like > http://platform.xwiki.org/xwiki/bin/view/AdminGuide/InstallationMySQL# > HHTTP5 > 00Error > > Try this. Hope it will help. > > Kind Regards, > > Dmitry > > > 23 января 2012, 20:10 от eparent_pk <eparent(a)photonicknowledge.com>: >> Hi, >> >> I'm having the http://pastebin.com/k5V6mBha same error . >> >> My xwiki installation is Enterprise 3.3, on Ubuntu 11.10 (x64) >> with tomcat6. >> >> I installed following the instructions on this >> http://blog.dontneedcoffee.com/2010/02/install-xwiki-22-on-ubuntu-910 >> - >> mysql.html >> site . >> >> Here is an example of my http://pastebin.com/HEPmAAeQ >> hibernate.cfg.xml . >> >> I created MySQL user 'xwiki' who was granted with create, insert, >> alter, delete entries for the xwiki database. >> >> All the setup tutorials I've seen are quite straight forward but, >> for some reason, I just can't get it to work. Any hint / advice will >> be appreciated. >> >> Cheers, >> >> - Eric >> >> -- >> View this message in context: >> http://xwiki.475771.n2.nabble.com/Version-Error-tp6480013p7216532.htm >> l Sent from the XWiki- Users mailing list archive at Nabble.com. >> _______________________________________________ >> users mailing list >> users(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/users >> > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users _______________________________________________ users mailing list users(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/users

13 years, 11 months

2
1
0 0

[xwiki-users] Selected pages of PDF to image conversion in XWiki?

by Haru Mamburu

Hi! The task is: - Calculate MD5 of attached PDF document - Extract e.g first 10 pages from the attached PDF file as images - store images as attachments into the document 1. What is the best way to calculate MD5 in XWiki? Is it possible to do via standard velocity scripting in XWiki? 2. Is there any built in/hidden ways of PDF->image conversion of several pages of attached PDF file? If not, what is the solution possible? I found some opensource JAVA libraries, but I realize a big gap in my understanding between libraries and their integration in XWiki with followng velocity scripting usage. Does anyone has a clue where to dig to make all this staff runnung? Thanks in advance, Dmitry

13 years, 11 months

1
0
0 0

[xwiki-users] How to Configure the search user functionality for a given user group?

by mohit gupta

Hi All, I have question regarding search functionality i want to give rights in a way so that the users in a certain group should be able search the users of a certain group. For example i have 3 groups G1,G2,G3 . G1 contains user U1,G2 contains user U2 and G3 contains user U3. Now i want to give the the group 1 users rights in a way so that they should be able to search the G1 and G2 users only but not G3 users. I know we can customize the rights of specific group user for a specific space but what about above feature? Is it configurable? Thanks .

13 years, 11 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-users