Item11335: JQueryAjaxHelper examples are broken on 1.1.4-RC2

Jayen has confirmed as well. Appears to be browser sensitive:

Example	Firefox 7/8	Chromium	Konqueror 4.6.5
Topic Selector	Dead - no indication of activity	Works fine	Works fine
Web Selector	Dead - no indication of activity	Works fine if FlexWebList installed otherwise causes a parse error.	Popup with "Error: parsererror"
Jump Box	Works - requires an extra click or enter to jump	Works, requires extra click or enter to jump	Doesn't jump on select as it did previously
Global Jump Box	(same)	(same)	Doesn't list web name until selected, which it did previously. So you cannot tell which web.duplicateTopic is listed until you select one. Doesn't jump on select as it did previously
User Selector	Dead - no sign of activity	Partially works Finds subset of users. Search for "Ad" finds AdminGroup, but no others. Occasionally gets "stuck"	Partially works Finds subset of users. Search for "Ad" finds AdminGroup, but no others. Occasionally gets "stuck"
Query Fetcher	Dead	Dead	Dead

See other comments in Item10302

-- GeorgeClark - 07 Dec 2011

On FF7, I get the following javascript error.

Error: $(".jqUserSelector").data("autocomplete") is undefined
Source File: http://f114.fenachrone.com/System/JQueryAjaxHelper
Line: 163

No errors on Chromium

-- GeorgeClark - 07 Dec 2011

One problem with the User selector part - USERINFO macro won't return information on any user except the current logged in user, unless you are an admin. So the User selector is going to be very limited in most cases.

-- GeorgeClark - 07 Dec 2011

Debugged this a bit. USERINFO macro quietly honors the $Foswiki::cfg{AntiSpam}{HideUserDetails} setting. If enabled (the default), USERINFO does not return any information except for the current user. If disabled, the User selector example works on chrome - still dead on FF7. Unfortunately if disabled, it reveals email addresses to everyone.

Since search was able to find the user (as input to USERINFO), then the macro probably ought to hide email only, instead of hiding all user information, including the name - which was already known.

-- GeorgeClark - 07 Dec 2011

Just discovered encode="quote" option of the URLPARAM macro. That should help fixing the format passed around, so it can be like before with $topic for the local jump and $web.topic for the global jump.

-- JayenAshar - 07 Dec 2011

Encountered another error on ff7

Error: uncaught exception: [Exception... "Cannot modify properties of a WrappedNative"  nsresult: "0x80570034 (NS_ERROR_XPC_CANT_MODIFY_PROP_ON_WN)"  location: "JS frame :: chrome://global/content/bindings/autocomplete.xml :: onxblpopuphiding :: line 859"  data: no]

-- GeorgeClark - 07 Dec 2011

Tested all this with trunk. The errors are gone and all of the examples work on Firefox using JQuery 1.7.1. ... with the exception of the parent query popup demo, which does not pop up an alert.

-- GeorgeClark - 07 Dec 2011

Tested on t.f.o with JQ 1.7.1:

Example	Firefox 8	Chromium	Firefox 8 - http://trunk.foswiki.org/Sandbox/JayenJQueryAjaxHelper
Topic Selector	Working, but no indication of activity		Working, but spinner can get stuck
Web Selector	Popup with "Error: parsererror", no indication of activity		Popup with "Error: parsererror", no indication of activity
Jump Box	Works - requires an extra click or enter to jump, keeps anchor on page change, no indication of activity, only matches beginning of topic name (different from 1.1.3)		Works - spinner can get stuck, only matches beginning of topic name (different from 1.1.3)
Global Jump Box	(same) and Doesn't list web name until selected, which 1.1.3 does. So you cannot tell which web.duplicateTopic is listed until you select one.		(same)
User Selector	Working, no sign of activity		Working, but spinner can get stuck
Query Fetcher	Dead		Working

-- JayenAshar - 07 Dec 2011

Here are screen shots of the jumpbox on Foswiki 1.1.3 and 1.1.4 - the old version is much more useful.

Foswiki 1.1.3	Foswiki 1.1.4

-- GeorgeClark - 08 Dec 2011

Tried to fix the Query Fetcher. This line in jQuery seems to not work...

elem = document.getElementById( match[2] );

match is ["#jqQueryExample", undefined, "jqQueryExample"], but elem becomes null...

-- JayenAshar - 08 Dec 2011

Found a missing close double quote after the class name, so the button had no id. fixed it, but now firebug broke???

-- JayenAshar - 08 Dec 2011

Ok, firefox crapped itself after fixing the quote, but restarting brought it back. the query fetcher is now working on my sandbox page on t.f.o

-- JayenAshar - 08 Dec 2011

The activity indicator comes from .ui-autocomplete-loading, which is specified for themes/foswiki, but not themes/base.

-- JayenAshar - 08 Dec 2011

I've committed your fix for the missing comma. Thanks Jayen. also made a change to always show the Web in the jumpbox. These fixes plus JQuery 1.7.1 on trunk has everything working. Have to decide what to do about release 1.1.4 though.

-- GeorgeClark - 08 Dec 2011

Committed all your fixes to the JQueryAjaxHelper topic. Also updated 1.1.4 to JQuery 1.7.1, it seems to fix multiple issues.

