Unable to turn edit on - course previously configured for collections

[djplaner]

Describe the bug

Related to #297. If a course has been previously configured with Collections - but the configuration has been removed/renamed - it appears impossible to get back to editing.

To Reproduce

• (Optional requirement) Turn off the Collections browser extension

• Go to a Canvas course with Collections configured

• Remove the Collections configuration page

• Reload the modules page

• The collections widget appears with the on switch

• Turn it on

  • A new configuration page is created it should be names canvas-collections-configuration-_x_ where x is some number
  • Collections should show a dialog explaining the config page has been created
    Reports of unpublished when it is published

• Hit the "Edit on" button to enter edit mode

• Collections shows "failure" dialog - couldn't find collections configuration

Expected behavior

Edit mode should operate with a fresh/empty configuration

Observed errors

Developer logs are showing a 404 error when trying to get canvas-collections-configuration which is being called from CollectionsDetails.requestCollectionsPage

Suggesting that it's not handling the -x extension being added apparently related to this known Canvas change which apparently had been fixed???

[djplaner]

Exploring source of issue

CollectionsDetails::requestCollectionsPage responsible for getting the configuration page it is implementing

const theUrl = `${this.baseApiUrl}courses/${this.config["courseId"]}/pages/canvas-collections-configuration`

i.e. it's not looking for multiple different versions of page names.

The code to retrieve the editing page lock uses CanvasSetup::getPageTitle which is focused on getting the most recent page matching the page title - not the page slug.

Proposed solution - modify requestCollectionsPage to use getPageTitle

Part of the challenge will be the difference in approach

• getPageTitle accepts a call back
• requestCollectionsPage uses a "then" to decide

requestCollectionsPage

• getPageTitle( "Collections Configuration", courseId, handleCompletedRequest )
• handleCompletedRequest
  • would have to use msg.body to decided whether to parseCollectionsPage or call finishedCallBack with "noCollectionsConfig"

that appears to work after some kludging

Additional related problems

This issue (Canvas page name change resulting in multiple pages with the collections configuration page name) creates some other issues with Collections, including

• "Unpublished" link in main component links to the original slug/page title rather than the one actually being used

  Modified to use the html_url returned from reading, which is saved in configStore[configPageUrl]

• Determining if the configuration page is unpublished or not

• CollectionDetails::saveCollections hard coded to save back to the specific slug --

• CanvasCollections::completeInitialiseConfigPage ahrded coded in HTML -- also

• .... completeImportCollections

[djplaner]

Further fixes

• Save is creating brand new configuration files
• Student view not working

Testing changes

• Start again from scratch
  • save changes isn't creating new configuration pages

[djplaner]

Saving Collections

• CanvasCollections::startSaveCollections
• CollectionsDetails::saveCollections
  • modified to use the page slug - check (using the wrong slug)
  • CollectionsDetails::generateConfigPageContent
• CanvasCollections::completeSaveCollections

Student view not working

• Getting a 404 when trying to retrieve the Collections Configuration page using the API call
  .../api/v1//courses/7085075/pages/?sort=updated_at&order=desc&include[]=body&search_term=Canvas%20Collections%20Configuration

Of course, because this relies on the pages being visible to students.

There is no alternate for students - at least in canvas.

Alternate method - bespoke (allCollections) approach

An alternative might be to use Canvas API to manually try each -X extension, but that could result in 100s of API calls - simply not sustainable.

Stick with straight page name (no slug) and handle it with advice

• Always assume the specific slug/name.
• Explore if there are ways to detect problems and give advice
  • CanvasSetup::getPageName should return an error if it doesn't exist. Perform this at steps when the file should already exist (very early in staff view??)
• Give basic advice in documentation

Todo - adding a check and warning

When teacher needs to create a new configuration page, before showing the "Canvas Collections is now on" dialog do a check to see if the page can be retrieved and/or check the status of this process and display an error that links to the limitations update

[omachado-id]

Thanks for your hard work trying to figure this out, Mr. Jones.

Here is something that occurred to me, though: might this new wrinkle in how Collections is behaving impinge on the ability to copy courses that use Canvas Collections (e.g., from semester to semester/term to term)? I hate to add to your list on this issue, but it would be an additional snag, if course copying was stymied.

I'll leave you to it and wish you success on this.

[djplaner]

Hi @omachado-id,

Always happy to hear new suggestions for Collections. No matter when. Please do send any through.

I had wondered about potential issues with the copy process. However, I've just tested it (once) and it all worked as expected. A key point, however, is that this test was copying into a brand new course. It had never had Collections in it ever. All worked as expected. The normal Collections course copy process worked as expected.

Based on my current assumptions about this issue, I wonder if your tests were a bit like those I've done before. I tended to reuse the same set of sandbox course sites for all my testing. Deleting pages and other content for each new test. Given the Canvas change to pages, this process would no longer work. Canvas would always remember the original Collections configuration page.

David.

[djplaner]

