Temporary button to uncheck the Disallow Threaded Replies option in all Discussions

[TamasBalogh]

Update: The self service button is now available in Beta environment

In a previous post, we explained the 'Disallow Threaded Replies' option was inadvertently applied to discussions that were intended to remain threaded. Unfortunately, due to the nature of the update, we are unable to identify which specific discussions were affected.

Contrary to the popular belief that discussions are intended to be threaded, our analysis of historical data shows that approximately one-third of discussions are not threaded.

Since we couldn't determine whether discussions in each course were intended to be threaded, and given the large volume of unthreaded discussions, it wasn’t feasible to update all of them. To reduce the burden on instructors and streamline the correction process, we're introducing a temporary self-service option that gives instructors control over their courses. 

A new button will be available on the Discussions Index page, allowing users to bulk-enable threaded replies in all discussions in a course by unchecking the 'Disallow Threaded Replies' option. Please be aware that this action will apply to all discussions in the course, not just those affected by the error, and the change is irreversible.

This temporary option will be activated on Monday, September 16, 2024, and will remain available until the end of October. Given the issue's urgency and the solution's simplicity, we have decided to release this update ahead of our usual schedule to provide instructors with a timely fix. We have thoroughly tested the functionality to ensure that it works as intended without introducing any unintended side effects.

Showing alert in the Discussion Index Page

The self-service button will only be visible in courses that still contain at least one discussion affected by the issue. If your discussions have already been manually updated, modified via API, or resolved through support, you will not see the button. Once the button is used and the update process is successfully completed, the notification will no longer appear in that course.

If you dismiss the alert but later decide to proceed with the update, you can either clear your browser cache or access Canvas from a different browser or device. You can see the overall flow of the process in the below video:

Additionally, if your course content is derived from course copies or synced via Blueprint courses, please ensure you run the update in the original course first. Otherwise, the synced or copied discussions will retain the incorrect setting after each sync or copy.

We sincerely apologize for the inconvenience this has caused and appreciate your understanding as we work together to address the issue.

[Mikee]

Hi @TamasBalogh - is the deployment date localised? (here in Australia on the East Coast we're somewhat in the future as we're GMT +10, so will be good to confirm if so)

[TamasBalogh]

Hi @Mikee, the deployment will happen at 6am ET which is 8pm GMT+10. 

[tvannorman]

@TomasBalogh,  Thank you for the update.

Is there a way this button/option could be set up permanently to allow the faculty/teacher to default all Discussions (not Announcements) in the course as Threaded or Not Threaded?  Then could the faculty be able to change that setting on an individual Discussion basis?   

You stated that your research showed that 2/3 of the Discussions are threaded.  It is surprising that Canvas/Instructure would choose to appear to go against the significant majority of the Discussions.

[cinman]

@tvannorman I logged into this thread to make that exact comment.

"You stated that your research showed that 2/3 of the Discussions are threaded.  It is surprising that Canvas/Instructure would choose to appear to go against the significant majority of the Discussions."

There's not much else to say about the decision.

Again, thank you for the update @TamasBalogh.

[TamasBalogh]

Hi @tvannorman, 
I'm not sure what do you mean. Discussions are threaded by default. If a faculty member creates a new Discussion, the "Disallow Threaded Replies" checkbox is unchecked by default. Would you like to see a course level setting to set what is the default setting for threaded/not threaded?

[helfco]

Thanks @TamasBalogh for addressing this.

Our district ran an API to address this, but now many faculty are complaining that "edited by (Admin Name)..." appears under their API edited discussions. Will this button remove the "edited by..." ?

[diane_meterko]

@TamasBalogh - Will you please provide more details regarding who will see that message? A lot of our associate faculty who teach classes don't have access to edit their course in Canvas. Will the message be displayed to those who are enrolled into a course as a the Teacher role or will the message appear to those Account roles that have access to edit discussion forums? Thank you!

[adamsma]

Ok there is a potential problem with this temporary fix..."the new button will be available on the Discussions Index page"...which many folks do not look at when managing discussions...the other problem is the choice to make this change based "historical data shows that approximately one-third of discussions are not threaded." So what about the other 2 thirds? That seems like a really poor desicion when 2 out of 3 folks do indeed use threaded discussions and only 1 doesn't...why not leave it as it is and let the faculty decide? 

Somebody flubbed.

[BrianHall76]

