On Fri, Aug 7, 2009 at 11:32 PM, Christian Ribeaud < [email protected]> wrote:
> Because the mailing list does not seem to accept attached images, here > the link > to the screenshot: > > > http://www.ribeaud.ch/tmp/xwiki.png I believe this problem can be "fixed" by "hand editing" the "Objects of type XWiki.XWikiGroups" in http://xwiki:8080/xwiki/bin/edit/XWiki/XWikiAllGroup?editor=object then redisplaying http://xwiki:8080/xwiki/bin/view/XWiki/XWikiAllGroup ; in a virtual wiki setup, you may need to do something similar to explicitly set xwiki:XWiki.Admin for each http://<vhost>:8080/xwiki/bin/edit/XWiki/XWikiAdminGroup?editor=object prior to calling http://xwiki:8080/xwiki/bin/view/XWiki/XWikiAdminGroup, . This needs some explanation: since you don't necessarily want the local <vhost>:XWiki.Admin "shadowing" the root xwiki:XWiki.Admin (the one with programming rights), you don't want the v-host to have a local "XWiki.Admin" user at all. So if you do this, you'll see additional breakage until the correct root "xwiki:XWiki.Admin' user is pointed in the vhost for both XWikiAllGroup and XWikiAdminGroup. If you got these from the latest XAR, you'll probably want to do some hand-editing in a virtual-wiki setup if you hit this issue. Related to the above issue, if you've imported your vhost wiki as the "local" <vhost>:XWiki.Admin (which you'd have picked up unless you explicitly excluded in loading the XAR into the v-host), you probably want to re-import the XAR logged in as xwiki:XWiki.Admin (the root user with "programming rights" set). Otherwise any scripts that expected programming rights in the XAR will silently fail in the virttual-host, even though they work on the "root." OpenOffice Server Administration ( http://xwiki:8080/xwiki/bin/admin/XWiki/XWikiPreferences?editor=globaladmin§ion=XWiki.OfficeImporterAdmin) is a potential casualty of this kind of installation mistake; so is http://xwiki:8080/xwiki/bin/view/Main/AllDocs?view=attachments (works on "root" host, shows up empty on any virtual host). The underlying issue is that on a v-host, a document that might need programming rights is only saved as local "XWiki.Admin" user w/o programming rights; for example http://xwiki:8080/xwiki/bin/edit/Main/AllDocs?&editor=wiki and its four included documents -- XWiki.AllAttachments, XWiki.Tableview, XWiki.Treeview, XWiki.OrphanedPages -- are all saved as local XWiki.Admin. However, only http://xwiki:8080/xwiki/bin/view/XWiki/AllAttachments has the problem of displaying "empty" on a virtual host. I'm assuming that since you're seeing this new "users" behavior, you're using the recent 2.0M2 release? Here's my initial observations of the same issue you raised posted to the devs list: FYI, http://www.mail-archive.com/[email protected]/msg09995.html Re: [xwiki-devs] [ANN] XWiki Enterprise 2.0 Milestone 2 released > Niels Mayer Mon, 03 Aug 2009 22:21:35 -0700 > A few more problems, which i consider more "major" than previous first impression issues: On the "main" host of a v-hosted setup: > (1) Using administration "users" panel, add a user. As soon as user is added, no entries in users panel display. Subsequent return to this panel continues to show no users. The added user is created, however, and other user logins still work. However, no subsequent editing or browsing of users in user panel is possible. > (2) In administration "groups" panel, go to a group , e.g. XWikiAdminGroup and add the new user to that group. As soon as this is done, all the users in the group list disappear, yet the "lightbox popup" remains up. Subsequent browsing of a group where new members added shows an emtpy list of users, just like in the above users panel. > (3) the lightbox popup out of Groups->XWikiAdminGroup has a cancel button that is nearly invisible, and partially overlaps other buttons (the forw/back pager, which needn't display if only one page of users in list). This is in firefox 3.0.12 on Fedora 10 Linux. > -- Niels http://nielsmayer.com > PS: I shift-reloaded the pages with issues a few times to make sure it wasn't caused by the browser caching an old javascript file.. > PPS: I wouldn't have been adding users had I not just recently extracted my head from a dark and fetid orifice, in attempting to get "programming rights" on a muli-vhost-wiki... fortunately I happened to catch http://jira.xwiki.org/jira/browse/XWIKI-4066 "out of the corner of my eye" : > > For example, when the backup pack xwiki-enterprise-wiki-n.n.xar is used > as > a template or imported into a virtual sub-wiki and since local user > XWiki.Admin is used as authors of most pages, those don't receive > programming rights, because only global user may have these rights. For > most > pages, this has no concequence, but a few ones don't work properly. For > example XWiki.AllAttachementsResults, which use non-priviledged API does > not > work in a virtual wiki, without being resaved by a global user having > programming rights first. > > Isn't this the cause of numerous bugs All over the place? How would scripts requiring programming rights that are part of the 2.0 XAR , installed in each virtual-wiki, end up pointing to the "global user" XWiki.Admin and not a local XWiki.Admin that is the admin of the particular virtual-wiki. The latter wouldn't get programming rights. Isn't this also the cause of the office-converter issues I was having?? > Asiri Rathnayake wrote: > (3) When trying to start a internally managed ooserver-instance, I > consistently get message "Inadequate privileges." despite being Admin. (I > can start the external ooserver instance so openoffice seems to work). The page XWiki.OpenOfficeAdmin must be saved with programming rights. Make sure this is true. -- Niels. http://nielsmayer.com _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