Add a check/warning for the 'wrong' Collections configuration page

Collections must use the configuration page with the slug "canvas-collections-configuration". Just after Collections creates an initial config page, check that it is using this slug. If not, generate an error and point user to the documentation.

CanvasCollections::turnEditingOn will detect noCollectionsConfig and display alert. Modify this to point to documentation/explanation.

CanvasCollections::initialiseCollections appears to do the initial set up. It calls collectionsDetails::saveCOllections to create the page -- does it test if it's created?

Modify saveCollections to check saved page URL for the proper slug

Turning the switch on for the first time needs to error

CollectionsDetails::initaliseCollections doesn't check result of collectionsDetails::initialiseCollectionsConfig before setting noCollections to false

A call to gotCollectionsDetails is perhaps too early?????????

That's because it doesn't save it.

CollectionsDetails.saveCollections needs to check for creating correctly. But it's not even being called

Explore Collections start up

The editingOnHandler is being created for every user, but. not needed for student. Leave for now.

[omachado-id]

Mr Jones,
I appreciate your willingness to consider new features, even as you stamp out this vexing issue (which I have no doubt that you will, given how you're zeroing in on the error inducing settings). I'll collect my thoughts on the feature musings I've had, and post them at a later time.

BTW, I think your observation that you and I may have been relying on the same set of sandboxes for our testing is spot on. There are hefty courses that I've built with Canvas Collections that continue to work just fine, and then there are the ones throwing the errors, and those are sandboxes. For whatever arcane reason, they refuse to work with Collections now. Canvas does seem to be "remembering" their original Collections settings, even though I've deleted all the previous config pages. Could Canvas be doing this through its content undelete features (where one can "undelete" previously deleted content, for up to several days after the deletion? No other idea comes to mind, unfortunately.

[djplaner]

About to release a 1.3 update to Collections.

This version introduces the previously deleted configuration page check.

When Collections is used with a course site where the Collections config page has been deleted, you will need to turn Collections on. Turning it on checks for this problem and displays a dialog warning which links to the online help. Which details a possible solution.

However, due to the limitations of the Canvas "undelete" feature (it only shows recently deleted items) the solution is not 100% usable. Particularly when using "sandbox" course sites

[omachado-id]

Thanks for the hard work, Mr. Jones; I'm now using v. 1.30.

As you pointed out, sometimes the new update may not work, if the reported issue occurs. I tried it on the two courses that know were giving me the problem. Version 1.30 allowed me to use Collections in one of them again. And one did not, due to the limitations of the undelete feature, which you mentioned. On a side note,

On the one that worked, I noticed the Collections turned itself off automatically very quickly again (recall that you had fixed that issue in one of my earliest reports on this forum). Could you double-check what the auto-turnoff time limit is on new version 1.30 (just in case the code reverted to the old short turnoff time limit)?

[omachado-id]

Update on my previous comment earlier today:

Regarding the course, which was refusing to allow me to reactivate Collections even with version 1.30, I think that I've resolved the issue sufficiently that I was able to activate Collections again. However, I'll have to redo any Collections editing I may have lost with this workaround solution (minimal, I believe).

First, my attempts to use "undelete" to find the one correct "old" config page that I could restore, after I'd deleted it months ago, and which would allow me to reactivate Collections, failed. (It was too long ago and there were so many newer deleted config pages within the last few days, that it wasn't possible to go that route.) Next, I considered resetting the course to a blank state, but that seemed like an irrevocable "nuclear option" to me, so I passed on that idea.

What I Did:

A few moments ago, I followed a hunch and did the following:

• Visited the troublesome course's Settings>Import Content area.
• There, I found a Course Copy course import package that I'd brought into this course, and which preceded the oldest Canvas Collections Config page that I'd seen listed in the "Undelete" section for this course.
• I re-imported this Course Copy import package (this was a viable solution since I had not substantively changed the course since then, so changes were minimal)

Results:

• After performing the steps above, the course looked practically the same (given the minimal changes I'd made to the course in all that time).
• I then changed the course name and Canvas course card to remove the reference to the Course Copy imported content's original course name (this always happens when performing a Course Copy of an old course).
• I went into the Modules view and activated Canvas Collections.
• I received the usual dialog telling me that a new Collections config page had been created.
• This allowed me to turn editing on for Collections in the troublesome course. This was the success indicator for me, because it's the correct and expected behavior when turning on Collections for the first time in a course.
• I can now revise the course using Canvas Collections.

While these steps above allowed me to reactivate and begin using Collections in this troublesome course, it may not be a solution for everyone, because:

• Reimporting the old Course Copy package might have eradicated a lot of work that I might've been done in the course since that first import. It worked as a solution because I had not done much work to that course.
• It also worked because the old Course Copy package I used had not exceeded Canvas' retention time limit of 500 days for such imports.

So the net result is that the troublesome course is practically as good as new--at least in this case--and Canvas Collections is once again usable within it.

I hope this helps others.