[Faraz32123]

Fixes the v3 home issues raised on #39263, so it can serve as the public replacement for GET /api/contentstore/v1/home.

• No write on GET. With ENABLE_CREATOR_GROUP on, loading Studio home (v1, v3 and the legacy page) inserted an unrequested CourseCreator row for non-staff users. The status is now reported as unrequested without a write, and request_course_creator creates the row when the user asks for access. It's created as unrequested and then saved as pending, so the admin notification still fires.
• org removed from the v3 home list schema. That action never loads courses, so the parameter did nothing.
• v3 home is no longer x-internal. v1 home is public and v3 is its replacement. ADR 0038 allows x-internal only for the unversioned course_home BFF, and lists Studio home among the screen names to replace. This removes it from both mounts. The legacy /api/contentstore/v3/home/ was public before feat: apply ADR 0038 (URL structure standardization) across 6 standardized APIs #39078 and stays deprecated.

Course creator requests and the admin. request_course_creator does nothing for staff, with the creator group off, or with course creation disabled, since the table isn't read there. Staff can now add CourseCreator rows in the admin (user picked by id on the add form, read-only after), so admins can still grant access to someone who hasn't requested it.

Testing: course creators, v1/v3 home, spectacular, library and course-creation tests pass locally. New tests fail without the fix. The generated CMS schema has no x-internal operations, and /api/authoring/v3/home/ keeps its SDK tag. docs/cms-openapi.yaml is left to the schema workflow.

Note: #39300 removes the hook block from cms/envs/devstack.py and production.py; whichever lands second drops the comment edit there.

Related: #39263, #39068

🤖 Generated with Claude Code

[taimoor-ahmed-1]

get_or_create turns a request that used to fail into one that writes. Before this change, a user with no row hit DoesNotExist here (a 500, nothing written). The only users without rows were global staff, and everyone on a site with ENABLE_CREATOR_GROUP off or DISABLE_COURSE_CREATION on.

Now any logged-in user who POSTs to /request_course_creator gets a pending row, and the admins get an email. That includes:

• global staff, whom _add_user deliberately never adds;
• sites with the creator group off;
• sites with course creation disabled, where the request can never be granted.

Could this be a no-op in the cases where _get_course_creator_status never reads the table? Something like:

if (
    user.is_staff
    or getattr(settings, 'DISABLE_COURSE_CREATION', False)
    or not getattr(settings, 'ENABLE_CREATOR_GROUP', False)
):
    return

Please also add a test for each of the three cases. test_user_requested_access_without_an_entry would then need @override_settings(ENABLE_CREATOR_GROUP=True) instead of relying on the default.

[Faraz32123]

Good catch, done. user_requested_access is now a no-op for staff, with the creator group off, and with course creation disabled, the cases where _get_course_creator_status never reads the table. Added a test for each, and test_user_requested_access_without_an_entry (and the old test_user_requested_access) now set ENABLE_CREATOR_GROUP=True explicitly.

[taimoor-ahmed-1]

On the side effect in the description: I think this needs a decision before merge rather than a note. CourseCreatorAdmin returns False from has_add_permission and keeps username read-only, so an admin can no longer grant creator access to someone who hasn't requested it. Operators who pre-approve staff or instructors today lose that workflow.

Two options I can see:

• allow adding rows in the admin, with user editable only on the add form;
• keep the behaviour and add an operator-facing release note saying users appear in the admin only after they request access.

I'd lean towards the first, since it keeps the old capability without bringing back the write on GET.

[Faraz32123]

Agreed, went with the first option. Staff can add rows in the admin now; user is picked by id on the add form and stays read-only on the change form. Added a test that adds a user who never requested access as granted through the admin and checks they land in the creator group. I've dropped the side-effect note from the description.