The problem
An instructor who launches an activity from the LMS without a matching LAMB creator account reaches a dead end. backend/lamb/lti_router.py:202 renders lti_contact_admin.html, which says:
Unable to Set Up This Activity
You have been identified as an instructor in your LMS, but we could not find an associated LAMB Creator account linked to your identity. […] Please contact the LAMB administrator at your institution and ask them to create an LTI Creator account for you, or to link your existing LAMB account to your LMS identity.
The page is a full stop. There is no action the instructor can take inside the product, the wording is fixed in a template shipped with the code, and the instruction it gives — find your institution's administrator — assumes a support relationship the instructor may not have and the institution may not want to run for every teacher who tries the tool once.
This matters more as the legacy LTI activity path is retired: the unified flow becomes the only way in, so its worst case becomes everyone's worst case.
What it should do instead
1. A self-service route out of the dead end. An instructor without a creator account should be offered a way forward rather than an apology: apply for a code that grants creator status on an organization automatically, without an administrator having to act on each request individually.
Eligibility is the security boundary, and it is narrow. The code may only be redeemed by a user who arrives through a valid LTI launch — signature verified, from a configured consumer — and carries instructor status in that launch. It grants nothing to students, nothing to guests, and nothing to someone who simply has the code.
That constraint is what makes self-service safe. A code redeemable outside an LTI context is a creator-grant anyone can pass around; codes leak, get pasted into course pages and forwarded to students. Binding redemption to a signed launch with an instructor role means possession of the code is not sufficient — the LMS has already asserted, cryptographically, that this person teaches there. The institution's own enrolment becomes the gate, which is the only source of that fact LAMB can trust.
Implementation consequence: redemption must happen inside the launch request, with the verified LTI context in hand — not on a page reached later, where the launch context is gone and only a session remains.
2. The page must be institution-customizable. Whether teachers may self-enrol, what they must agree to, whom to contact, what the process is — that is institutional policy, not product behaviour, and it differs per deployment. A template compiled into the code cannot express it. Administrators need to author this page.
3. Codes are managed at organization-admin level. Creating, enabling and disabling a code belongs to the org admin, so an institution can open enrolment for a term, close it, or run different codes for different faculties without touching another organization.
4. From the activity UI, the instructor should be able to reach the creator interface — and, where they hold authorization in more than one organization, switch between them. Today the LTI activity surface and the creator interface are separate destinations; an instructor who has just configured an activity has no path into the place where assistants are built.
Notes
- The existing signup-key mechanism already routes a user into a specific organization on registration. Whether the creator-grant code should extend that or be a separate concept is a design question, but the two should not end up as parallel half-answers.
- Whatever is built needs a clear boundary: a code grants creator status, not administrator, and its scope is one organization.
- Worth deciding at design time what happens to instructors who arrive after a code is disabled, since that is the common case a term later.
Sequencing
Not now. Raised while building the upgrade baseline harness, to be designed and implemented once the current integration work is finished.
The problem
An instructor who launches an activity from the LMS without a matching LAMB creator account reaches a dead end.
backend/lamb/lti_router.py:202renderslti_contact_admin.html, which says:The page is a full stop. There is no action the instructor can take inside the product, the wording is fixed in a template shipped with the code, and the instruction it gives — find your institution's administrator — assumes a support relationship the instructor may not have and the institution may not want to run for every teacher who tries the tool once.
This matters more as the legacy LTI activity path is retired: the unified flow becomes the only way in, so its worst case becomes everyone's worst case.
What it should do instead
1. A self-service route out of the dead end. An instructor without a creator account should be offered a way forward rather than an apology: apply for a code that grants creator status on an organization automatically, without an administrator having to act on each request individually.
Eligibility is the security boundary, and it is narrow. The code may only be redeemed by a user who arrives through a valid LTI launch — signature verified, from a configured consumer — and carries instructor status in that launch. It grants nothing to students, nothing to guests, and nothing to someone who simply has the code.
That constraint is what makes self-service safe. A code redeemable outside an LTI context is a creator-grant anyone can pass around; codes leak, get pasted into course pages and forwarded to students. Binding redemption to a signed launch with an instructor role means possession of the code is not sufficient — the LMS has already asserted, cryptographically, that this person teaches there. The institution's own enrolment becomes the gate, which is the only source of that fact LAMB can trust.
Implementation consequence: redemption must happen inside the launch request, with the verified LTI context in hand — not on a page reached later, where the launch context is gone and only a session remains.
2. The page must be institution-customizable. Whether teachers may self-enrol, what they must agree to, whom to contact, what the process is — that is institutional policy, not product behaviour, and it differs per deployment. A template compiled into the code cannot express it. Administrators need to author this page.
3. Codes are managed at organization-admin level. Creating, enabling and disabling a code belongs to the org admin, so an institution can open enrolment for a term, close it, or run different codes for different faculties without touching another organization.
4. From the activity UI, the instructor should be able to reach the creator interface — and, where they hold authorization in more than one organization, switch between them. Today the LTI activity surface and the creator interface are separate destinations; an instructor who has just configured an activity has no path into the place where assistants are built.
Notes
Sequencing
Not now. Raised while building the upgrade baseline harness, to be designed and implemented once the current integration work is finished.