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
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