-- GeorgeClark - 09 Dec 2011

The user selector broke on distro:b9bd29dc841f as it shows anything that resembles a username in the Main web rather than filtering users.

-- MichaelDaum - 11 Dec 2011

We need a different solution then. The USERINFO macro cannot be used on a default foswiki install for filtering users, unless you are running as an admin, or have disabled the hiding of email addresses. A user list that lists no users other than yourself is not particularly helpful.

-- GeorgeClark - 11 Dec 2011

Converted to a query search for topics with a UserForm, or GROUP meta. Please verify that this works for you. It will fail to find groups that are still in the old format. The right fix is to change USERINFO to only hide the email instead of becoming a NOP when AntiSpam is enabled. But I don't want to change that behavior for 1.1.4.

-- GeorgeClark - 11 Dec 2011

We can't use UserForm. Thats limiting it to installations that actually do have this DataForm anywhere attached. In a lot of intranet installs this information is stored in an LDAP directory instead, or any completely different form of storing profile data.

Actually the autocompleter should return an empty list when $Foswiki::cfg{AntiSpam}{HideUserDetails} = $TRUE; is in use as this setting has exactly this purpose: to hide user information. So user information must not be disclosed probing for it via autocompletion.

Foswiki has got an internal representation of its uses and groups which is independent of the kind of user mapper other than the default topic based one. All of this information can be queried using USERINFO and GROUPINFO ... when HideUserDetails is switched off. So, IMHO, using USERINFO was the right thing to do as it was at first.

-- MichaelDaum - 11 Dec 2011

The point is that it does not hide the User Details. It hides all users totally / completely. Search finds that the user exists, the ACL's permit the User topic to be read, and then USERINFO discards it. If it was hiding just the emails, photo, login name, etc. but allowed the user found by search to be displayed, it would be useful.

If a User topic ACL allows the user to be seen, then USERINFO should at least allow the WikiName returned by search to be visible. It makes no sense to have a topic visible in search that is hidden from the autocomplete.

Your implementation is totally worthless on Foswiki.org, not because we hide the Users ... the User topics are all (mostly?) readable. But because we hide the email addresses.

Maybe the only answer is to have two separate examples, one for corp / LDAP based sites that don't hide user details, and another that is usable on Foswiki.org.

-- GeorgeClark - 11 Dec 2011

I've restored the user selector example. Unfortunately it's unusable on public wiki sites.

-- GeorgeClark - 11 Dec 2011

Can we make an

%IF{"NOT isAdmin AND {HideUserDetails}" then="<try the topic form>" else="<USERINFO>"

solution?

-- PaulHarvey - 11 Dec 2011

There are at least three issues mixed up here:

First and foremost: the real solution is to have a formfield of type users and dont have to bother with these kind of fragile TML juggling. The current implementation is a major headache already, i.e. nothing to rely on long term and nothing able to cover the different setups which foswiki has to cover, ranging from total protection / hiding of any users from each other to social intranet sites with quite open sharing of user details.

Second, I totally agree with you George, that USERINFO is too anal by default. It should be at least a tiny bit more useful even in a HideUserDetails setup to allow the kind of filtering as being used in the current impl. For instance, USERINFO should by default be usable to translate login names to wiki names and vice versa. If the USERINFO is more or less useless by default, whats the point of having it at all by default?

Yet, disclosing too much user details is and will always be a sensible issue for any kind of social software where people come together to collaborate and try to get their job done.

Third, we need to make clear that the helpers shipped with JQueryPlugin can't cover and weren't intended to cover all possible use cases for autocomplete backends you could ever think of. That too is a misunderstanding. If we are in the situation having to set up one very specific foswiki in concrete environment you will most probably have to customize these callbacks anyway. Take for one displaying photos of users in the autocompletion list: where do they come from and how can you fetch them? This alone varies so much, yet users regularly ask for this feature. We see it out there on other platforms regularly. That's why users ask for them in foswiki as well. The two choices for USERINFO to (a) either render it useless or (b) risk to be too open disclosing user information, are both either too rigid or too open.

-- MichaelDaum - 11 Dec 2011

See USERINFOisTooRestrictive I've proposed a change that would open up USERINFO just a bit. That change lets the autocomplete be a bit more useful in a default Wiki installation. We can argue there about whether more or less info could be revealed and under what conditions.

Generally I think it's better for the new user that examples work in an out-of-the-box default installation wherever possible. Implementation in a LDAP or other environment is a bit beyond Foswiki 101. I was rather stymied by the JQueryAjaxHelper topic - initially not one of the examples was actually working on my test systems. The first experience for the "new user" should have all of the examples either working, or clearly identified as to why they are not working. First impressions are so important, and a page of dead examples, regardless of whether it's due to browser issues, syntax errors, or anal security defaults leaves a really bad impression.

That was my rationale on this and why I was being a bit of a pain. Let's get the default experience as positive as possible.

-- GeorgeClark - 12 Dec 2011

I fully agree. Thanks for acting so fast on putting up the feature proposal. It even contains a patch. Cool.

-- MichaelDaum - 12 Dec 2011

Commenting is disabled while not logged in