@helfco based on how I read the blog post I would guess the button would not be visible in courses modified by the API and therefore wouldn't fix/remove the "Edited By" notation.

"If your discussions have already been manually updated, modified via API, or resolved through support, you will not see the button"

[tvannorman]

@TamasBalogh, Once the Disallow Threaded Replies was  implemented, the discussions that were not actively threaded were automatically defaulted to "Disallow Threaded Replies". This occurred in courses that had not been published, therefore did not have active threaded replies within their discussions.  

I would consider the automatic setting of a field within a discussion that is not active, therefore has no threaded replies, defaulting the setting.

While this may not have been the intended consequence, it is what happened.

[helfco]

@BrianHall76 yes I'm sure you're right. I'm wondering if there's a workaround. Maybe create an unpublished discussion, set it to disallow threaded replies, then see if that triggers the fix button which when clicked will remove the "edited by..."

I tried fixing via the API using as_sis_user... to masquerade, but couldn't get that to work. The only thing that worked was getting an access token generated by the actual teacher and running the API with that token. This involves meeting with the teacher and getting the token securely which I want to avoid.

[TrinaAltman]

@TamasBalogh  This seems like a good mitigation measure for this issue. Is there a reason it needs to be temporary? A lot of our folks have already fixed the problem in their fall courses out of necessity, but we'll be facing this same issue in January when our spring 2025 term starts and instructors/designers copy content from spring 2024 courses that were affected into newly created spring 2025 course shells. Since the message/option only appears in courses that still contain at least one discussion affected by the issue, is there a reason it can't persist into future terms since the issue will be ongoing for a while due to course copies of older courses?

Will the option appear in new courses that are created after the change is made on 9/16/24 (assuming they end up with affected content from a copy)? (I.e., Will the new option only appear in courses that exist on the system when that change is made?) If it only appears in existing courses, then it wouldn't help with my spring 2025 scenario above anyway since those courses don't exist yet. But we will have this issue again then, so I am wondering about our options going forward after this temporary change goes away at the end of October. We will still have courses affected by the issue in the future.

[Mikee]

@adamsma - yep, and this is the 'oh golly' fix for the 1/3, seemingly not recognising how time-poor and unconscious a lot of users are. I'm worried that this is a simple and easy "make the orange box go away" that will lead to further complication for support and admin staff.

A lot of admins and developers are hard-pressed to recognise how advanced they are, and how things that appear simple and straightforward to them simply aren't digested easily by a lot of users.

A lot of folks when given a yes/no prompt, will accept it because that's what the internet at large has trained them to do - cookie acknowledgement notices a prime example of how this continues to be the case. 

I'd prefer to see this option moved from the headline act (given it's for at most 1/3 of the teaching community) in the Discussion area to the right-hand settings nav with an alert badge/icon that there's something new in the menu (as example of how to surface it to users without affecting their workflow)

[TrinaAltman]

@Mikee My understanding is this mitigation is intended for the 2/3 (and in our case I suspect a much higher percentage than that even). Users that click the button will have threaded discussions in their courses (and only threaded discussions - I am not clear if they can go back in and then select the 'Disallow threaded replies' option for specific discussions if they have only some they actually do want unthreaded).

[mwolfenstein]

At the risk of overemphasizing the point, I'm writing to concur with @tvannorman and @cinman regarding the part about the rationale behind the initial rollout being the historical data indicating one-third of discussions as not threaded. I'm not going to question the direction this was rounded in because even taking it at face value it means Instructure made a choice where 66.6% of the use cases that rely on being able to make replies could potentially have this stripped away because 33.3% had replies disabled. I just want to emphasize that not only was this choice made in relation to a pattern across a significant minority of implemented discussions, but it was also done in the direction where the users who rely on having that feature for their assignments lost it, where at worst it would only have created some confusion for discussions that didn't want threads to have them available. In addition, it's worth pointing out that the milestone/checkpoint due dates, one of the most heavily requested features in Canvas's history, is a feature that is directly connected to threaded replies.

