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 

"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?

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.


30 января 2012, 18:21 от Eduard Moraru <enygma2...@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 

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.


 On Sat, Jan 28, 2012 at 7:41 PM, Haru Mamburu <haru_mamb...@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 
Main Wiki              |   ..................................................
                             |  virtual wiki N - "Solo" - No Workspace Manager 
(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 

Hope, it would be nice idea for 4.0 roadmap to think over :-)

Best Regards,


28 января 2012, 00:53 от Eduard Moraru <enygma2...@gmail.com>:

Hello again,

Please see below...

On Fri, Jan 27, 2012 at 3:17 PM, Haru Mamburu <haru_mamb...@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 

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.


Kind Regards,


27 января 2012, 16:48 от Eduard Moraru <enygma2...@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?


On Fri, Jan 27, 2012 at 1:32 PM, Haru Mamburu <haru_mamb...@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,


27 января 2012, 14:26 от Eduard Moraru <enygma2...@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.


 [2] http://extensions.xwiki.org/xwiki/bin/view/Extension/Workspace+Application

On Fri, Jan 27, 2012 at 11:57 AM, Haru Mamburu <haru_mamb...@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_mamb...@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_mamb...@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 mailing list

users mailing list

users mailing list

users mailing list

Reply via email to