Re: [xwiki-users] Workspaces and group management + access rights bug?

Thanks a lot for clarification, Eduard! And what about http://jira.xwiki.org/browse/XWIKI-7530 http://jira.xwiki.org/browse/XWIKI-7521

Are you going to do it in 3.5 or it would be only in 4+ plans? Kind Regards Dmitry 14 февраля 2012, 16:11 от Eduard Moraru<enygma2002(a)gmail.com>om>: > Hi Dmitry, > > It's just a matter of rights management. > > This is the default (open) behaviour of Workspaces since that's XWiki's > policy as well. When you create a new workspace, it will allow all global > users and the guest user to view it, but not edit. When a user becomes a > member of the workspace, he will also get edit rights. > > If you want to change this for a single existing workspace, you can simply > go to Administration Workspace> Rights> Groups, select Both from the > Search Scope select input and there you will see that the main wiki > XWikiAllGroup has view rights checked. Uncheck the view right and leave it > as default to stop this from happening. Don`t forget to do the same for the > Unregistered User under the Users tab of the Rights management section. > > If you want to change this for all future workspaces that will be created, > go to the "workspacetemplate" wiki template as a global admin (you can use > WikiManager/WebHome to find it) and do the same thing that I just described > above, for the single workspace situation. Now all the new workspaces that > you will create will not be accessible to non-members. > > Minor note: Additionally, the Skin page, ColorThemes space and Panels space > are also set to explicitly allow view to global users and unregistered > users, so that, when a user lands on a restricted workspace, he can > properly see the skin and color theme that is currently set and he can also > see the workspace information panel that allows him to click (Request)Join > if the option is available. Of course, you can change that too by editing > the rights of the page and spaces (either in a workspace or in the > template), but that should not be necessary IMO. > > Thanks, > Eduard > > On Mon, Feb 13, 2012 at 11:13 PM, Dmitry Bakbardin<haru_mamburu(a)mail.ru>wrote;wrote: > >> oops... sorry Once again >> >> I found very strange IMO behaviour of access rights in 3.4 XEM. Access >> rights are simply ignored. >> >> How to reproduce: >> 1) Clean installation of 3.4 XEM >> 2) Default Admin creates "test" workspace >> 3) Test user in XWikiAllGroup in main wiki, not invited in Workspace "test" >> 4) The task was to restrict access to the workspace to test user. >> >> I failed to do this in all possible ways. If Test user is not in the >> workspace, I can't restrict access to him and workspace is ALWAYS visible >> to Test user. >> Access was restricted even to ALL XWikiAllGroup in Main Wiki. Works fine >> for main wiki, BUT, when you enter direct link >> like /xwiki/wiki/test/view/Main/WebHome it simply ignores all restrictions >> both on main wiki and workspace. >> >> So, as a result, there is no way to restrict access to users/group of >> users (or I didn't find it). E.g. I really don't like when my customers >> have an authorized access to "internal" staff :-))). >> From that point of view I either don't understand Workspace access rights >> management quite good, or it's not ready to use yet. >> >> Is it a bug, or it's a misused (by me) feature? >> >> Kind regards, >> >> Dmitry >> >> >> >> >> 14 февраля 2012, 00:04 от Dmitry Bakbardin<haru_mamburu(a)mail.ru>ru>: >> >> >> Hi, >> >> For now owner can invite users to workspace. Is there any possibility to >> invite GROUPS? >> >> I need following scenario: >> - Main Wiki Group A, B, C >> - Workspace "One" invites Group A, B and denies Group C to see workspace >> "One" >> - I register a new user and add it to group A >> - This user AUTOMATICALLY gains access/invitation to workspace. >> - I delete user from the Group A and user is rejected by workspace "one" >> also automatically >> >> Is there any simple way to do this? >> >> >> Kind regards, >> >> Dmitry >> >> Kind regards, >> >> Dmitry >>