This project has moved and is read-only. For the latest updates, please go here.

Limitations of SPServices

May 2, 2012 at 3:48 PM

I've implemented some custom jqery to utilize the SPServices functionality.  Some basic stuff...capturing the logged on user and thier respective manager.

The code works most of the time....I suspect that something is amiss with SP2010 profiles that causes the code to "stop working".  I've tested with 10 users, and 9 of the 10 user that hit the page with my custom code retrieves their user ID and managers info.  The 10th person consistently fails (doesn;t retrieve their UserID or Manager's Info..those variables are blank/undefined).  I've looked at the "troublesome" user's profile, and it appears that profile services did NOT successfully resolve their managers name during the profile import (because there were mulitple "jsmith" listed for the manager...hence it's didn;t resolve the correct manager).

Is there a known "limitations" list of how SPServices interacts with the profile services?

Any suggestions on how I might debug this further would be greatly appreciated!


May 2, 2012 at 9:24 PM

I have a similar problem. I am using the getcurrentuser function on a MOSS site and when I or anyone from my team uses the page that the code is on, it works without issue. The problem is when people outside of our workgroup try to use the page, I can get javascript and even jquery to work for them but the spservices functions do not seem to work for them. Any suggestions that can be offered would be greatly appreciated!

May 2, 2012 at 11:54 PM
Is the SPServiced in the same folder as jquery? If not, do those users have permissions to the folder where it is located?
Also, what does it mean when you say that SPservices is not working? Is the library successfully loaded on the page? Or is it that you get errors when your calls to the module execute?

To the original poster: does your site allow anonymous login?


Sent from mobile device

May 3, 2012 at 4:00 AM

In both cases, it sounds like a permissions issue forst, possibly a script file reference issue second, and probably a m issing data issue third. Noe of these are SPServices per se. Calls to the Web Services work under the current user's permissions, so that user has to have permissions to do what the script is attempting.


May 3, 2012 at 4:03 PM


Both my jquery and spservices libraries are in the same folder with the exact same permissions (all authorized users have read access). When I say that it isn't working, I don't think it's a matter of SPServices not functioning properly... I'm just not getting the end result that I am looking for. I am somewhat new to both jquery and spservices so I'm not exactly sure how to see if the library is loading or if there is some other error (but if you can point me in the correct direction to figure out how to check that I will definitely check that).


I am inclined to think that it may be some type of permissions issue as well; however, I've already checked the permissions for the library that is being referenced and everyone has access to that so I am more inclined to think that it might be the permissions for calling web services. Is there a specific standard for permissions necessary for calling web services (specifically those necessary for getcurrentuser)?

Any assistance that can offered is of course greatly appreciated!

May 3, 2012 at 4:14 PM

My suggestion: Time to get into specifics... If you have a user where you can consistently recreate the problem, then post what the expected results should be along with your code (specifically around where it calls (getcurrentuser)... then I can suggest where you can put some "debuging" calls to try and figure out where the problem might be.

Some Tips:

Because (as the DOC's state), getCurrentUser() is based page scraping, it may be useful for you to look at the page "/_layouts/userdisp.aspx?Force=True" for the users where this is not working and compare it to the same page for users where it is working... just to see if there is something different.

The original post indicates that they then show the manger's information... I assume you are using the "currentUser" id and getting their full information (via webservices) and retrieving the user's manager out that out... will need to see that code as well.

Hope this helps...


May 4, 2012 at 4:31 PM


I compared two users on the following page "/_layouts/userdisp.aspx?Force=True", one consistently receives expected results and one consistently does not and there was nothing that I could discern on the two pages that would cause that difference. My expectation of the code (and what happens when I or anyone else from my team uses the form) is as follows:

- SPServices retrieves users first and last name, compiles these into a string variable, "fullName", and then inserts this variable into a field on the page ("cbFullName").

In addition, I use jquery to hide several fields on the page. I have added an alert to test and see if the var "fullName" is being populated. Whenever someone outside of my team is on the page the alert returns "Welcome " which indicates that the variable has not been populated correctly. Conversely, if I or anyone from my team is on the page then the alert returns "Welcome John Doe" (or whatever their name happens to be) which indicates that the variable is indeed being populated properly. In both cases, the fields that I am trying to hide are hidden which indicates that the jquery is working for everyone, regardless of whether they are on my team or not.

The code that I am using is as follows:

$(document).ready(function() {
  var firstName = $().SPServices.SPGetCurrentUser({
   fieldName: "FirstName",
   debug: false
  var lastName = $().SPServices.SPGetCurrentUser({
   fieldName: "LastName",
   debug: false
  var fullName = "" + firstName + " " + lastName + "";
  alert("Welcome " + fullName + "");

  $(function() {

        {value: fullName});

As stated previously, I am new to both jquery and SPServices and hope this is something simple that I have overlooked. I really appreciate your assistance!

May 4, 2012 at 8:56 PM
Edited May 5, 2012 at 4:37 PM

Do you see values on the userdisp.aspx page for the FirstName and LastName? Can that user navigate to that page and see that values as well?

Also, you should use this syntax to populate the value:



May 4, 2012 at 9:08 PM


I actually don't see the FirstName and LastName fields at all on the userdisp.aspx page, for any of the users. My script sits on a MOSS page but a lot of my users are getting to that page from a WSS site, could this have anything to do with it?

Thanks for the update regarding the val() syntax, I will definitely use this instead!

May 5, 2012 at 4:37 PM

If you don't see the values on the userdisp.aspx page, then SPGetCurrentUser can't return them. All it really does is "scrape" the values from that page.


May 7, 2012 at 1:28 PM

More data on my "issue".

It seems that I may have uncovered a "flaw" with how profile imports work...

In profile services, I searched for my user name and returned 4 results...2 with my NETBIOS name as the domain prefix and 2 with the DNS name as the prefix.  All 4 had the correct SAMAccount name.  When I tried to MODIFY the records with the NETBIOS name, I was not able to MODIFY the account name NETIOS\USERNAME...all I could do was delete them.

Only after I deleted ALL but ONE profile record what I able to return results via SPServices.  In code wasn;t was what was contained in the profile services databases.

Since a Profile import doesn;t pass through the profile services interface, it appears to me that there is no integrity/duplication checking that occurs during the bulk import....hence the multiple NETBIOS prefix SAMAccount names.

It seems that userdisp.aspx must do some sort of query for the current logged in user, and retrives the FIRST RECORD it finds...worse finds multiple records and displays NOTHING. :(



May 7, 2012 at 1:32 PM

userdisp.aspx is actually a view on the User Information List. The information you see should tie directly to the exact user you are logged in as.

It does sound like you have an issue external to SPServices, though.


May 7, 2012 at 1:39 PM


I took another look at the userdisp.aspx page and realized I was looking on the wrong site the first time I checked it out (I was initially looking on the WSS site that the users were being referred from and not the MOSS site that the page sits on). So I took another look, this time on the correct site, and found that the users actually do have all of the information on that page that I am looking for. I haven't tested to see if the users themselves can navigate to that page yet but that will be my next step... will keep you posted and thanks for the assistance!

May 7, 2012 at 2:01 PM

So it appears that the issue was a permissions issue realted to the userdisp.aspx. My only question now is whether there is a way to change the permissions for that page without changing permissions for the rest of the site?

Thanks again for all of your assistance!

May 7, 2012 at 2:25 PM

It would be pretty unusual for a user to not be able to see their own information on that page. If someone can't, then you probably have done something odd with permissions.


May 7, 2012 at 2:42 PM

The users that were having issues with the function only had access to one list on that specific site and the rest of the site was closed off to them. I'm sure I'll be able to work out the details necessary to adjust their permissions for the site and keep them out of what they don't need to be in to :)

Apr 12, 2013 at 9:39 AM
Edited Apr 12, 2013 at 9:51 AM

I am getting a similar issue with sp2010 portal, patched to Feb 13 CU

In my custom master page

 <SharePoint:ScriptLink language="javascript" name="~sitecollection/Style Library/Scripts/jquery-1.8.2.min.js" Defer="false" runat="server"/>

<SharePoint:ScriptLink language="javascript" name="~sitecollection/Style Library/Scripts/jquery.SPServices-0.7.2.min.js" Defer="false" runat="server"/>
var thisCurrentUserTitle = $().SPServices.SPGetCurrentUser({fieldName: "Title",debug: false});
var thisFirstName = $().SPServices.SPGetCurrentUser({fieldName: "FirstName",debug: false});
var thisLastName = $().SPServices.SPGetCurrentUser({fieldName: "LastName",debug: false);
<div id="MyServices-Box-Header-User-Name-Large"><script type="text/javascript"> document.write( thisCurrentUserTitle  );</script></div>
<div id="MyServices-Box-Header-User-Name-Large"><script type="text/javascript"> document.write( thisFirstName  );</script></div>

<div id="MyServices-Box-Header-User-Name-Small"><script type="text/javascript"> document.write( thisLastName  );</script></div>              
Users added to portal via an Domain Users AD Group.

access my new portal and only the Title field (for debug purposes)_ is shown. The other fields seem to appear later on or after a reboot. when a new user accesses the system.._. wierd eh! Just been around the IT dept getting people to logon and access the portal -via IE 9 the outcome is how I have described

Apr 15, 2013 at 3:26 PM
Edited Apr 15, 2013 at 3:26 PM
SPGetCurrentUser does a "screen scrape" of the /_layouts/userdisp.aspx page, as described in the docs. If a user hasn't "touched" the Site Collection, they may not be in the User Information List which feeds that page. However, since the current user is logged into the Site Collection, I'm not sure how that could be. It's possible that it's simply a timing issue, but I've never had any reports of it that I can recall.

Apr 18, 2013 at 2:59 PM

Thanks for the reply. I guess your are referring to User Profile Service App and User Profile Sync Service kicking in, when you mention "touched" . The issue I have seems to happen to all users - title field ( first name and last name) seems always to get populated, the individual names later. It could be a timing / network issue ( nothing surprises me about the environment here). In the iterim to assuage the users, I have quickly written a js helper object so they always get the correct ui. Also I am building a sp2010 instance vm and porting my app to it for other reasons but will also look at this issue on it.


BTW you missed a cracking spevo2103.
Apr 18, 2013 at 4:53 PM

Yes, spevo looks like it was cracking all right!

There's the UPS synchronization, but on first "touch", even if the user hasn't been synchronized, they are added to the User Information List for the Site Collection. This same thing happens even in Foundation where UPS isn't available. Maybe given your UPS synch schedule the UIL data isn't getting populated correctly?

Apr 19, 2013 at 8:27 AM

I see what you mean - this seems quite feasible. On the subject of "touch" I guess you referring to a user logging in for the first time - does this trigger the population of the Information list for the site collection. Note the Users are added to the sc as in the form of an AD group. I didn't build the server but will take a look at the UPA and UPS, farm CU levels to see if there is anything obvious.

Yep just writing up my notes on spevo - Ted Patterson equating differently hosted apps in sp2013 to real and virtual: intimate human interactions - truly a first for a SharePoint conference!
Apr 20, 2013 at 5:02 PM
"Human interactions"? Wasn't this a tech conference. ;+)

The touch is, in my experience, anything that a user does that impacts a Site Collection. I use the word "touch" because it dsoesn't matter who touches the Site Collection with the user. If you add a user to a SharePoint group, they have "touched" the site Collection.

The thing that's odd to me in what you describe is that when a user visits a page in a Site Collection, they have touched it and therefore should be in the UIL.