Hi Niels, many thanks for your answer. However I am not sure I understood everything. What I actually would like to know is what should I do to solve this critical problem? How should I edit the http://xwiki:8080/xwiki/bin/edit/XWiki/XWikiAllGroup?editor=object for instance? We are using one and only one XWiki, no virtual ones (if I got it right, virtual wikis allows you to create/use more than one XWiki instance). I also tried to re-import the XAR file logged as administrator. The problem still persists. I forgot to mention it: we are using XWiki Enterprise 1.9.2.22089. So not the milestone one. This problem is quite critical and decisive for us. I installed XWiki locally on my machine with a PostgreSQL database and things work fluently. I do not understand why this does not work on this Linux machine and with a MySQL database. Do you think this is a question of right permissions? I wish you a wonderful day. Cheers, christian -- Canoo - Your Solution Provider for Rich Internet Applications Christian Ribeaud Canoo Engineering AG Kirschgartenstrasse 5 CH-4051 Basel Tel: +41 61 228 94 44 Fax: +41 61 228 94 49 [email protected] http://www.canoo.com/ On Aug 9, 2009, at 11:10 PM, Niels Mayer wrote:
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:
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&... ) 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