@TamasBalogh I appreciate your communication with us, and the fact that a step has been taken to mitigate the issue this caused even if it comes a little late. I'm writing this response in the hopes that as the Canvas team continues to debrief how this issue has played out, they take two things into account going forward. First, that when they need to make a decision like this, a holistic approach is taken that includes asking questions like, "What is the least possible disruptive way we can push this implementation based on existing use patterns?" A thorough engagement with that question would have likely resulted in a different approach. Second, in the instance that a bad implementation happens (and they will because it's software development and it happens, that part is understandable), I hope the team gives a little more consideration to how the messaging is likely to come across. When you let us know that historically a third of historical uses follow this pattern, you're basically telling us that you decided against the other two thirds which just isn't very encouraging to hear. We get that 1 in 3 is a lot, but it's also still literally half as many as the ones that are using the tool in the other way, and that just makes it seem like the decision really wasn't thought through as well as it could have been.

[TamasBalogh]

Hi @diane_meterko Thank you for this question. Only users with edit discussion permission will see the button. 

[TamasBalogh]

Hi @TrinaAltman we decided to be temporary solution because we designed and implemented it with urgency, therefore it stands out from the overall design of Canvas/Discussions. We hope that all affected discussions, courses will be dealt with in this time period. It doesn't matter when you are creating a course, if there is any discussion which has the old type, the button appears. 
In case you are using course copy to create next semester's course shell, I'd suggest and ask you to run the process on your original/blueprint courses as well to avoid further issues in the future. 
At end of October, we will check how many discussions might still have the wrong type and might reconsider the solution to be present longer, but ideally, all discussions' type would be updated to either threaded or not_threaded. 

[TrinaAltman]

Hi @TamasBalogh as you said in your post, there are many discussions that are intentionally unthreaded. We are hesitant to run a process to change all discussions to threaded in older courses as it would impact copied versions of those - and as soon as someone makes a reply, the instructor can no longer change the setting to unthreaded as they intended it to be.

It is unrealistic to think schools/instructors/designers will be able to mitigate this individually in all the older courses that may be copied until those copies are actually made in future terms. I don't see an issue with leaving the message since it will only appear in affected courses - and those courses will still need to be fixed. Courses are likely be affected for multiple semesters and possibly years to come. We don't use blueprints. Our instructors manage their own courses individually. Every course is different. 

[TrinaAltman]

@TamasBalogh will the change be made in beta in advance of production systems, and if so, when?

[pburwick]

That is interesting data indeed! I am thinking that based on the number of issues it has caused at my home college, we are probably in the 66% that are threaded...

Thank you for t he fix!

PB

[diane_meterko]

Thanks @TamasBalogh !

You mentioned, "Only users with edit discussion permission will see the button." - Our teachers have access to edit ungraded discussion forums, but not graded discussion forums. They can see the edit button for graded discussions, but when they try to save, nothing happens. How will those teachers be impacted by this temporary message?

I should have clarified that earlier. My apologies.

[TamasBalogh]

Hi @mwolfenstein, @Mikee, @tvannorman, @cinman, @adamsma,

Update: I mistakenly wrote July 20, but I meant August 14th

Let me elaborate on the 1/3-2/3 and the reason of the original change. I purposely avoided going into too much technical details in the blogpost.
The team tried to find the least impactful way of introducing the threaded/unthreaded option to Discussions Redesign as it was left out initially. As you know, it was added on July 20th.
The legacy Discussions had 2 possible types (discussion_type property in a discussion object) threaded and side_comment. In case an old discussion allowed threads, the type was threaded, if not, side_comment.
For the discussions which were created with Discussions Redesign, but created before August 14th, the type was set to side_comment. (This was the original mistake which led to this situation). Since Discussion Redesign is available for a while now, it was not possible to differentiate if a discussion was created with the legacy engine and the type was explicitly set to side_comment, or with Discussions Redesign and implicitly set to side_comment.
Therefore, the impacted Discussions are the ones which were created with Discussion Redesign before August 14th and there is no threaded replies yet. That number is a fraction of the total discussions.

With the Disallow Threaded Replies option, we introduced a new type: not_threaded and all of the newly created discussions are set to either threaded or not_threaded, based on the setting of the Disallow Threaded Replies.

If we would have treated the side_comment type discussions as threaded, we would have impacted 1/3 of all discussions which is much greater than the fraction I mentioned above.

I understand this is not the ideal situation for many of you and I'd like to apologize for the inconvenience we caused again.

[TimVanNorman]

@TamasBalogh 

Thank you for the context.  The main issue is that the decision was made to impact the 2/3 (66%) of discussions that are threaded in favor of the 1/3 (33%) that are not.  This is especially concerning in that it did not show up in Beta before being turned on in Production which violates the standards that Instructure was built on with regard to adding functionality.

