There's custom data for users, but is there a way to do something similar for courses? Failing that, is there a hack I can use to tag courses for specific purposes? Perhaps a specific, custom semester? Any out-of-the box ideas?
I don't know of any options for custom data, but naming conventions for courses, terms, and sub accounts provide some decent compartmentalization, which can be effective for some downstream tasks and queries.
We use naming conventions across our integration to provide more detailed information to users and scripts.
Geoscience - S1 -- P03 - LASTNAME, F | 30800001-4 - FAL19
All courses from the SIS include the curriculum code, but when deployed with our content, we can track strings and files in the content to see who is using our content vs their own, and teachers and schools who recently started deploying our content, etc. This helps us with adoption, deployment and outreach questions.
We auto generate and allow employees to create additional work rooms.
WORKROOM -- Employee Name | CCSD
As well as School/Sub Account conference courses (essentially online teacher lounge/resources).
CONF -- School Name | 123
We also place courses into various sub accounts for different purposes
School (each school has these)
Homeroom courses are generated by the SIS for the online school, these land in School > SIS Courses > Student Services sub account. Students and Teacher are managed by SIS, but I typically try not to count them in stats.
Professional Development, which is a separate department has their own sub account and terms, this allows us to separate student and school stats from PDE.
Terms are useful as well
Forever (workrooms, conferences)
Professional Learning (PL 18-19)
K12 18-19 Fall
K12 18-19 Spring
K12 18-19 Summer
Custom data is not available for courses.
How to hack it might depend on how and where you want to use it.
Another approach is to store the custom data on one of your servers and then make an AJAX call to yourself rather than to Canvas. We cache the Canvas course ID locally for all of our courses, so we could look it up based off that and return the custom information.
The mobile apps are harder to work with as little is exposed to the user, unlike the web interface where you can sometimes ascertain information through the URL or ENV variables.
As others have said, there is no custom data store, per se, but we encode a lot of useful information in the sis_course_id and the options integration_id.
Depending on your use case, though, there may be a couple of other options to consider:
First, the test user gets a unique instance per course and functions as a complete user…including the custom_data endpoint. I’m not sure how stable that is over time, since the faculty also have access to masquerade as that user, etc., but it could certainly be used for short-lifespan working data.
Second, the course files are always an option for storage. If the data strings are short and don’t warrant a bunch of operations to open and manipulate files, there’s always the old unix trick of /touch/-ing files to encode useful info directly in the file names and timestamps.