Hi, Maxime Mathieu wrote:

Hi,

When using the *Meta+G* popup search in a wiki instance of the farm, after typing something to search for, the dropdown appears saying always "Document not found".

If we repeat the same operation with the admin user of the farm, all works fine and the suggested list contains up to 10 pages. Using Firebug, I discovered that all is right except that the Rest search service returns an empty list of page. This is the exact JSON received : {"template":" http://server.com/xwiki/rest/wikis/calife/search?q={keywords}(&scope={content|name|title|objects})* ","searchResults":[]} Please, Maxime, what Firebug settings are you using the get this message? I am seeing somekind of malfunction of Meta+G in our 2.4.30451 farm but I am not getting any Firebug message. Thanks!

Greetings, Ricardo -- Ricardo Rodríguez CTO eBioTIC. Life Sciences, Data Modeling and Information Management Systems

Concerning the authentication method, I think I am using the default cookie-based one. The farm is connected to an Active Directory but not in SSO (we have to type in login and password). About the json response, this is the steps I follow using Firebug : - first, I click on the Meta-G link, the popup appears - then, I open Firebug - and in the Net menu (of firebug) I active it clicking on "Enabled" - I activate the Console menu of Firebug - then I type in some text in the "Jump to any page" popup - the Console window of firebug contains the Get request - I open it and in the Response tab is the JSON result of the REST request. Hope this help. My firebug version is 1.5.0 in Firefox 3.6.9. Regards, Maxime Mathieu

Hi! Maxime Mathieu wrote:

I just discovered that the problem doesn't occur with a local user (I mean a user not defined in the main wiki of the farm).

Could someone reproduce this issue ?

I've being doing some trials as I am also interested in how XE/XEM behaves using LDAP. In my case, this is the environment: ***** A XE 2.4.30451 instance as per xwiki-enterprise-web-2.4.war upgraded to XEM 2.4 a on this environment: Open Enterprise Server 2 SP2 2.0.2-0 / Suse Linux Enterprise Server 10 SP3 10.3-0 / eDirectory 8.8 LDAP enabled (Fully updated and patched. It is the current OES2 commercial configuration distributed by Novell) ***** I am not seeing what you describe. At least, or, much better, I don't understand how your farm is set up concerning LDAP authentication. Please, have you set up the farm to creates users only in the main wiki? Both in the main wiki and virtual wikis? Only in virtual wikis? To the best of my knowledge it is not possible to have a wiki, the main one or any virtual one with users being created both at local (virtual) level and in the main wiki. That only happens with you modify the settings after the initial set up. Then, you get crazy mixture of users that is not easy to manage: for instance, two users with the same name one in the main wiki other in one or several of the virtual ones. I our case here, we have set up so far the farm to creates all users in the main wiki (as per http://tinyurl.com/37nrk9l) and Meta-G seems to work fine. This set up won't be enough as we need use groups to grants access to different virtual wikis by using several eDirectory groups. I will keep this thread updated with new trials when the configuration change and try to write an "use case" when finished. Please, could you detail your LDAP configuration? To better understand your current case? Thanks! Ricardo -- Ricardo Rodríguez CTO eBioTIC. Life Sciences, Data Modeling and Information Management Systems

Hi Maxime, Maxime Mathieu wrote:

Hi,

I have applied the last section of this doc http://platform.xwiki.org/xwiki/bin/view/AdminGuide/LDAPAuthenticationUseCas... you). So, in theory, users are created only in the main wiki. And it is the desired behavior.

First of all, allow me what could be a silly question: *virtual wiki* and *subwiki* are used as synonyms? Local and main wiki are also used indistinctly? I think Local is used as "relative" concept both in the main and virtual wikis to express that an user or a group is defined in its database. Thus, I think it will be better to use *main wiki* for the "master", even though I prefer the the old wary: the controller, and *virtual wikis* for any other wiki in the farm. In fact sub wiki could be not appropriate for a number or reasons. For instance, here we have some virtual wikis that are far from being considered as a sub-group of the controller. In brief: I would like to propose to use *controller* and *virtual wikis* as the advised way of calling both type of wikis. WDYT? Thanks!

But in fact, an admin can create a local user (not connected to the LDAP) in a subwiki. It is what I have done only to test the Meta-G feature. If you know how to prevent local user creation, I'm interested.

No idea, sorry. I've not faced this kind of challenges yet. What I understand here is that you want to have virtual wikis administrators that won't be able to create local users, am I right? This will be welcome also here.

More about my configuration : Users don't have the right to read the main wiki (except their profil page, of course). Only users are imported from the LDAP, the groups are xwiki groups.

Here groups in the directory service are used for many other different things. So, for us, groups in the farm and in the directory service must be synchronized. In fact, this is a feature we are planning to develop. Well, patronize its development! I am far from being able to develop such a thing! Now, users and groups can be synchronized with directory service contains, but that is not true the other way round. For instance: if an user changes its telephone number in the his/her wiki profile, the change won't propagate to the directory. Please, why do you use XWiki groups?

The principle to manage the rights of a subwiki is that the subwiki administrator creates local group and inserts global users in it.

I get your point, but as stated before, groups for us have a lot of different uses in the directory service. I've not tried yet how LDAP properties set at virtual wiki level behave. I will keep this thread, or created new ones if required, updated about this issue. BTW, does global user selector work for you when editing local groups in virtual wikis? It doesn't show any result for me. Cheer! Ricardo -- Ricardo Rodríguez CTO eBioTIC. Life Sciences, Data Modeling and Information Management Systems

Hi! Maxime Mathieu wrote:

Hi,

2010/9/10 [Ricardo Rodriguez] eBioTIC. <[email protected]>

In my humble opinion, a "virtual wiki" is a xwiki installation that enables to manage a farm of wikis.

See http://manager.xwiki.org/xwiki/bin/view/AdminGuide/Installation *Set your wiki as "virtual" to allow multiple wikis*

A farm is composed of a "main wiki" (the controller) and a lot of "wikis". Theses terms seem to constitute the "official" vocabulary of the xwiki product.

In my words, a sub-wiki is just a simple wiki of the farm.

The words "Local" and "Global" apply to users and groups. Global means : "present in the main wiki", Local means : "present in a wiki (not the main one)"

I think that what sounds weird to me here is the adjective virtual applied to that sub-wikis. It is not less "virtual" the controller than any of the wikis being controlled, at some extent, by it. I think I feel myself more confortable speaking about a *wikisystem* or a *wikiscape *(perhaps XWikisystem or XWikiscape better than a XWiki Ecosystem) where relationships of dependence between wikis and objects within wikis need to be defined. Well, that seems more related with philosophy or anthropology then with computer science.

...

No idea, sorry. I've not faced this kind of challenges yet. What I understand here is that you want to have virtual wikis administrators that won't be able to create local users, am I right? This will be welcome also here.

Yes exactly.

I see what you want here. In fact, this morning I had a good example that required this solution: I would need a so called administrator for a wiki that has not rights to modify the composition of the community (won't be able to create local users) although is trusted to organize documents/objects within that wiki. Don't you thing it deserves a Jira idea?

It doesn't show any result for me too, this is why I created the issue

XAADMINISTRATION-167.

Sorry, I must concentrate on Jira and forget other topics! Cheer, Ricardo -- Ricardo Rodríguez CTO eBioTIC. Life Sciences, Data Modeling and Information Management Systems