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 <[email protected]>:
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
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
Kind regards, Dmitry
On 02/14/2012 04:38 PM, Dmitry Bakbardin wrote:
Thanks a lot for clarification, Eduard!
And what about http://jira.xwiki.org/browse/XWIKI-7530 http://jira.xwiki.org/browse/XWIKI-7521
XWIKI-7521 isn't going to happen in 3.5. It is not a bug, since this is the intended behavior. When a particular right is set for a user, it's supposed to be read as: "Adam is the one that's allowed to edit this page!" not as: "Fine, Adam can edit this page as well..." So, according to the desired logic, there's no bug, so there's nothing to "fix" for 3.5. It would be a very big behavior change that would break a lot of existing rights configurations. I'm not saying that it will always be like this. A big rewrite of the rights mechanism is going to happen soon.
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<[email protected]>:
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
-- Sergiu Dumitriu http://purl.org/net/sergiu/
participants (2)
-
Dmitry Bakbardin -
Sergiu Dumitriu