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 <enygma2...@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_mamb...@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 <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 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_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 > > (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 <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 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 <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? > > > > Thanks, > > Eduard > > > > 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, > > > > Dmitry > > > > > > 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. > > > > Thanks, > > Eduard > > > > ----------------- > > References: > > [1] > > http://extensions.xwiki.org/xwiki/bin/view/Extension/Wiki+Manager+Application > > [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@xwiki.org > > http://lists.xwiki.org/mailman/listinfo/users > > > > > > _______________________________________________ > > users mailing list > > users@xwiki.org > > http://lists.xwiki.org/mailman/listinfo/users > > > > > > _______________________________________________ > > users mailing list > > users@xwiki.org > > http://lists.xwiki.org/mailman/listinfo/users > > > > > > _______________________________________________ > > users mailing list > > users@xwiki.org > > http://lists.xwiki.org/mailman/listinfo/users > > > > > > _______________________________________________ > > users mailing list > > users@xwiki.org > > http://lists.xwiki.org/mailman/listinfo/users > > > _______________________________________________ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > _______________________________________________ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
