1 Feb
2012
1 Feb
'12
4:30 p.m.
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>om>:
> 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>om>:
> >
> >
> > 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>om>:
> >
> >
> > 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>om>:
> >
> >
> > 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>om>:
> >
> >
> > 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>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>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
>