API-created active users and communication channels

[vkg]

Hi, folks.  We're working on an application that involved our creating Canvas users in our instance who have external email addresses.  We're finding in our test environment that these users, who are added in active (not pending) status, are never sent email notifications of things like announcements (we test this in admin tools/view notifications).  My theory is that it's because we're not setting the communication_channel [skip_confirmation] value in the create user API call ​.  So since the communication channel is never confirmed, Canvas never sends email notifications to the account.  But I'd love a 2nd opinion on whether this is logical and/or any other avenues to investigate!

Many thanks,

Victoria

[amcdona]

University of Florida creates its users via API with the parameter skip_confirmation=1

The users have active (on profile settings: blue email address rather than gray) communication channels from the start.

Andrew

[20764325]

Hi Victoria, is your test environment by any chance the regular Canvas Test environment (umich.test.instructure.edu)? Notifications aren't send by the Test and Beta environments.

We stopped using the API to create users last February because we found the communication channels parameter to be unreliable. When we were creating users through the API, we had many users with greyed out email addresses and whose workflow_states returned "unconfirmed" but who were receiving notifications from Canvas. However, there were others who also had workflow_states of "unconfirmed" who were not receiving notifications from Canvas. We changed our feed to add users through SIS Import to ensure that email addresses were automatically set to "active."

[curtain]

We just recently went around and around about the same thing.  We are now doing skip_confirmation and they are getting their announcements and notifications.  FYI, without confirming that a user can also not set their profile picture.  Those are the only 2 consequences that we found for people not confirming.  So we skip_confirmation now so they get notifications immediately

sf

[ckretler]

I am seeing similar behavior to what Marlee is reporting.  Email changes set by csv file are immediately active, whereas changes made by the API results in a communications_channel with a state of 'Unconfirmed'.  Here is a template of our POST: myinstance.instructure.com/api/v1/users/:user_id/communication_channels?   communication_channel[skip_confirmation]=true   &communication_channel[address]=emailATplace.edu   &communication_channel[type]=email Scott and Andrew, could you post your full parameter set?

[curtain]

here is our setup:

POST 'https://k-state.test.instructure.com/api/v1/accounts/1/users?user[name]=curtain&pseudonym[sis_user_i...=curtain+3@ksu.edu&communication_channel[skip_confirmation]=true&user[skip_registration]=true&pseudonym[send_confirmation]=true'

[ckretler]

Thanks Scott, It appears that email changes must be made via the communication_channels api.  Do you have a sample call for modifying a user's email address? - Chris

[20764325]

The script that I used to do that (where HUID is the sis_user_id) is update_comunication_channels.py takes in a dictionary of HUIDs and email addresses as an input, adds...

That being said, it only added a new email address for the user. In order to change the primary email address for a user, we had to masquerade as the user and select the new email as the primary email address, which we did using Selenium.

[ckretler]

Thanks for the response Marlee,

Did you consider updating the user's email address using SIS imports, as you did when creating new users?

[20764325]

I didn't really consider that because we wanted to allow people to keep their existing communication channel when adding the additional email address, rather than replace their existing email. Also, because this was a one-off, I wanted to avoid any potential conflicts with our feed processes (they overwrite emails that are fed from our SIS and changed using SIS imports but not those that are manually edited).

[ckretler]

I have been in contact with Instructure about our difficulties modifying a user's email address.  Our issue was the misuse of the skip_confirmation parameter.  The following does create an active channel that receives messages:

ourinstance.instructure.com/api/v1/users/:user_id/communication_channels?

communication_channel[address]=somebodyATsomewhere.edu

&communication_channel[type]=email

&skip_confirmation=true

We had previously been erroneously using the following parameter:

&communication_channel[skip_confirmation]=true

Which is need for creating a new user account, but not for updating a user's email address.

[shane_ohara]

Has anyone on this thread identified a way to update workflow_state to "confirmed" instead of "unconfirmed" through an API call?  Our issue is that users are created without email, so LoginID is pushed as the default email. When the email comes through it is added by making an 'Edit user' API call, but the API doesn't have skip_confirmation as a value that we can include, so we're finding users with unconfirmed emails. Example being:

{

    "id": 25116,

    "position": 1,

    "user_id": 122,

    "workflow_state": "unconfirmed",  (

    "address": "email@unh.edu",

    "type": "email"

  },

Any thoughts on how we can confirm this workflow_state or confirm via the API (see: Canvas LMS REST API Documentation for edit user)

Thank you!

Shane

[20764325]

Hi Shane,

Sort of. I've confirmed an email address when adding it through the 'Create Communication Channel' API call and using skip_confirmation. It's not through the 'Edit User' call. Canvas LMS REST API Documentation

That being said, the documentation only seems to include create and delete, not update, so you may have to delete the emails and add them again.

Good luck!

Marlee

[shane_ohara]

Interesting - I am concerned that by deleting we are retiring them in the system. Do you know if by deleting and then reconciling with our identity management system, and then making a new call...will that result in an error since the email technically still resides behind the scenes?

[20764325]

I'm not really sure. When I ran this, we had a feed that updated the primary communication channel, but I was able to run a set of scripts to change a primary email address that added an email (with the skip_confirmation) and make the new email the primary. This did not result in an error since our feed lets user changes take precedence and we left the existing emails there.

[themidiman]

Hi  @shane_ohara ​ or anyone else,

Have you tried seeing what the API returns for a user account that was provisioned via the SIS Upload API endpoint? (i.e. the users.csv file)?

My thought is that you would set the login_id string and the email string to be the same thing in the users.csv file.

[shane_ohara]

We no longer add users through SIS (users.csv). All users are created by an API call that originates from our identity management system. The APIs though are extremely limited.

[stuart_ryan]

Hi  @vkg  et al.,

I am going through having a look at some of the early days in the Canvas Developers group, and checking in to see if older enquiries have been answered. I also noticed there hasn’t been any discussion on this question in quite some time.

I am wondering, were you ever able to resolve this with the assistance provided? I am hoping I can assume that it is well and truly resolved by now, but if not, please let us know and we can certainly have another look. Alternatively, if have some insights you may be able to share for others that would be awesome too!

I will mark this as assumed answered for the time being, however, by all means please let us know if you still have an outstanding question and we will take a peek!

Cheers,
Stuart

[a1671492]

I just wanted update this thread, that it seems there is still a gap in the users and communication channels API and there does not seem to be a way to set a default email in the confirmed state via API.

The users api can set a default email (moving the existing one to another comms channel slot) but it can not accept skip_confirmation=true.

The communications channel API can list, delete, or create channels, but it can not update channel and thus can not set the confirmed state. It also cant not create a channel by position, thus it can not create the default communication channel for an existing user.

I think we need one or more of:

1) user API needs to be able to accept skip_confirmation=true when setting the default email

2) the communication channels api needs to be able to update an existing channel, setting skip_confirmation=true

3) the communication channel api needs to be able to create a communication channel in the default position with skip_confirmation=true

One or more of these options would make what we need possible to maintain an existing system where users have non-standard default emails.

Also worth noting, there is another oddity where the global setting  "Users can delete their institution-assigned email address" must be cleared for the user API accessed with an admin token to be able to update a users default email. If "users" can not delete their own institution-assigned email address, the API strangely returns 'unauthorised' to admins for this action.

[a1671492]

It turns out that via the communication channels API you can delete a comms channel if its present but not validated, then you can create a comms channel with skip_confirmation=true, then when you know it exists in the right state you can set it to be default with the users API, which moves the existing channel thus it ends up in the default slot with the confirmed flag set.