create user API return "unique_id":" too_short"

[moonshot]

there are two question i hava

The first question is what the content of ":account" in the URL corresponds to. The second question is that I tried to fill in ":account" with "self", and the result showed

{"errors":{"user":{"pseudonyms":[{"attribute":"pseudonyms","type":"invalid","message":"invalid"}]},"pseudonym":{"unique_id":[{"attribute":"unique_id","type":"invalid","message":"invalid"},{"attribute":"unique_id","type":"too_short","message":"too_short"}]},"observee":{},"pairing_code":{},"recaptcha":null}}

i'm used this https://moonshot.instructure.com/api/v1/accounts/:account/users

[mzimmerman]

Hi @moonshot 

In the API, ":account" is not referring to the user, but to the numeric ID for account/sub-account that you are running the query against.  So, "self" doesn't make any sense in that context.

The top-level account is always "1", and sub-accounts get numeric ID more or less in the order they are created.  Since users are always created at the top level account, normally "1" would be the account ID, i.e. https://moonshot.instructure.com/api/v1/accounts/1/users 

[chriscas]

Just a small clarification.  The top level may not always be 1.  For us (implemented in 2013), our root account is 134.  I'm not sure if Instructure changed practices and the root is always 1 for newer implementations now, but I wanted to add this here for those who may be similar to us.

-Chris

[James]

@moonshot 

Provided the person with the access token has permission to call the endpoint, self does work for the account for this call.

GET <instance>/api/v1/accounts/self/users

If you try to call it with someone who doesn't have permissions (typically a non-admin user), you get a 403 forbidden result.

The main account may be #1 for self-hosted instances. I doubt it is that way for newly created Instructure-hosted accounts because you would need some way to keep the data separate in the database. For requests, you could infer the account from the hostname, but internally, it would still need a number for that. The number you get is not sequential as we implemented in 2012 and are close to 98000 for our root account ID.

If you want to force a number instead of using self, then you can ask Canvas for the top account and look at the id field.

GET <instance>/api/v1/accounts/self

Again, you must have enough permissions to make that call.

Unfortunately, I won't be able to be as certain with the error messages. That does not look like anything that I've ever seen come out of the request for users. It makes me wonder if you threw in some additional parameters that you didn't mention.

There is a search_term that says you have to have at least 3 characters, so searching for something with 2 characters could be "too short", but it was the unique ID that was too short. Besides that, it still worked even if I specified something only two letters long. Also, it's the login name that is too short.

I searched the public source code on GitHub for "too_short" and got 8 hits. Two of them were related to account_course_user_search, which sounds right for this endpoint. Neither has the right message, though. It has SEARCH_TERM_TOO_SHORT and gives the message about needing at least 3 characters (even though 2 characters works). The second is for the web UI and gives a similar message within the browser. The first was actually JavaScript, which should not affect things if you're making an API call.

The third one was dealing with pseudonyms (good) and unique_id (good), but and includes a message of "too_short". That sounds like what we're looking for. That is just the errorMap for pseudonyms, though. A few lines later, it has a normalizeErrors function that goes through all the errors and if any of othem are 'too_short' then it adds that error. It just fancifies the error messages.

From that it looks like the unique_name is too short. Unique name is called the pseudonym or the login. The pretty name people use to login.

I can easily find where something is too long -- more than 255 characters. Finding where something is too short just says "required". That makes it sound like you have a login somewhere that doesn't have a login name (it's blank, null, or '')

It appears that the default user search returns users in sortable name order (at least for my first page of results). If there was no name or login, then would be first, which would mean that it would cause errors right away.

You might try sorting in descending order and see if that allows you to get the first page.

GET <instance>/api/v1/accounts/self/users?order=desc

That may not help because it would have to sort by a non-existing value and that could still throw an error.

You could try getting the second page of users to see if that bypassed the bad record.

GET <instance>/api/v1/accounts/self/users?page=2

Another thing you could do is go to Admin > Settings > Reports > Provisioning Reports. Select All Terms, Users, and include deleted objects (I don't think it's deleted, but you might as well be safe). See if you can get a list of users and then look for ones with missing information. If you do, then you can edit that user by the Canvas ID and fix the missing information.

If I had to guess as to how this happened, I would think someone tried to create a user without supplying all of the required information and it messed things up. I know that when I was first learning to use the API, it was easy to miss some step. That's another reason for the recommendation to work in the beta instance when testing things.