Edit lock always being on

[djplaner]

Hi,

Just reporting another problem with which I need help saving myself from myself...

I was putting the final touches on a soon-to-be live course in which I've used Canvas Collections. All has gone perfectly fine with the tool until this afternoon. Then I've had this warning dialog pop up when I tried to do a bit more editing:

Reading up on the Help literature, the suggestion to delete the Canvas Collections-Editing page has not unlocked the tool for me. I've tried several times (each time I click on "Edit On" button, a new version of the Collections-Editing page is generated, but deleting all of them fails to reset the tool.

I am the only person who uses CC here and certainly the only person editing this course, so two people editing the same course is not the problem. I've logged completely off the browser (latest version of Firefox), cleared its cache and relogged in to the course again, to no avail. I've disabled and re-enabled CC in Tampermonkey. I'm on CC version 1.2.2, which according to Tampermonkey, was updated about 30-ish hours ago (my time). Yet I continue to get the pictured error alert.

Can you recommend some next steps that I can take to reset CC to a working state?

Originally posted by @omachado-id in https://github.com/djplaner/canvas-collections/discussions/293

[djplaner]

Similar issue in various versions - suggestive of a broader change.

Debugging

Observations

On instructure site via Mac, I'm getting new versions of editing lock page being created - up to 3 (three attempts). Ask for edit again and another is created.

In code it appears that "GET" edit lock page is failing: both when there initially ad then when it is created.

All the edit lock pages that are created are NOT the straight/raw page. All have -X on the end of the name.

Hypotheses

1. createEditingOnPage is not creating the original page name which is causing checkCreation to fail and give the error

Confirmed Cause

Confirmation from Instructure support staff that this change in behaviour is actually intended. All new pages with the same title will get a -X suffix. Appears connected to September update to Canvas which includes new page functionality

[djplaner]

Exploring - Hypotheses 1

Confirmed, the call is creating -X pages. The url member of the returned object has the fixed named.

The page is being created, but the check is looking for the original edit lock page name (no -X) and this is failing and hence the error

Possible fixes

1.1. edit handler handles -X names as acceptable locks 1.2. edit handler forces proper names

Experimentation - 1.1

Early changes to checkCreation. Not working because URL is slugified and that doesn't work with getUrlFromPage - need to make that work better with pre-sluggified names.

https://canvas.instructure.com/api/v1//courses/7350876/pages/canvascollectionsediting12

[djplaner]

Solution - assuming long term change in behaviour

getPageName should use api to search for all pages with the title (not the name) and appropriately handle 0, 1 or more versions of that file

• 0 - no-one has edit, go ahead
• 1 - someone has edit, check who it is and maybe generate error
• more than 1 - some files haven't been removes, focus on the most recent version and attempt to remove the others

This should help just about everything?

Mapping out editLockHandler

turnEditOn

• starts with getPageName being passed a constant
• Question - as it stands, does it return multiple matching pages - no it is currently getting the sluggified version

Likely changes

• Rename EDITING_ON_PAGE_NAME to EDITING_ON_PAGE_TITLE and focus on using title
• Introduce a getPageTitle method that searches on title
  • figure out if it requires more smarts to hide multiple versions etc.
  • should perhaps do something to ensure that there is only one version - perhaps rely on the most recent one as this is used by staleEditLock and perhaps others
• Modify updateEditingDetails to accept the URL -- actually it doesn't use pageName it's first parameter, could be ignored?
  • figure out if the inclusion oage pageName is a hang over to work with getPageName and may not be required for getPageTitle because it would use the url member in the selected response as page name

[djplaner]

Initial solution implemented and rolled out requires more testing.