Having a button/option that would allow teachers to default all discussions in their course as threaded or unthreaded would solve the issue Instructure attempted to resolve, and failed, without negatively affecting any of the courses.

I would love to know your thoughts on this.

[TrinaAltman]

@TamasBalogh in this post, you said, "Therefore, the impacted Discussions are the ones which were created with Discussion Redesign before July 20th and there is no threaded replies yet."  Does that mean if a spring 2024 course which did have threaded replies is later copied to the spring 2025 course shell, that the discussion settings for those discussions in the spring 2025 course will all be threaded, i.e., the 'Disallow threaded replies' option will be unchecked? (This would be good news.)

Another scenario: If a development course with (no students enrolled) has set up Discussions (with no active discussion activity) - what are the specific situations by which the 'Disallow threaded replies' option may have been checked by the changes made on 8/14/24? (These development courses will be copied into real courses in the future.)

Understanding the specifics of which discussions were impacted is critical to our institutional planning around how to manage and mitigate this very problematic issue going into the future.

[Code-with-Ski]

I have created a user script that can be used to update the threaded reply setting for discussions in bulk within a course.  This can help with other use cases that aren't covered by this temporary feature (i.e. bulk update feature after this temporary solution is gone, ability to update only some of the discussions, ability to update discussions that were already been updated and/or not affected by the original issue) You can choose to either enable threaded replies or disable threaded replies. It will load in the relevant discussions based on the update you want to make.  All listed discussions are selected to be updated by default, but the user can uncheck any discussions they don't want updated.  Clicking "Update" and confirming will begin the process to update the setting on the selected discussions. User Script to Bulk Update Threaded Reply Setting of Discussions in Courses 

The user script is set-up to require a user to be an Account Admin or teacher to use it. It also includes a couple permission checks to see that they can manage content and change settings based on the ENV.permissions of the Discussions page.  If you wish to change these, you can make your own version and adjust these checks towards the beginning of the script.

NOTE: I have it set to exclude discussions that already have replies when performing an update to disable threaded replies.  You will need to check these discussions individually to see if it is still possible to disable threaded replies on these since in my testing the API didn't throw an error when trying to disable threaded replies on a discussion that already has threaded replies.

[TamasBalogh]

Hi @TimVanNorman,

We were considering to add this to the release cadence, but given the urgency to have a solution, we decided this should be handled as a hot-fix, as our customers are come back online and facing the issue now. 

Having a default setting on course level on threaded/not-threaded discussions might be a good idea, but it wouldn't have solved the issue. I'll add the idea to my list to investigate/consider. Also you can create an idea in the community as well.

[TamasBalogh]

Hi @TrinaAltman, 

Yes, Discussions with threaded replies in them should be not affected, but to be sure, please navigate to those courses and check if the warning shows up or not. 

For your development courses, the impacted discussions are the ones which were created with the Discussions Redesign before August 14th, 2024. If you were using the legacy Discussions when created these course shells, they should not be affected. But again, to be sure, please check the development courses as well. 

In case you find any course where the problem occurs and you'd like the Discussions to be threaded, run the self-service button process. After that, you can safely copy the course content without any ongoing issue.

[TrinaAltman]

Hi @TamasBalogh,

@Tamas - thank you for the specifics on which discussions may be impacted in the future. That really helps with our planning, mitigation, and communication of the issue going forward.

That said, has there been any additional thought to keeping the button that allows instructors to update all their discussions at once in place beyond October? Since it only appears in affected courses, it seems it would continue be a good reminder of the issue for instructors in affected courses prior to students not being able to complete their assigned activities (e.g., respond to another student's post) AND would give instructors a way to fix all their discussions at once instead of entering EVERY discussion in their class to check the settings for multiple terms in the future. This would be much better than us continuing to communicate about the issue (or would allow our communication to just say, "look for the button - if it's there you may have an issue") when only some courses are affected. Continuing to communicate will begin to cause even more confusion and concern given that only a subset of courses will be impacted in the future, and the only recourse for instructors would be to check the settings in Every. Single. Discussion. That is a TON of clicks and extra work/time for them. Being able to isolate to just the ones with the message and button and allowing them to fix them all at once would be extremely helpful going forward.

Multiple times you have mentioned checking courses and "We hope that all affected discussions, courses will be dealt with in this time period" which is a TON of work and unrealistic for us to expect our busy instructors and/or designers would or could do this in all the discussions for all their courses or the source courses before they copy in the future. You also said, "In case you find any course where the problem occurs and you'd like the Discussions to be threaded, run the self-service button process. After that, you can safely copy the course content without any ongoing issue." In most cases, the problem won't be apparent until the copy has already completed - and in some cases it won't be apparent until a student is stuck not being able to reply as instructed because the instructor didn't realize the issue was there. Keeping the message and button seems the easiest way to mitigate the issue going forward into future terms, and to alleviate a lot of concern, confusion, and frustration for our users.

[rpsloan]

Hi @TamasBalogh! Would discussion type "side_comment" be retired and it would either just be "threaded" or "not_threaded"? While the banner is helpful, I don't foresee a lot of users clicking this, and I've also seen (at least in my test course) that discussions that were created prior to May 2024 (which is when we enabled Discussions Redesign) has the banner showing up because at least one forum is set as "side_comment". And the forum was created back in 2021/2022 and we didn't have redesign enabled back then.

Our team can manage assisting users and letting them know they can manually disable the checkbox. Is the intent of this fix to make sure "side_comment" gets replaced as either "threaded" or "not threaded"? What happens to forums that stay as "side_comment"?

[TheodoreWalley]

First: Way to not accept responsibility. "Even though it's our fault the error occurred, technically we have data that says we're not wrong."

Second: Math. Even if you have data that supports 1/3, that's still no where near a majority to warrant a change or an implementation. Data driven decisions would be looking at 1/2 or higher to support your conclusion. 

I apologize for the curtness of my response, but this was a pain to keep corrected for all my classes, and to then be told "well, technically we were right to do it." is professionally insulting.

[benjamin_rodrig]

I think it's great to give the ability to revert from unthreaded to threaded. 

What would also be good would be to increase the thread depth beyond three.

Currently it looks like after three levels in, replies stack chronologically.
This is a bit confusing for users and limits engagement because the modality changes from a Reddit like environment to a YouTube comments type of environment. When it does switch over, it's easy to get lost and difficult to see who replied to who. 

Please consider bringing back deep nesting the way Classic Discussions had to help foster meaningful educational engagement.

[Anna-Hayman]

Hi @TamasBalogh, 

Apologies - I didn't '@' correctly when I initially posted.

Please may I request clarification on "A new button will be available on the Discussions Index page, allowing users to bulk-enable threaded replies in all discussions in a course by unchecking the 'Disallow Threaded Replies' option. Please be aware that this action will apply to all discussions in the course, not just those affected by the error, and the change is irreversible."

Is it just discussions without replies which are in scope? If the button is used and there is another, unaffected discussion with 'Disallow Threaded Replies' intentionally ticked, will its setting be updated if it has already received replies?

Many thanks!

[TamasBalogh]

Hi @rpsloan,

Yes, our goal is to retire side_comment as it got replaced by not_threaded. Currently, we treat them the same. Any newly created discussions have either not_threaded or threaded type and if someone edit a discussion, the type will be updated based on the Disallow Threaded Replies checkbox.
The self service button appears if there is any discussion in the course with side_comment type, but that doesn't imply the discussion was affected.

We are going to review the future of the button in October and the possible next steps for the side_comment type.

[dbrace]

I believe that reviewing the future of this temporary button/feature will be important because of course shells that are only re-used on a rotating basis, instead of every semester.

[NancyOlson]

Can a button be developed and deployed at the site level to clear all disallow threaded replies that are checked across the instance? This solution would save us much time, as the consensus amongst the faculty is that no one wants to have their students blocked from replying to other students.

If this isn’t possible, can Instructure extend the timeframe the remove all disallow threaded replies button is available? I would suggest you leave it until at least the end of the fiscal year., so 6/30/25. This would give everyone time to clear their instances without the stress of the short deadline currently imposed upon us all.

[TamasBalogh]

Hi @NancyOlson, in case, if you would like to un-check the Disallow Threaded Replies checkbox for all your discussions in your instance, please contact support and we can do that for you. 

[TrinaAltman]

@TamasBalogh Since the end of October is a mere week away now, I'm just checking in to see how the consideration of keeping the button that allows instructors to update all their discussions at once in place beyond October is going? Have there been any decisions about this yet? The director of our large instructional design team said that inquiries about this issue were greatly diminished after that button appeared and asked if it can be left in place.

[TamasBalogh]

@TrinaAltman  We will communicate the details in a few days, but, yes, we are keeping the button for a while.