Limit or restrict toolbar 'insert' features in the New Rich Content Editor


When instructors want students to submit their work in an assignment as a 'text entry' only, while not allowing any file uploads as an option, the new Rich Content Editor has allowed students with the opportunity to still 'upload documents' as a formal submission using the 'upload document' feature available under the 'Insert' tab of the new RCE toolbar. As such, new insert tab has created a 'back door', if you will, allowing students to retrieve a file (i.e., saved WORD document) from their personal device and upload it as a formal submission.  The link generated in the text box then becomes the official submission, negating the need to copy/paste or manually enter the full online text entry.

Is there a way to have the system 'block' students from the insert feature of uploading documents when the instructor sets the submission to 'online' - - > 'text entry' only?

Instructure Alumni
Instructure Alumni
Status changed to: Open
Community Explorer

When students are asked to use the text entry submission type in assignments they are presented with the full scale RCE allowing them to format text and even link to files. It is possible to have text entry submissions be anonymous but when students link to files the URL exposes the students name rendering the anonymity useless. It is apparently a feature request to have students anonymity fully functioning even in an anonymous text submission assignment therefore I am suggesting the following since this is not considered a bug:

Have the RCE be stripped down so that tools within the editor that create content that link to resources that expose the students names in anonymous assignments can't be used. Since it is not intended use to have students link to files in the text submission type (as I have been told by the support team and our CSM) it should also not be possible and not depend upon whether or not instructors have given correct instructions and whether or not students read these instructions.

Community Explorer
When an instructor establishes the permissions in the 'edit' settings of an assignment, and they DO NOT want the submission to be completed via a file upload, the box is left unchecked:


However, when a student goes to submit the assignment via a 'text entry', by means of the New Rich Content Editor, the student can navigate to the New RCE toolbar and click on the 'INSERT' tab to reveal a 'back door' way to upload a WORD document (for example) as a way to technically submit an assignment through text entry.  HOWEVER, the process of submission is still a file upload.


The old version of the Rich Content Editor did not have this feature as part of its toolbar options.  As such, the request has been to create some type of 'governor' that turns off the 'insert' option of 'upload document' or 'user documents' whenever the 'File Uploads' setting box is left unchecked.
This truly is an issue that didn't exist with the previous version of the Rich Content Editor.
Instructure Alumni
Instructure Alumni

Hello! Thanks for bringing this situation to our attention. 

I don't think we can remove the ability to embed documents entirely from the current "text entry" submission type because there are legitimate reasons an instructor might expect students to embed documents in their assignment submission. Additionally, LTIs that support document embeds (think Google Drive, OneDrive, Dropbox, etc.) are also accessible in both the old and new RCE for "text entry" submission types.

What issue is it causing that students are sometimes embedding a document instead of typing their submission directly in? Understanding the problem better will help us consider possible solutions that don't interfere with assignments using the functionality as is.

Community Explorer

Thank you for your response! 🙂

The key issue centers around students completing their work in a Word document, or other Canvas-friendly file type, and using the 'upload document' as a work-around to submit the work, rather than typing the submission as a text-entry.  As such, some instructors have noted the following when it comes to Turn It In: I am using Turnitin and attachments don’t seem to get reviewed. 

I realize Canvas allows for grading of 'attachments' via SpeedGrader, however, if the option for file upload is NOT checked by the instructor, then the 'back door' document upload option shouldn't be accessible/available.


Community Explorer

I completely agree. It is very frustrating to set parameters for an assignment only to find later that they meant nothing.

In response to dlyons:

"there are legitimate reasons an instructor might expect students to embed documents in their assignment submission" - Sure, and if that's what they want, they can select that themselves using the "file upload" option. 

"What issue is it causing that students are sometimes embedding a document instead of typing their submission directly in?" - The issue, in one sense, is simply that Canvas isn't respecting the wishes of instructors and is effectively overriding our settings. (There are multiple examples of Canvas doing this - such as where it issues notifications to students without any regard at all for what instructors actually want - and these collectively become infuriating. I work better when I'm not seething and cursing.) In a more practical sense, efficient grading generally entails slotting into a "flow," and it is disruptive and aggravating to have to break that when student responses sporadically turn up as links that have to be clicked, particularly when you have done everything you can at your own end to avoid that.

Status changed to: Archived
Comments from Instructure

As part of the new Ideas & Themes process, all ideas in Idea Conversations were reviewed by the Product Team. Any Idea that was associated with an identified theme was moved to the new Idea & Themes space. Any Idea that was not part of the move is being marked as Archived. This will preserve the history of the conversations while also letting Community members know that Instructure will not explore the request at this time.