Showing results for 
Search instead for 
Did you mean: 

Should we be able to lock default email address from being changed?

Jump to solution

So we have run into an interesting situation with our Canvas external tool integration.  Currently we have quite a few external tools installed in our Canvas instance.  Many of these tools are setup to allow access through canvas but also directly though the local login such as Taskstream, Kaltura, Voicethread to name a few.  We have found an interesting issue where students are changing their default email in Canvas.  Our students cannot delete their institutional email as we have that box unchecked in the account settings.  However since students can change their default email address users are creating problems with using the tools outside of Canvas.  Example of issue below:

Suzie Student changes her default email address to instead of  Suzie then logs in to Taskstream via Canvas integration and her account is created.  However her new Taskstream account is now associated with the primary email address that is passed over via LTI,  If Suzie just accessed Taskstream via Canvas then this would be no big deal.  However, if Suzie logs in to Taskstream directly via our Taskstream portal with SSO her institution credentials and email gets passed on to Taskstream.  Taskstream sees there is no account for and creates a new account.  Now Suzie has a brand new account that is not linked to Canvas and has none of her prior work available to that account because the system sees these accounts as 2 separate users.

Doing more research i am finding other tools that we allow multiple entry points where this is happening.  Some portals are not letting users log in via vendor gateways because the emails do not match so it sees the user as not having an account.  It appears that LTI is only allowing the passing of " lis_person_contact_email_primary" and not the institutional email address.  There are no other email parameters that i can find.  Canvas ID and other canvas variables being passed do not help as obviously those will not be passed by our SSO in the vendoer login page.  Email address would be unique and tie the accounts together but if a student changes it then things break as in above.

So, should we be able to lock the default email address from being changed?  Users can still add other email addresses and control forwarding via our local university forwarding service.  Any of you LTI and tool experts out there seeing something i am missing?  Maybe a better variable to recommend to vendors to link both entry points (Canvas and vendor portal) so that we do not run into dual accounts setup or blocked access outside of Canvas?  I am kind of surprised no one has run into this issue yet so maybe i am missing something?  Interested in hearing everyone's thoughts.

1 Solution

Accepted Solutions

Our institution had a similar issue, and the response I got back was to use CSS to hide the "Add email address" option.  Here's the full thread:

Is there a way to prevent users from adding additional email addresses?

View solution in original post

16 Replies

Our institution had a similar issue, and the response I got back was to use CSS to hide the "Add email address" option.  Here's the full thread:

Is there a way to prevent users from adding additional email addresses?

View solution in original post

Hey Anthony,

This was the initial thought we had but I would really like to avoid doing this as this is not a true fix in my mind.  We also hide the "Add App" and toekn creation buttons right now as users were doing things with tokens they should not and adding apps that were not secure or vetted by our security team.  Educated users can find out how to override CSS includes that do these things.  There are addins for every browser that can help with this among other things.  It would be much better in my mind if Canvas would allow us to define what we do or do not want our users to change for our instance.

It is getting to the point where our Canvas has way to many overrides and i was really hoping for a more stable fix.  I appreciate your answer though as it likely confirms what i already thought.  Might need to make a feature request on this then and drum up some support.

if you do make an ideas post, let me know.  I'll vote on it and pass the link on to others that are interested.

Community Member

Did anyone ever create this as an idea request? If so, can you please send me the link to add my support? This has come up as issue for us, and it seems to me like it should be an optional setting for institutions to block students from changing their default email address from the one provided by the institution.

Thank you!

Community Member

This has also become a problem for our organisation. We have also applied a css workaround but there are other ways users can change their default email.

On the account settings page, you can select "Edit settings" and also change it here.

In my mind, however, this is a design issue. Email is often used as a unique identifier in addition to being used for email.

Different organisations also have different policy around email addresses and email address re-use. Here we have a 'friendly' email which is firstname.lastname@domain format and this is re-used. We also have a unique identifier alias of xxxxxx@domain which is more suited to use for identification context.

The problem with the current design for us is that we are forced to use the unique identifier for consistent user mapping in LTIs and so that SSO to other entry points for the LTI tools (mobile apps, direct access) works and the accounts can be linked between services.

The problem for users is that they want their friendly email, and as soon as they find a way to change it they do.

I believe what would help from an integration perspective is a consistent identifier that can be shared between the LMS, LTI tools, and any back end SSO systems. It would need to be in email format and delivered as an email to the LTI tools. The user should be unaware of it and unable to change it.

A further forward looking fix might mean the LTI standard needs updating with consideration to these issues and SSO best practices. That however would come to late for the current problems.

Hi Anthony:

We are running into a similiar issue. What css code did you use to restrict student's abilility to additional email addresses.

Hi Alicia,

Im not sure what the css was in 2016 but we are currently doing it with the following javascript. Note that we do allow users to add and remove their own emails, this only prevents them changing which one is the default, and because of that - removing it. Its not bulletproof as its client side but it has worked well enough.

// UOFA JIRA MUT-455 : Disable end user ability to change default email address

// UOFA JIRA MUT-483 : Maintain email configuration in Canvas

$(“select#default_email_id option:not(:selected)“).remove();

You may find you also want this css to remove the delete account button:

/* this hides 'Delete My Account' button in user account settings */
a[href=""] {
display: none !important;

Hi Anthony,

I am trying to add your custom javascript to my test instance because I would like to use your process. I am not a coder so I need some beginner help with why I can't get this to work. I copied and pasted your two lines into notepad and saved as .js. I added to my theme editor and saved changes. It seemed to take the file and is still visible on the page. I went back to my people area and "acted as" a student with two email addresses and I do not see a change in behavior on the screen. It still allows a change to which email address is "default."

Can you help me with what I am doing wrong?


Ann Strickland

Hi Ann,

I'm working together with Anthony.

You've to do the following:

  1. Your institution must have custom css / javascript activated. As far as I know Canvas Support or your Success Manager can help with that.
  2. Go to "Admin / Your Institution / Themes".
  3. Click on your current theme and select "Open in Theme Editor".
  4. Select Upload and click on "View file" for CSS and JS. Download the files and modify them locally.
  5. Click into the CSS / JS URL input field and select the appropriate modified file.
  6. Click "Preview your changes" and later "Save theme".

This will add the custom CSS / JS to your page.