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_mamb...@mail.ru>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_mamb...@mail.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
>
>
> 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

Reply via email to