5

We've been looking up ProfileId from a given user that has OAuth-ed already. Normally they're returning the Id correctly when we call this:

/services/data/v28.0/sobjects/User/THEIR_USER_ID

However, for one user, we noticed the ProfileId is not readable.

When calling describe on the User object, it does not return a field with the name ProfileId.

/services/data/v28.0/sobjects/User/describe

This made me believe that Read permission for the ProfileId field was disabled so I tried changing the User field read permissions for one of our profiles. Then I saw the following:

Note that on the User object, field-level security is only supported for custom fields, not standard fields.

How has someone disabled read access to the ProfileId? I want to follow some steps to allow me to reproduce this on our SFDC Edition.

I read the User API docs for ProfileId and noticed that it used to be called RoleId. However this is also not present in the describe response.

Steps to edit the profile's User field permissions:

Setup -> Manage Users -> Profiles -> Selected one of our profiles -> Scrolled down to the section "Field-Level Security" -> Selected [View] for User -> The message is right under the profile's name

Improve this question

1 Answer 1

Reset to default
1

The workaround I have been using is to use the AccessToken returned OAuth token to call make a SOAP API call to the getUserInfo.

Kind of a bummer that a second web-service call is needed, but it seems to do the trick.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.