5

I'm at a client site where they have an application which began in SharePoint and is slowly migrating away to a very custom ASP.NET application. Some of their data elements are still hosted within SharePoint lists, two of which currently in question are some "Notes" and "Tasks" (fairly simple data elements in their SharePoint setup, nothing special about them). One of the things I need to be able to do from within ASP.NET is to automatically create some new items for these lists and add them from code.

So far it's pretty easy. I found the existing web part which handled the editing for those items, attached the debugger to it, tracked how it got its values and what it added to the list, etc. However, one of the fields being added to the list item isn't quite as obvious. In the existing web part UI, the field looks like this:

Assigned To field

Essentially, it's a field for entering a user from the current Windows domain. The book icon opens a pop-up which allows the user to search for a name, etc. In my current testing, I'm running as local Administrator on a development machine. So I just look for "admin" in the pop-up and it populates the field with "[machine name]\Administrator" as expected. Then, in debugging, the value that gets pulled from the field and entered into the SharePoint list item is "1" as opposed to a name or anything like that.

I assume that "1" is an identifier for the local admin account. Makes sense, after all. But my question is, how can I get that identifier for the current logged-in user in code? I've found code to get the current user's name, but not any kind of numeric (even though it's a string) ID.

Additionally, this wouldn't just be happening inside of an ASP.NET application context. There's also a WPF client application for laptops which would be generating these list items and synchronizing them back to the server when connected. I'm currently operating on the assumption that the client user would be logged in with a proper domain account known to the server.

I imagine this is pretty easy, I just haven't stumbled across what I need quite yet.

David
  • 208,112
  • 36
  • 198
  • 279

1 Answers1

6

I suppose you're looking for this:

int userId = SPContext.Current.Web.CurrentUser.ID;

By the way, this is the internal Id assigned by SharePoint to the user. To get this Id from a WPF application, you could deploy a WebService inside SharePoint that would return this Id. Or you can even query the SharePoint database, but I'm not sure if it's safe :-)

goenning
  • 6,514
  • 1
  • 35
  • 42
  • Excellent, definitely what I need for the ASP.NET side. (I figured it was easy, I just know nothing of SP.) The WPF one is a little more complicated though, because it needs to work in a sometimes-connected model. So there's no guarantee of SP connectivity. I suppose worst case is that the client machine queues up the items in local storage (which already isn't SP-related) and, when pushing them to a web service, assign the ID as the web service does the actual adding to the SP lists. I'll need to check with the client to make sure the web service has the SP context. – David Apr 11 '11 at 19:47
  • You could also get this Id once and then store it on a the new database. Would be much easier and faster. – goenning Apr 11 '11 at 19:49
  • Ya, I think I'm going to have to go with a workaround of some point. I'm thinking of just storing some basic data elements in a table on the client laptop and, when it hits the synchronization web server (existing functionality, it syncs tons of stuff right now) just add a method to upload those elements to the server and let the server figure out the details. The stopping point right now is that I don't think the SP context is available on the sync web service, so I'll have to address that as an architectural concern. Thanks! – David Apr 11 '11 at 20:01
  • 3
    Also, this UserID is specific to each site collection. The same user can (and probably will) have different IDs across collections. – Kit Menke Apr 11 '11 at 20:38
  • @Kit Menke: Noted. It's not a concern in this case, the client has just the one site collection (of which I'm currently aware, at least... it wouldn't be the first surprise) and is moving off of SharePoint over time. But a good tip to know, thanks. (Unrelated but also of note, apparently the SharePoint Stack Exchange site went public beta today.) – David Apr 12 '11 at 00:32