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 <[email protected]>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 <[email protected]>:

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

Kind regards,

Dmitry _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users