4 Aug
2009
4 Aug
'09
7:20 a.m.
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.