[xwiki-devs] [ Proposal ] Remove XWiki.Admin from xwiki-platform-administration-ui
Issue : * Since XWiki.Admin is packaged in xwiki-platform-administration-ui, it comes with xwiki-enterprise-ui-wiki (which is the subwiki default UI). * XWiki.Admin is a member of XWiki.XWikiAdminGroup and XWiki.XWikiAllGroup, which are also bundled in xwiki-platform-administration-ui. * WorkspaceManager.Install removes XWiki.Admin from workspacetemplate, in order to not have local admin in new workspaces. * When we upgrade subwikis, DW does not install XWiki.Admin (DW is aware that the user has been intentionally removed), but the merge of XWiki.XWikIAllGroup does no work well : it add XWiki.Admin to the group. * That leads us to: http://jira.xwiki.org/browse/XWIKI-9501 (The local admin does not exist, but she is a member of XWiki.XWikiAllGroup). + I think the WorkspaceManager.Install trick is not clean. My proposal is to *move XWiki.Admin to XE mainwiki*. But it breaks the *functional tests* that needs to *log-in as *an admin. It can be solved by using the *superadmin*! + When DW does the first install, it should use superadmin too, so all default macros come with the rights of superadmin. Here is my +1. Thanks, Louis-Marie
+1 On Thu, Sep 26, 2013 at 3:05 PM, Guillaume "Louis-Marie" Delhumeau <[email protected]> wrote:
Issue : * Since XWiki.Admin is packaged in xwiki-platform-administration-ui, it comes with xwiki-enterprise-ui-wiki (which is the subwiki default UI). * XWiki.Admin is a member of XWiki.XWikiAdminGroup and XWiki.XWikiAllGroup, which are also bundled in xwiki-platform-administration-ui. * WorkspaceManager.Install removes XWiki.Admin from workspacetemplate, in order to not have local admin in new workspaces. * When we upgrade subwikis, DW does not install XWiki.Admin (DW is aware that the user has been intentionally removed), but the merge of XWiki.XWikIAllGroup does no work well : it add XWiki.Admin to the group. * That leads us to: http://jira.xwiki.org/browse/XWIKI-9501 (The local admin does not exist, but she is a member of XWiki.XWikiAllGroup).
+ I think the WorkspaceManager.Install trick is not clean.
My proposal is to *move XWiki.Admin to XE mainwiki*.
But it breaks the *functional tests* that needs to *log-in as *an admin. It can be solved by using the *superadmin*!
+ When DW does the first install, it should use superadmin too, so all default macros come with the rights of superadmin.
Here is my +1.
Thanks, Louis-Marie _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hi Guillaume, IMO the XWiki.Admin user should not be any where, in any package since this could cause more trouble than it solve, like leaving an admin account unsecured, resetting password of the admin account, etc... IMO, this is the job of the DW to propose the creation of an admin account when appropriate and securing it properly immediately. So, if you go for this change, I think removing it would not require more work, apart from the DW adaptation and it could be adapted depending of the usage (workspace or farm). WDYT ? On Thu, Sep 26, 2013 at 3:05 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:
Issue : * Since XWiki.Admin is packaged in xwiki-platform-administration-ui, it comes with xwiki-enterprise-ui-wiki (which is the subwiki default UI). * XWiki.Admin is a member of XWiki.XWikiAdminGroup and XWiki.XWikiAllGroup, which are also bundled in xwiki-platform-administration-ui. * WorkspaceManager.Install removes XWiki.Admin from workspacetemplate, in order to not have local admin in new workspaces. * When we upgrade subwikis, DW does not install XWiki.Admin (DW is aware that the user has been intentionally removed), but the merge of XWiki.XWikIAllGroup does no work well : it add XWiki.Admin to the group. * That leads us to: http://jira.xwiki.org/browse/XWIKI-9501 (The local admin does not exist, but she is a member of XWiki.XWikiAllGroup).
+ I think the WorkspaceManager.Install trick is not clean.
My proposal is to *move XWiki.Admin to XE mainwiki*.
But it breaks the *functional tests* that needs to *log-in as *an admin. It can be solved by using the *superadmin*!
+ When DW does the first install, it should use superadmin too, so all default macros come with the rights of superadmin.
Here is my +1.
Thanks, Louis-Marie _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Thu, Sep 26, 2013 at 3:19 PM, Denis Gervalle <[email protected]> wrote:
Hi Guillaume,
IMO the XWiki.Admin user should not be any where, in any package since this could cause more trouble than it solve, like leaving an admin account unsecured, resetting password of the admin account, etc...
IMO, this is the job of the DW to propose the creation of an admin account when appropriate and securing it properly immediately.
So, if you go for this change, I think removing it would not require more work, apart from the DW adaptation and it could be adapted depending of the usage (workspace or farm). WDYT ?
Sure ideally that's what should be done, I would put +1 if I was not going to be the one that will have to do it ;)
On Thu, Sep 26, 2013 at 3:05 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:
Issue : * Since XWiki.Admin is packaged in xwiki-platform-administration-ui, it comes with xwiki-enterprise-ui-wiki (which is the subwiki default UI). * XWiki.Admin is a member of XWiki.XWikiAdminGroup and XWiki.XWikiAllGroup, which are also bundled in xwiki-platform-administration-ui. * WorkspaceManager.Install removes XWiki.Admin from workspacetemplate, in order to not have local admin in new workspaces. * When we upgrade subwikis, DW does not install XWiki.Admin (DW is aware that the user has been intentionally removed), but the merge of XWiki.XWikIAllGroup does no work well : it add XWiki.Admin to the group. * That leads us to: http://jira.xwiki.org/browse/XWIKI-9501 (The local admin does not exist, but she is a member of XWiki.XWikiAllGroup).
+ I think the WorkspaceManager.Install trick is not clean.
My proposal is to *move XWiki.Admin to XE mainwiki*.
But it breaks the *functional tests* that needs to *log-in as *an admin. It can be solved by using the *superadmin*!
+ When DW does the first install, it should use superadmin too, so all default macros come with the rights of superadmin.
Here is my +1.
Thanks, Louis-Marie _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Sep 26, 2013, at 3:05 PM, Guillaume Louis-Marie Delhumeau <[email protected]> wrote:
Issue : * Since XWiki.Admin is packaged in xwiki-platform-administration-ui, it comes with xwiki-enterprise-ui-wiki (which is the subwiki default UI). * XWiki.Admin is a member of XWiki.XWikiAdminGroup and XWiki.XWikiAllGroup, which are also bundled in xwiki-platform-administration-ui.
I agree that the Admin user shouldn't be in platform and ideally not anywhere at all. However: * It needs to continue being simple for the user so indeed we would need the DW to create the Admin user on first start rather than forcing the user to edit xwiki.cfg to enable superadin * I'm slightly worried that functional tests are going to be executed with the superadmin user since we're not going to test some security code (we have special handling for superadmin). So another approach would be to create an Admin user for the tests that require one (makes the test a bit longer though but it's necessary for some tests anyway since some go to the user profile page to make changes and the superadmin user doesn't have a profile page ;)) I also agree that it's nicer to have default pages marked as created by superadmin rather than Admin. I hope it doesn't cause any issue though. So all in all, +1 from me too. Now, should we do this for 5.2 (I'm talking only about the move and not the change for DW which can be done after 5.2). It's already late and this represents some risks… WDYT? Thanks -Vincent
* WorkspaceManager.Install removes XWiki.Admin from workspacetemplate, in order to not have local admin in new workspaces. * When we upgrade subwikis, DW does not install XWiki.Admin (DW is aware that the user has been intentionally removed), but the merge of XWiki.XWikIAllGroup does no work well : it add XWiki.Admin to the group. * That leads us to: http://jira.xwiki.org/browse/XWIKI-9501 (The local admin does not exist, but she is a member of XWiki.XWikiAllGroup).
+ I think the WorkspaceManager.Install trick is not clean.
My proposal is to *move XWiki.Admin to XE mainwiki*.
But it breaks the *functional tests* that needs to *log-in as *an admin. It can be solved by using the *superadmin*!
+ When DW does the first install, it should use superadmin too, so all default macros come with the rights of superadmin.
Here is my +1.
Thanks, Louis-Marie
+1 too, but we need to update the tests if we want it in 5.2. Thanks, Marius On Thu, Sep 26, 2013 at 4:46 PM, Vincent Massol <[email protected]> wrote:
On Sep 26, 2013, at 3:05 PM, Guillaume Louis-Marie Delhumeau <[email protected]> wrote:
Issue : * Since XWiki.Admin is packaged in xwiki-platform-administration-ui, it comes with xwiki-enterprise-ui-wiki (which is the subwiki default UI). * XWiki.Admin is a member of XWiki.XWikiAdminGroup and XWiki.XWikiAllGroup, which are also bundled in xwiki-platform-administration-ui.
I agree that the Admin user shouldn't be in platform and ideally not anywhere at all.
However: * It needs to continue being simple for the user so indeed we would need the DW to create the Admin user on first start rather than forcing the user to edit xwiki.cfg to enable superadin * I'm slightly worried that functional tests are going to be executed with the superadmin user since we're not going to test some security code (we have special handling for superadmin). So another approach would be to create an Admin user for the tests that require one (makes the test a bit longer though but it's necessary for some tests anyway since some go to the user profile page to make changes and the superadmin user doesn't have a profile page ;))
I also agree that it's nicer to have default pages marked as created by superadmin rather than Admin. I hope it doesn't cause any issue though.
So all in all, +1 from me too.
Now, should we do this for 5.2 (I'm talking only about the move and not the change for DW which can be done after 5.2). It's already late and this represents some risks…
WDYT?
Thanks -Vincent
* WorkspaceManager.Install removes XWiki.Admin from workspacetemplate, in order to not have local admin in new workspaces. * When we upgrade subwikis, DW does not install XWiki.Admin (DW is aware that the user has been intentionally removed), but the merge of XWiki.XWikIAllGroup does no work well : it add XWiki.Admin to the group. * That leads us to: http://jira.xwiki.org/browse/XWIKI-9501 (The local admin does not exist, but she is a member of XWiki.XWikiAllGroup).
+ I think the WorkspaceManager.Install trick is not clean.
My proposal is to *move XWiki.Admin to XE mainwiki*.
But it breaks the *functional tests* that needs to *log-in as *an admin. It can be solved by using the *superadmin*!
+ When DW does the first install, it should use superadmin too, so all default macros come with the rights of superadmin.
Here is my +1.
Thanks, Louis-Marie
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
IMO it's too big for 5.2 and not needed for http://jira.xwiki.org/browse/XWIKI-9501 anyway. On Thu, Sep 26, 2013 at 5:37 PM, Marius Dumitru Florea <[email protected]> wrote:
+1 too, but we need to update the tests if we want it in 5.2.
Thanks, Marius
On Thu, Sep 26, 2013 at 4:46 PM, Vincent Massol <[email protected]> wrote:
On Sep 26, 2013, at 3:05 PM, Guillaume Louis-Marie Delhumeau <[email protected]> wrote:
Issue : * Since XWiki.Admin is packaged in xwiki-platform-administration-ui, it comes with xwiki-enterprise-ui-wiki (which is the subwiki default UI). * XWiki.Admin is a member of XWiki.XWikiAdminGroup and XWiki.XWikiAllGroup, which are also bundled in xwiki-platform-administration-ui.
I agree that the Admin user shouldn't be in platform and ideally not anywhere at all.
However: * It needs to continue being simple for the user so indeed we would need the DW to create the Admin user on first start rather than forcing the user to edit xwiki.cfg to enable superadin * I'm slightly worried that functional tests are going to be executed with the superadmin user since we're not going to test some security code (we have special handling for superadmin). So another approach would be to create an Admin user for the tests that require one (makes the test a bit longer though but it's necessary for some tests anyway since some go to the user profile page to make changes and the superadmin user doesn't have a profile page ;))
I also agree that it's nicer to have default pages marked as created by superadmin rather than Admin. I hope it doesn't cause any issue though.
So all in all, +1 from me too.
Now, should we do this for 5.2 (I'm talking only about the move and not the change for DW which can be done after 5.2). It's already late and this represents some risks…
WDYT?
Thanks -Vincent
* WorkspaceManager.Install removes XWiki.Admin from workspacetemplate, in order to not have local admin in new workspaces. * When we upgrade subwikis, DW does not install XWiki.Admin (DW is aware that the user has been intentionally removed), but the merge of XWiki.XWikIAllGroup does no work well : it add XWiki.Admin to the group. * That leads us to: http://jira.xwiki.org/browse/XWIKI-9501 (The local admin does not exist, but she is a member of XWiki.XWikiAllGroup).
+ I think the WorkspaceManager.Install trick is not clean.
My proposal is to *move XWiki.Admin to XE mainwiki*.
But it breaks the *functional tests* that needs to *log-in as *an admin. It can be solved by using the *superadmin*!
+ When DW does the first install, it should use superadmin too, so all default macros come with the rights of superadmin.
Here is my +1.
Thanks, Louis-Marie
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Thu, Sep 26, 2013 at 3:46 PM, Vincent Massol <[email protected]> wrote:
On Sep 26, 2013, at 3:05 PM, Guillaume Louis-Marie Delhumeau <[email protected]> wrote:
Issue : * Since XWiki.Admin is packaged in xwiki-platform-administration-ui, it comes with xwiki-enterprise-ui-wiki (which is the subwiki default UI). * XWiki.Admin is a member of XWiki.XWikiAdminGroup and XWiki.XWikiAllGroup, which are also bundled in xwiki-platform-administration-ui.
I agree that the Admin user shouldn't be in platform and ideally not anywhere at all.
However: * It needs to continue being simple for the user so indeed we would need the DW to create the Admin user on first start rather than forcing the user to edit xwiki.cfg to enable superadin
* I'm slightly worried that functional tests are going to be executed with the superadmin user since we're not going to test some security code (we have special handling for superadmin). So another approach would be to create an Admin user for the tests that require one (makes the test a bit longer though but it's necessary for some tests anyway since some go to the user profile page to make changes and the superadmin user doesn't have a profile page ;))
Admin user has programming right so it has no difference with superadmin.
I also agree that it's nicer to have default pages marked as created by superadmin rather than Admin. I hope it doesn't cause any issue though.
So all in all, +1 from me too.
Now, should we do this for 5.2 (I'm talking only about the move and not the change for DW which can be done after 5.2). It's already late and this represents some risks…
WDYT?
Thanks -Vincent
* WorkspaceManager.Install removes XWiki.Admin from workspacetemplate, in order to not have local admin in new workspaces. * When we upgrade subwikis, DW does not install XWiki.Admin (DW is aware that the user has been intentionally removed), but the merge of XWiki.XWikIAllGroup does no work well : it add XWiki.Admin to the group. * That leads us to: http://jira.xwiki.org/browse/XWIKI-9501 (The local admin does not exist, but she is a member of XWiki.XWikiAllGroup).
+ I think the WorkspaceManager.Install trick is not clean.
My proposal is to *move XWiki.Admin to XE mainwiki*.
But it breaks the *functional tests* that needs to *log-in as *an admin. It can be solved by using the *superadmin*!
+ When DW does the first install, it should use superadmin too, so all default macros come with the rights of superadmin.
Here is my +1.
Thanks, Louis-Marie
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Thu, Sep 26, 2013 at 3:46 PM, Vincent Massol <[email protected]> wrote:
On Sep 26, 2013, at 3:05 PM, Guillaume Louis-Marie Delhumeau < [email protected]> wrote:
Issue : * Since XWiki.Admin is packaged in xwiki-platform-administration-ui, it comes with xwiki-enterprise-ui-wiki (which is the subwiki default UI). * XWiki.Admin is a member of XWiki.XWikiAdminGroup and XWiki.XWikiAllGroup, which are also bundled in xwiki-platform-administration-ui.
I agree that the Admin user shouldn't be in platform and ideally not anywhere at all.
However: * It needs to continue being simple for the user so indeed we would need the DW to create the Admin user on first start rather than forcing the user to edit xwiki.cfg to enable superadin * I'm slightly worried that functional tests are going to be executed with the superadmin user since we're not going to test some security code (we have special handling for superadmin). So another approach would be to create an Admin user for the tests that require one (makes the test a bit longer though but it's necessary for some tests anyway since some go to the user profile page to make changes and the superadmin user doesn't have a profile page ;))
Except for tests that are focused on checking the Admin receive proper right and of course those acting on the profile page, I do not think executing additional security code in tests would be useful, even worse, it could cause performance penalty.
I also agree that it's nicer to have default pages marked as created by superadmin rather than Admin. I hope it doesn't cause any issue though.
So all in all, +1 from me too.
Now, should we do this for 5.2 (I'm talking only about the move and not the change for DW which can be done after 5.2). It's already late and this represents some risks…
I am -0 doing it half way, and for 5.2 almost -1. +1 to do it properly for 5.3
WDYT?
Thanks -Vincent
* WorkspaceManager.Install removes XWiki.Admin from workspacetemplate, in order to not have local admin in new workspaces. * When we upgrade subwikis, DW does not install XWiki.Admin (DW is aware that the user has been intentionally removed), but the merge of XWiki.XWikIAllGroup does no work well : it add XWiki.Admin to the group. * That leads us to: http://jira.xwiki.org/browse/XWIKI-9501 (The local admin does not exist, but she is a member of XWiki.XWikiAllGroup).
+ I think the WorkspaceManager.Install trick is not clean.
My proposal is to *move XWiki.Admin to XE mainwiki*.
But it breaks the *functional tests* that needs to *log-in as *an admin. It can be solved by using the *superadmin*!
+ When DW does the first install, it should use superadmin too, so all default macros come with the rights of superadmin.
Here is my +1.
Thanks, Louis-Marie
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
participants (5)
-
Denis Gervalle -
Guillaume "Louis-Marie" Delhumeau -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol