Disallow Threaded Replies option in Discussions

TamasBalogh

On August 14th, 2024, we deployed an option in Discussions that allows you to disallow threaded replies. This feature was previously available in the legacy Discussions but was missing in the redesigned version. As a result, some of you may have noticed discrepancies with the new setting checked or not on your existing discussions. I would like to take this opportunity to clarify the situation.

Until now, in the database, we stored all new Discussions with the same property as we did for legacy discussions which were not threaded. Due to this, we could not distinguish whether a discussion had been created in the legacy Discussions with threaded replies disabled or if it had been created in the Discussions where threads had not yet been added. With the introduction of this feature, we needed to check the Disallow Threaded Replies setting for some of the Discussions.

At the time of the change, three scenarios were possible:

If an existing discussion was explicitly set to threaded, the Disallow Threaded Replies setting remained unchecked. This indicates that the discussion was clearly created using the legacy Discussions with threading allowed.
If an existing discussion was not set to threaded, but contained threads, the Disallow Threaded Replies setting also remained unchecked and we converted the underlying . This scenario indicates that the discussion was created using the Discussions and students had already added threaded replies.
If an existing discussion was not explicitly set to threaded and did not contain threads, the Disallow Threaded Replies setting was set to checked, regardless if it was a new discussion or not, since this scenario could mean the discussion was either created in legacy Discussions with threading disabled or in Discussions without any threads.

This means, if you created a discussion recently and intended to allow threaded replies but did not have any threaded responses yet, this change would have set the setting to disallow threaded replies. To allow threaded replies again you can uncheck the Disallow Threaded Replies option when editing your discussion. We apologize if this change created any additional work.

Moving forward, all newly created discussions will respect the Disallow Threaded Replies setting. If the setting is unchecked, the discussion will be threaded, while if the setting is checked, the discussion will be not threaded. Additionally, if a discussion is published and contains at least one threaded reply, the Disallow Threaded Replies setting will become locked and cannot be changed.

Should you have any questions or concerns, please feel free to reach out to your CSM or Support.

kailey

@TamasBalogh Thank you for this post. I've been working with Instructure Support yesterday and most of today to try and get an understanding of this exact issue. We have a case that doesn't seem to fit into any of the three categories you shared. We have a new, unpublished course with imported discussion topics. At least one of the discussions had the 'Disallow threaded replies' setting auto-enabled after the deploy, but the original discussion from the source course included threaded replies. So wouldn't this fall into #1 or #2 where the setting should be disabled? Or are imported discussions treated differently?

For #3, I don't think Instructure deployed that with the right mindset. Instructure is assuming the instructor's preference is to not allow threaded replies. However, discussions created with Discussions Redesign had no option for instructors to choose between threaded or not. So, instructors completed the discussion creation process with the understanding and impression that threaded replies will be applied. There are a number of reasons why there may not be any threaded replies to a discussion yet. For example, we bulk created Fall 2024 Canvas shells with Discussions Redesign enabled. Instructors have been setting up discussion prompts over the summer and those have no replies because the term has not started. Unless an instructor intentionally enabled the new setting, it shouldn't have been automatically enabled on their behalf. Without the instructor's knowledge, it's only going to cause them confusion. Institutions should have been given the choice to not have the setting auto-enabled for their instance if it doesn't work for their users.

bhmills

Major impact in our live courses... It seems this was toggled in all discussions in all of our courses. Students can't post replies to their peers, which is a pretty standard discussion requirement. Hoping our internal ITS team can resolve the issue... Still wondering would you would roll out this update assuming that "disallow threaded replies" should be the default?

Jeff_F

I disagree with the decision to roll out this feature if it was known that doing so would negatively impact live courses. As noted by @bhmills this has had a major impact for us and is still an issue. If enabling this was going to cause problems, then we should be informed ahead of time. We spent quite a bit of time attempting to determine the cause all the while responding to dozens of instructor and student pleas for assistance. When I called to report the problem on 8/13, the support folks wanted to be helpful but it seemed to me that they didn't know about this change and the impact. The solution they offered made little sense as it wouldn't resolve the issue of this setting being enabled and greyed out (add availability dates).

We should be made aware of such changes so we can alert our users ahead of the implementation. We would call for a discussions 'downtime'. This is crucial as even during the summer we have over 1,000 active courses. And we should be provided with a solution ahead of time as well. For example, Canvas performing API calls to list the impacted courses/ discussions as well as API calls to change the setting. This is necessary as this change enabled the setting in active discussions and as students already posted, instructors nor our support team could edit the setting via the GUI. It is also needed due to the scale. Using Canvas Data we detected there being over 5,400 discussions with this setting enabled. Our LMS administrator created a support request last night requesting Canvas to remove the setting from these discussions.

In addition, while the deploy notes state this was to be enabled on 8/14 I believe it was enabled a day early on 8/13 as that is when we started receiving reports of missing reply buttons. This leads to a question of when exactly are system changes made? The system time is tied to the Eastern time zone. Are system updates then made according to that time zone?

https://community.canvaslms.com/t5/Canvas-Releases/Canvas-Deploy-Notes-2024-08-14/ta-p/610769#toc-hI...

dbrace

@TamasBalogh, while I could be wrong and this is my opinion, I believe that if a discussion already existed and did not have any threads, it would have been safer to allow threads while also informing the community at large in this style of blog post so that discussions could have been reviewed for accuracy with how they are configured.

Question: Is this incident (https://status.instructure.com/incidents/3lnwrvxp8nmz) related to this problem? The incident start time was officially Aug 13, 2024 - 21:53 MDT and end time was Aug 14, 2024 - 06:28 MDT.

James

@Jeff_F

I haven't been following this closely, so my thought process might be off here. I'm exploring how this impacts our institution and trying to narrow down where the problem is coming from.

I use July 20 here because that's the date we were ~~switched~~ forced to the new discussions, but I know some people wisely adopted it before the semester began rather than being forced into it in the middle of a semester.

Based on memory and using Canvas for 12 years, prior to July 20, instructors would have had to check a box to make it a threaded discussion if they wanted that. And if that box was checked before July 20, then the discussions are still threaded, which is what the instructor wanted.

If the instructor had not selected threaded discussions prior to July 20, then they did not want (or perhaps didn't know how to set things up) threaded discussions. Since they could not have threaded replies (unless the instructor had changed things mid-discussion), they got set to non-threaded, which is what the instructor wanted.

I'm interpreting that as only discussions created after switching to the Discussions Redesign (July 20 for us) that are potentially affected.

Since we're only a month into that, the number is small. That doesn't jive with what other people are saying in this thread, so this is where someone can tell me my logic is off. But perhaps the difference is just because other people made the switch earlier and the logic is valid.

After my initial freak out, I checked my discussions for the upcoming term and they were okay. I had specifically used threaded in the previous course, but I had copied the content over back in May.

I then checked our Canvas Data 2 (CD2) database to see how big of an impact this would be.

We had ~2500 discussions for the upcoming term, about 500 of those were marked as side_comment (non-threaded). I figured I only had to worry about those created since July 20. That narrowed it down to about 300.

Of course "created_at" doesn't mean that the discussion is new. It means that's when it was created for the course. That could have been a course import from a previous course. The settings would come through correctly from the previous course.

I then looked at the migration_id in CD2 and every single discussion I was worried about had a migration_id. There were no new discussions created during that time.

Whew! I was safe. Nothing to worry about.

But then I had question as I was preparing this.

If a course was copied DURING the time between July 20 and August 13, would it honor the settings of the previous course, even if there was no equivalent setting in the discussions redesign?

Knowing the migration_id itself in CD2 isn't particularly useful. There is a content_migrations table, but it uses an integer ID, which seems to apply to the migration itself, while the migration_id appears unique for each individual item that is migrated.

I took one of those discussions marked as side_comment where students had already replied for this semester and dug in further. I found the same discussion in the offering from Spring 2024 and it was marked as threaded. It's possible that the discussion was copied from Summer 2023 -- the last time it was non-threaded -- but unlikely. To make sure, I used the course audit log API to get where the course was imported from. Note that you can also use the list course migrations endpoint to get the source course. The source course wasn't the one I thought it was. For some reason, the course that it actually came from didn't show up in the query, but once I found the actual ID, I was able to look up the discussion and it was non-threaded in that course. Since it was non-threaded in Summer 2024, the source course used in the import, it should have been non-threaded here -- and it is.

I checked another discussion from a different course that was copied between July 20 and August 13. That discussion was non-threaded in the original and non-threaded in the new course as well. That discussion had also been renamed from "Weekly Chat" (the source course had 10 discussions called "Weekly Chat" and the new one is "Weekly Chat 1"). That makes it hard to be able to match up assignments exactly when comparing, but all 10 Weekly Chats were side_comment.

Two checks and it looks correct so far, but two is a really small number.

I checked a psychology discussion this time, one that didn't already have a reply. This time, it was non-threaded in the new course, but threaded in the original course. However, the instructor edited the discussion on August 6 and it's possible that they changed the settings at that time. Possibly a problem, but there's a reasonable explanation.

I then focused on discussions that had never been edited since their original creation. That narrowed my list down to about 200.

It's going to be impossible for me to automatically check every discussion, but so far it's looking like the transition was smooth for me.

I checked one more. This time, I know the instructor hasn't edited the discussion. It's side_comment in the new discussion and threaded in the original discussion.

That means I can confirm that the transition is not smooth and that courses migrated after switching to the Discussions Redesign but before August 13 do not honor their settings (I haven't checked courses copied after August 13). That makes it more of an impact for institutions that switched early.

I haven't written code to go through and test this (I still have one more class finish getting ready before school starts on Monday).

It seems that I could use CD2 to get a list of all current and future discussions that were side_comment. Then use the API to get which courses the discussions were originally copied from and try to match them up. This could be simple provided the titles were unique and haven't changed (those conditions are not guaranteed). I might have to resort to comparing the text of the discussion itself, but I'm guessing that's not unique either. I could then use the API or CD2 to find out which of those discussions were threaded in the original course. Presumably, since Canvas has those migration ids, they know which assignment it came from and could have programmed that in the first place, but then they would have had to deal with new discussions using their logic.

Does this sound like what you're seeing?

Do you know of a more definitive way to link the new discussion to the original one? The migration_id in the CD2 discussion_topics table is a UUID and cannot be used to look up anything that I know how to access. There is an old_assignment_id but it is the same as assignment_id and not one to a previous course. I know you've done a lot more work CD2 than I have, so perhaps you see something I don't?

Edit: I did discover that the content_migrations table in CD2 has the source_course_id when the migration_type = 'course_copy_importer'. This could save having to look the previous course up using the API.

LayaKafle

Dear friends and Respected Professors, Namaskar!

Nice to see you on the canvas of IVC.

I have been using canvas on chrome browser for two years. i had no any problems, but when I saw this disallowed discussions, I got surprised and could not understand what it is and why it was set like this. I am confused what it aims to do and what I am supposed to do. Thank you so much for the post. Namaskar.

James

@LayaKafle

Here is the short version. It purposefully leaves out some of the details that may confuse the situation.

If you are a student, you don't need to do anything.

If you are an instructor, instructional designer, or other person responsible for creating discussions, then you should check the settings for each of your discussions in all of your current or future classes. See the How do I edit a discussion in a course? lesson from the Canvas Instructor Guide if you need help doing that.

Check the options section where it says "Disallow threaded discussions."

Select (check) that checkbox if you want a flat, non-threaded discussion. This prevents users from responding to other student's replies and forces them to respond to the main discussion topic.
Deselect (uncheck) that checkbox if you want a threaded discussion. This allows students to respond to each others replies.

If you change the setting, be sure to scroll down and hit save.

You may think that you already have it set from a previous semester. The problem is that for a while, Canvas did not keep your settings when you copied the course content over and it may be set to something other than what you want.

nwilson7

@TamasBalogh I completely agree with the thoughts shared by others. #3 seems completely backwards for people that were building courses over the summer as they did not have an option to check the box to allow threaded replies. We were forced to turn on the discussion redesign early because July 20th is in the middle of our summer term and we did not want things switching in live courses. This means that the majority of the courses we built this summer are all wrong as we would never have selected a box to disable threaded replies BUT those courses don't become live until next week so no students have posted yet for #2 to apply. Can Instructure do something to change this?

ADDED LATER: I find it interesting that when Instructure developed the Discussion Redesign they made the assumption that everyone always wanted threaded replies and then when they made this change, they assumed everyone wanted the exact opposite.

-Nick

paulamiranda

To my knowledge and testing, "Disallow Threaded Replies" was pulled from production shortly after Wednesday's deploy. There was a related service incident, and the fix appeared to be to remove this setting from prod altogether. When I read this blog post on Friday afternoon, there was nothing in the message that indicated that it would be bundled with Saturday's release.

Also, shoutout to @kailey (Hi, Kailey!) for highlighting the fact there were no settings for threaded replies at all in Discussions Redesign to begin with, which increases the amount of people/discussions this has impacted, given the 3rd condition in the blog post (“3. If an existing discussion was not explicitly set to threaded...”). Here is a screenshot of discussion settings that was taken prior to this change, confirming that there was no setting allowing for threaded discussions, therefore no ability for instructors or designers to set this option.

As of this morning, there aren't any updates on the August 14 Deploy Notes about this change (or the change to the Sections Added to Course Tray, which ended up being hidden behind an account setting), nor were there updates made to the August 17 Release Notes. We rely on these notes to test upcoming changes and validate them once they are live.

ccarnes

Here is what I don't understand.

We use Blueprint courses. So I understand how the settings should or should not change.

BUT when it is set to Disallow threaded - it is not allowing any replies to any of the initial posts. Is it supposed to work that way? That if it is set to Disallow threaded that it won't allow replies to initial posts?

Thank you. We are hurriedly going through all of the Blueprints and turning of the Disallow so our students make make reply posts as classes have just started. What a mess!

TimVanNorman

I am a little confused on this issue, just like several of the people who have posted here.

It appears that Canvas wants to make all discussions not threaded, by default. This goes contrary to what many faculty use Discussions for, peer-to-peer/student-to-student interactions. As this occurred just when classes have started for our faculty, this means that EVERY discussion needs to be opened and the button de-selected, for all discussions that were created since we turned on Discussion Redesign.

Was that the idea behind this change, force all faculty to individually edit each discussion?

Also, since many faculty would choose to either have threaded or non-threaded discussions. Couldn't a setting have been made to default all Discussions one way, then allow the faculty to only change this, when they wanted to? Having Disable Threaded Discussions turned off, by default, is now causing confusion for all faculty who have never had to worry about it, prior to today.

I hope this makes a little sense.

TrentMcMahon

Echoing the sentiments of others here. Bold of Instructure to assume that being unable to check a button which is not there in Discussions Redesign must mean that users want to disallow threaded discussions, a feature which, quite honestly, I have never once used in my years as an admin and course designer.

We adopted the new UI to align with the start of summer term, meaning we have hundreds of courses to check to make sure that our learners are able to reply properly to their discussion board assignments... awesome.

JennyDruckrey

This has also caused issues for our school. We've been using discussions redesign since we first migrated to Canvas last year. This morning, we had a lot of instructors reaching out wondering why students couldn't reply to discussions and found that this was checked in their fall courses. Our semester is just starting so this caused a large number of issues in discussion boards that didn't have any activity yet. Furthermore, it seems complicated that students cannot reply to anything but the main prompt--not just secondary replies. To me, that defeats the purpose of a discussion board. Our CSM told us we could use the API to change, which resulted in me spending a lot of time getting that sorted instead of dealing with all the other start of semester issues. It'll all work out, but I did want to share my PowerShell API code that I used to update our fall courses. Initial results look promising and if you're comfortable with API's and PowerShell, please feel free to use. This may not be a good fit for your school, so if you unsure of the results, please use your BETA environment to test or work with someone who feels more comfortable with API's. I won't be able to help with additional troubleshooting but hope that this gives someone else a starting point. Someone else may also have a more elegant solution.

---

#Update these values
$term = '<term_id>'
$token = '<token>'
$instanceUrl = 'https://someSchool.instructure.com'

#Get list of classes for a given term
$page = 1;
$oldcount = 0;
$urlclasses = $instanceUrl + '/api/v1/accounts/1/courses/?enrollment_term_id=' +$term +'&access_token=' + $token + '&per_page=100&page=' + $page
$semesterclasses = Invoke-RestMethod $urlclasses -Method get

#For more than 100 courses
while ($semesterclasses.Count -gt $oldcount)
{
$page ++;
$oldcount = $semesterclasses.Count
$urlclasses = $instanceUrl + '/api/v1/accounts/1/courses/?enrollment_term_id=' +$term +'&access_token=' + $token + '&per_page=100&page=' + $page
$semesterclasses += Invoke-RestMethod $urlclasses -Method get
}
$semesterclasses.Count #shows how many classes will be updated

#For every class returned, get a list of discussion topics
foreach ($s in $semesterclasses) {
#Get a list of dicussion topics
$dtopicsurl = $instanceUrl + 'v1/courses/'+ $s.id +'/discussion_topics?access_token=' + $token
$dtopiclist = Invoke-RestMethod $dtopicsurl -Method get

#Update each topic (if they exist)to allow threaded replies
if ($dtopiclist -ne $null) {
foreach ($d in $dtopiclist) {
$updateurl = $instanceUrl + '/api/v1/courses/'+ $s.id +'/discussion_topics/'+$d.id+'/?access_token=' + $token + '&discussion_type=threaded'
$updatetopic = Invoke-RestMethod $updateurl -Method Put
}
}
$s.course_code #tracker to see how script progress

James

@ccarnes

Disallowing threaded discussions prevents replies to replies and only allows replies to the original discussion prompt. This is documented in the How do I create a discussion as an instructor? lesson in the Canvas Instructor Guide. See the "Set additional options" section for the exact wording.

sima_tarokh

@TamasBalogh

We strongly urge you to reconsider making "Disallow threaded replies" the "default" setting for Canvas discussions.

Traditional discussions are naturally designed for back-and-forth conversations and interactions among multiple participants. Setting this as the default disrupts effective communication and collaboration within Canvas.

Since our master courses have already been imported into many active courses, this change is likely to cause significant disruption and confusion among both instructors and students. We've already received reports of issues resulting from this new default setting.

We respectfully request that you maintain the current behavior to avoid imposing this limitation on our users.

pray4

We are triaging along with the rest of you, but I sincerely hope that Canvas learns its lesson and listens to its community going forward. Myself and others pleaded to delay the launch of the redesign until we had final product in beta and test to thoroughly test. Those requests were met with silence here, and so we escalated through our Success Representative. Everyone makes mistakes, but it would be welcome to see some more efforts made to minimize these types of issues going forward.

The cadence of substantive updates needs to be spread out in such a way that Canvas' staff can effective deploy, and clients can effectively test. I've some suspicion that what we're currently dealing with is tied to the recent Canvas sale, but regardless of the whys, I hope Canvas recognizes the goodwill it has built over the years and does not squander it as other EdTech platforms before it.

Now I'm off to find a Lucid app thread so I can share to some additional displeasure, albeit in a polite yet direct tone. 😉

ccarnes

Yesterday, last night and today - all the my colleagues and I have been doing is going into the BluePrint courses and changing the setting to off.

In the older versions of the discussions - the idea was the discussions showed up and you were able to reply whether you said threaded discussion or not. So for many courses, we had not checked the Allow Threaded Discussions.

We switched to the New Discussions - there was no setting to check or not check.

Now the people who are in charge of the BluePrints must go through our 100s of BluePrints and go through every discussion in those BluePrints for any course that has that setting marked - NO INDIVIDUAL INSTRUCTORS cannot change the settings for that. It must be synced out through the BluePrint settings.

So we are spending all our time - going through the BluePrints and changing the discussion forums. After we spent the last week, helping professors figure out how to change dates in their discussion forums.

It used to be when you copied out the BluePrints, the professors could click on the edit of the discussion itself and change the date setting on teach individual assignment. Many of our professors did that this way.

We started getting calls that they could not set the dates that way. So we have to tell everyone - do not go into the discussion when setting dates - go to the calendar or go to the Batch edit for all the dates. It was just a preference - and because some had learned that that is the way they do it they had to relearn it.

Then we had someone who was making an edit NOT in a BluePrint course but the Save button was not working. We could not figure it out - until we figured out it was an issue with the dates. The error with the dates is hidden in the popup. So you don't know their is an error unless you click it open after you have tried to save it.

We have spent last week and these few days - just trying to cope with all the errors, and the new messes that this update has caused. I'm really disappointed because we switched to Canvas to make things easier. I understand the updates try to make things easier yet - but sometimes trying to make things fancier - just makes everything more difficult and causes a great deal of stress for the end users.

Thank you for hearing me out - just frustrated and tired.

TomGibbons

So, this is really a new feature in the Discussions redesign. Here's what it looked like on July 5: https://www.youtube.com/watch?v=bDbXqHbbMB0&t=676s There were no options, and we had to live with it that way for nearly a month, if not more.

The state of the setting when the feature was released is a little annoying--using legacy settings that were no longer even configurable by users to make the decision just seems weird.

Here's my big issue: Needing to toggle a setting to True/Checked to achieve a "not" function. It's not great, and can be confusing and easily misread as "Allow Threaded Replies." Every other setting in the list is phrased as activating a feature, not disabling/disallowing a feature. Usually, you want to go with positive expressions, not negative, when at all possible.

The expression in the opening sentence of this original blog post is a clear demonstration of the difficulty of the current label: "...we deployed an option in Discussions that allows you to disallow threaded replies." It allows us to disallow? That's rough.

Considering that the setting in legacy was "Allow Threaded Replies" and the default was unchecked, and now it's "Disallow Threaded Discussions," which is *also* defaulted to unchecked, users aren't being set up for success.

It would be great if:

The setting were "Allow Threaded Replies"
The default for a newly created discussion were "True" so that replies are threaded by default. (I can't speak for all use cases and users, but I can count on one hand the number of times I've seen an instructor or designer use Focused discussions intentionally over the last 12 years.)

Changing the label to "Allow Threaded Replies" and the default state to "True" right now will add to the initial feature release confusion, but it's going to save users and admins a lot of low-level frustration in the future.

PallaviJalakam

What a hassle right before the courses go live!

All unpublished courses that have the threaded discussion option enabled but lack threaded discussions now need to be updated one by one.

The settings are inconsistent across the courses. Some newly developed courses have the "Disallow threaded replies" option enabled, while others do not. With so many courses about to go live, checking each discussion is a complete mess.

Can we just have the Allow Threaded Replies option back as default?

JeremyDavis144

I'm glad you have admitted to your mistake. We have been scrambling and scratching our heads.

But thanks for posting this and owning up to it. I would just have preferred some kind of warning.

mwolfenstein

A lot of folks have already weighed in on why this whole roll out process was extremely problematic. I just wanted to add some feedback that actually goes to a deeper UX issue.

Instructure decided to have a checkbox for a negative in this interface. There are a few different ways this could have been approached, but selecting the negative is incredibly counterintuitive and frankly goes against basic UI design principles.

First, as others have pointed out, the default both for the redesign and for the vast majority of discussion forum use cases is to have threaded replies.

Second, from an information design standpoint checkboxes should be used to affirm a state, not negate it. At the very least, that checkbox might read, "Limit replies to a single level." which would at least be asserting a state rather than asserting a negative. The far more sensible version which would have avoided this entire cluster of a situation would be for the checkbox to be selected by default and to read "Allow threaded replies."

At this point, I'm worried that if Instructure attempted to implement that UI change it might blow up everyone's discussions again, but if there is any chance of ensuring that existing discussion settings are in no way tampered with I strongly recommend switching over to the default selected checkbox for the enabled state of threaded replies as this would conform with UX and interface design principles.

TomGibbons

@mwolfenstein Same. See my reply from earlier today in this thread. The whole UI approach is opposite to both the legacy approach and to the current list of settings in the redesign--which are all framed as activating a feature, not preventing one.

dbrace

An email I received on 2024-08-20 at 6:59 PM ET, with the following subject: Public Incident Report: 2024.08.13 Threaded Replies disabled in discussions

Summary

Threaded replies disabled in discussions on 8/13/24 to 8/14/24

Overview

The “Disallow Threaded Replies” setting for Canvas Discussions was enabled and locked for some discussions in all regions from 9:35 AM MT 8/13/24 to 6:31 AM MT 8/14/24. This kept users from being able to add threaded replies on discussions. Teachers and admins were also unable to modify the setting on their discussions to allow threaded responses.

Details

At 9:35 AM MT on 8/13/24, we deployed code in production that anticipated a database migration to add required data and columns within the database would occur immediately after deployment. Since the migration was set to occur after the deploy was completed everywhere later on 8/14/24, the new code changed the setting on discussions immediately. The “Disallow threaded replies” settings were enabled and locked for all existing discussions which had not been explicitly set to threaded, and did not yet contain threads.

We first became aware of issues with discussions not allowing threaded replies at 9:46 PM MT on 8/13/24. Additionally, the setting to enable threads could not be modified. Initially, we planned to revert the change that caused the issue, but encountered difficulties due to complexities in the code. Instead, we opted to implement an alternative solution that addressed the pre-migration state and resolved the problem for users. This fix was successfully deployed by 6:31 AM MT on 8/14/24.

Mitigation

Our Engineers implemented a fix to resolve the immediate issue by adding the necessary data that would have been included in a later migration. For future fixes, we will ensure that new code integrates seamlessly with existing code and does not depend on data that hasn't yet been added to Canvas.

Despite the resolution, some discussions remained in a state that prevented threaded replies. This can be corrected using the “Update a topic” API endpoint by setting the discussion_type parameter to “side_comment.” If you need help with this process, please submit a support request, and our team will assist you. For more details about the incident, refer to this blog post https://community.canvaslms.com/t5/The-Product-Blog/Disallow-Threaded-Replies-option-in-Discussions/....

Conclusion

We apologize for the inconvenience. We understand that any service downtime is challenging and are working diligently to prevent such issues in the future.

TraceyDeCicco

I, too, am very curious as to why the decision was made to make this enabled by default. Discussions are usually added as an engagement activity so students will converse with each other, so disabling this by default is puzzling to me. This is the first week of the Fall semester, so this has resulted in a great deal of extra work for the instructors in an already busy week and great confusion among students. I'm not trying to "pile on", but I am just confused as to why it was decided that not allowing replies in discussion boards should be the default.

TamasBalogh

Hello everyone,

First and foremost, I want to sincerely apologize on behalf of the entire team for the inconvenience and disruption caused by this recent change. I understand it led to confusion and frustration, particularly with the additional work required to reset your discussions to be threaded. We also acknowledge that communication prior to this change would have been essential in keeping you informed.

@James provided an excellent summary of the issue and the reasoning behind the change. To clarify, the Discussion Redesign shares the same database as the legacy Discussions, enabling support for both newly created discussions and those from the legacy system. Due to this and the initial absence of an option to mark a discussion as threaded or non-threaded, it was impossible to distinguish whether a discussion was created before or after the transition to Discussions Redesign. As a result, our goal was to minimize the number of discussions affected, ideally limiting the impact to only those created post-switch. It's important to note that we do not assume our users prefer non-threaded discussions. By default, when you create a new discussion, the “Disallow threaded replies” setting is not enabled.

In addition to the change which led to disruptions, there were complications during the deployment and database migration. @dbrace has kindly shared the incident report email that provides further details on the issue.

Moving forward, we are looking into updating the “Disallow threaded Replies” option to “Allow threaded Replies,” with the checkbox enabled by default. If we proceed with this change, we will ensure it is implemented smoothly, with ample communication well in advance to avoid any further disruptions.

I want to assure you that the team has learned a great deal from these events and is committed to preventing similar issues in the future.

cinman

T

rtoon

For those of you familiar with installing and using canvasapi, here's the script I ran for our system to fix a subaccount of courses.

#!/usr/bin/env python3

import os

from canvasapi import Canvas  # used for interfacing with canvas

# Canvas API URL
API_URL = os.environ["IVY_CANVAS_SERVER_NAME"]
# Canvas API key
API_KEY = os.environ["IVY_CANVAS_LMS_TOKEN"]
IOL = 16185
TERM = 3378
# Initialize a new Canvas object
canvas = Canvas(API_URL, API_KEY)
iol_account = canvas.get_account(IOL)  # IvyOnline

courses = iol_account.get_courses(enrollment_term_id=TERM)
for course in courses:
    print(course)
    discussions = course.get_discussion_topics()
    for disc in discussions:
        disc.update(discussion_type="threaded")

MarkNowowiejski

Having tons of issues with the moronic feature (why would anyone want this?!)

It seems to be ranodomly applying through out our blueprint and live courses all week with no rhyme reason

our helpdesk is getting flooded.

TamasBalogh

@ccarnes I'm sorry to hear about additional issues you face. We received both bugs and they are being resolved now and will be deployed soon:
1. Synced discussion's date can't be edited even if the date is not locked
2. Error message is hidden in the Assign To tray

I was not able to reproduce the other issue you mentioned, that if a blueprint discussion is set to disallow threaded replies, users can't reply to the initial post neither. If you are still experiencing that, please contact support so they can document it. Thank you!

Jeff_F

@TamasBalogh

This experience reminded me of an approach where we held off on making system changes in the weeks leading up to the term start. Sure, everyone has different term start dates and we actually have ten. But if major changes were not applied in the 2-3 weeks ahead of the typical Fall and Spring term start dates it may well help a great deal of people. Especially when an unexpected kerfuffle occurs with the deploy of new code that didn't work as envisioned.

I would gamble that 99% of the faculty prefer a stable environment more than they favor pressing forward with new features at an already busy time.

Please pass this suggestion on to management for consideration.

Thanks!! ~ Jeff