Because the mailing list does not seem to accept attached images, here the link to the screenshot:

http://www.ribeaud.ch/tmp/xwiki.png

Cheers, christian On Aug 7, 2009, at 10:08 PM, Christian Ribeaud wrote:

Hi,

We made a XWiki default installation, nothing special. We are using a MySQL5 database which has been configured as following:

<!-- MySQL configuration. Uncomment if you want to use MySQL and comment out other database configurations. Note that the database will be created automatically if it doesn't already exist. We need to set the sql_mode to a less strict value, see XWIKI-1945 --> <property name="connection.url">jdbc:mysql://localhost:33065/xwiki? useServerPrepStmts = false & ;useUnicode =true&characterEncoding=UTF-8&sessionVariables=sql_mode=''</ property> <property name="connection.username">username</property> <property name="connection.password">password</property> <property name="connection.driver_class">com.mysql.jdbc.Driver</ property> <property name="dialect">org.hibernate.dialect.MySQLDialect</ property> <property name = "connection .provider_class">com.xpn.xwiki.store.DBCPConnectionProvider</property> <property name="connection.pool_size">2</property> <property name="statement_cache.size">2</property> <mapping resource="xwiki.hbm.xml"/> <mapping resource="feeds.hbm.xml"/>

XWiki is running in a Tomcat6 container with jdk1.5.0. For some reason I do not understand, I am not able to see the users list when logged as administrator (which all consequences this implies...). However I see the number of users that are registered (see attached picture)!! Does anyone understand what the problem could be? I tried to display this page with Firefox and Safari. Nothing, and apparently no JS error.

Any help would be greatly appreciated. I wish you a wonderful day and a nice week-end. Best,

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/ _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

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:

...

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&... ) 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

Christian Ribeaud <[email protected]>:

Thanks a lot, Niels. Really. I got it now. But this is really cumbersome! And when using the administration panel, I always get empty panels: rights, users, groups,... (only the number of items is displayed).

One more thought on this issue: if you have upgraded your Xwiki, be sure to issue a shift-reload command in your browser on the home page, and probably on any important administrative pages. The bug we're seeing could becoming from two different possible sources: (1) New upgrade XAR overwriting system-specific configurations present in XWiki.XWikiAdminGroup, XWiki/.WikiAllGroup, XWiki.XWikiPreferences; (2) New upgrade WAR containing new javascript code, but same-path as previous javascript code that resides in browser cache. The new WAR was expecting to talk to the new javascript, but instead, talks to the old javascript. On browsers like Mozilla/FireFox, errors like calling nonexistent javascript functions happen without the end-user noticing, unless special steps are taken to see if javascript errors are happening. If the latter scenario happened, it could have left your Xwiki in a "half updated" state because the application never got the expected response from Javascript. (The bug would then be the lack of "defensive programming" on the part of Xwiki to detect this situation ...) It is entirely possible that the initial add-user and edit-groups bugs that cause these administrative features to break happened with "old javascript in the browser" coming from a previous version of Xwiki. This is not an Xwiki problem, it is a Web problem. Ultimately, it's something that's entirely in the control of the person running the website, and not really something that Xwiki can control (other than the "defensive programming" bit). You might see this issue more often in Xwiki because the team is doing software development "the right way" which means continuous improvement, continuous revisions, regular releases, and lots of users testing and using the software in every possible unexpected situation, etc. Microsoft's "release infrequently, and badly" approach means users only get to see these kinds of compatibility problems on each new service pack or browser upgrade, and that's at best once every few years. With the furious pace of Xwiki development, we can end up seeing this bug every few months, and that's just fine by me. Shift-reload is your friend. So if you're having problems in this regard, it is in no way "Xwiki''s fault -- just change your sites sub-domain name, or the path to Xwiki documents -- and you'd implicitly fix this problem for this or any web software on each upgrade. If the web-site doesn't want users to see this problem, one can easily add a "revision number" in the path to the javascript libs so that the browser will automatically load the new "revision" (the path changed, nothing in cache) as opposed to using the one in the cache. (This might actually be a good bit of "defensive programming" for Xwiki -- add a "revision code" to the path of any javascript lib referenced in the browser, and then just have xwiki do the path-rewriting magic to verify incoming requests are for the correct "revision code", and serve up correct files out of <xe-WAR>/resources/js ). This is also a world where my BANK's website doesn't work on any current browser I use day-to-day (FireFox 3.5.3 on x86_64 Linux, Chrome on Windows) and pops up errors all over the place when using my current up-to-date IE 8. Which means we're doing financial transactions underpinned by something as flaky as IE's "Javascript." So really, in comparison, the kind of problems we see in Xwiki are minor in comparison. Furthermore, the architect and original designer has joined this thread, so he'll probably have it fixed in 5 minutes once we've actually done our part of the "open source social contract" and have helped better characterize the problem. No need to wait a year for Microsoft to deliver a new service pack here in Xwiki land.... Finally, Xwiki is "open" enough, both at the software level, and even at the data level with "everything is a wiki doc" that we can actually diagnose and fix these problems ourselves. You think you'd have been so quick to do the same kind of fix I suggested for Xwiki using, by analogy, Microsoft's "registry editor" ??

I thought that this open-source application would be in a better shape.

Xwiki is in great shape. It is undergoing a massive transformation at this time, typical of 1.0->2.0 transitions. Fundamentally, Xwiki is an amazing application and there's really no competition for it. ( http://blog.asyd.net/2008/12/xwiki-cest-decidemment-magique/ (C'est vrai!), http://www.opensolaris.org/os/community/web/restructuring/wiki_eval_x/ http://madplanet.com/xwiki/bin/view/Blog/Rough+Diamond ) You do not necessarily need to be running the latest and greatest revision unless you're ready to deal with the latest and greatest issues. This wisdom doesn't just apply for Xwiki... it's endemic to software. Sometimes, you just have to forgo upgrades, and just wait a bit. For example I'm still running Win XP Service Pack 2, and I'm not going to upgrade to Service Pack 3, which i already know will break a bunch of things that work just fine right now. (My use of Win XP is just an engine to run http://cygwin.com so I can use windows as an X terminal and also test whether things work in IE :-) ).. For critical things, it's *ALWAYS* safest to wait a few months to upgrade -- wait for all the reports from "bleeding edge" users like me that are willing to deal with some pain to get the latest and greatest. (IMHO, w/r/t Xwiki 2.0, the pain is well worth it !!! But then again, I'm an xwikizochist :-) ). Also, upgrades should never happen without a dry-run first. Clone the data, go through the entire upgrade process on a different system/server, and take notes and resolve any issues that arise before considering doing the same thing to a live site. Nothing ever goes right the first time, so instead of wasting a lot of back-patching issues, and handholding unhappy users, make sure your users won't be surprised in the first place by testing the upgrade and new software, before rolling out to a "live" site. -- Niels http://nielsmayer.com PS: Regarding the javascript shift-reload issue: I really think that digital signatures need to be incorporated into javascript used in browsers. Before an app uses a JS "package" it would request the digital signature of the JavaScript the browser is using, and check it against what the app expects to be using. Only after this check you'd know you're talking to the exact intended javascript lib, as opposed to either an old incompatible revision; or even worse, bogus javascript that has been specifically overridden in a few places to intercept or alter communications back to the server. Ultimately, each javascript closure being executed needs it's own digital signature, composed of the digital signatures of the transitive closure of all functions that might be called out of a given closure, and of course, any response by this closure back to the server would need to be signed by this signature,and checked on the other end for validity/tampering. Oh well, I can dream, can't I?