-
Notifications
You must be signed in to change notification settings - Fork 5
docs: add ADR on Course Authoring Migration Process Details #213
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
rodmgwgu
wants to merge
1
commit into
openedx:main
Choose a base branch
from
rodmgwgu:rod/adr-phase2-migration
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
160 changes: 160 additions & 0 deletions
160
docs/decisions/0011-course-authoring-migration-process.rst
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,160 @@ | ||
| 0011: AuthZ for Course Authoring - Migration Process Details | ||
| ############################################################# | ||
|
|
||
| Status | ||
| ****** | ||
|
|
||
| **Draft** | ||
|
|
||
| Context | ||
| ******* | ||
|
|
||
| The legacy course authoring roles and permissions system stores role assignments in the | ||
| MySQL ``student_courseaccessrole`` table, represented by the `CourseAccessRole model`_. | ||
|
|
||
| To preserve existing role assignments during the transition to the new openedx-authz system, | ||
| we need a bidirectional data migration process that: | ||
|
|
||
| - Supports course, organization, and instance-level migrations (compatible with the feature | ||
| flag functionality in `ADR 0010`_) | ||
| - Enables rollback capability when the feature flag is disabled | ||
| - Maintains data consistency by removing role assignments from the source system after | ||
| migration | ||
| - Ignores roles that exist in the new system but have no legacy equivalent | ||
|
|
||
| *Note: New system roles without legacy equivalents will be preserved but not enforced until | ||
| the flag is re-enabled.* | ||
|
|
||
|
|
||
| Decision | ||
| ******** | ||
|
|
||
| **Automatic Migration Triggers** | ||
|
|
||
| Migration occurs immediately when the feature flag state changes: | ||
|
|
||
| - **Flag enabled**: Legacy role assignments migrate to new system and are removed from | ||
| legacy system | ||
| - **Flag disabled**: New system role assignments migrate to legacy system and are removed | ||
| from new system | ||
|
|
||
| *Note: Roles without legacy equivalents remain in the new system and are not migrated* | ||
|
|
||
| **Forward Migration Process** (Legacy → openedx-authz) | ||
|
|
||
| - **Parameters**: Optional course or organization filter | ||
| - **Process**: | ||
|
|
||
| 1. Query CourseAccessRole instances matching the specified filter (or all if no filter) | ||
| 2. Create equivalent role assignments in openedx-authz for each CourseAccessRole | ||
| 3. Remove successfully migrated CourseAccessRole instances | ||
| 4. Execute within database transaction for consistency | ||
|
|
||
| **Rollback Migration Process** (openedx-authz → Legacy) | ||
|
|
||
| - **Parameters**: Optional course or organization filter | ||
| - **Process**: | ||
|
|
||
| 1. Query openedx-authz role assignments for specified scope (or all course authoring | ||
| roles) | ||
| 2. Create equivalent CourseAccessRole assignments for roles with legacy equivalents | ||
| 3. Log warnings for roles without legacy equivalents (these remain in openedx-authz) | ||
| 4. Remove successfully migrated openedx-authz assignments | ||
| 5. Execute within database transaction for consistency | ||
|
|
||
| **Role Mapping** | ||
|
|
||
| The following role equivalences define the migration logic: | ||
|
|
||
| +----------------------------------+---------------------------+ | ||
| | Legacy Role (internal name) | New AuthZ Role* | | ||
| +==================================+===========================+ | ||
| | Admin (instructor) | Course Admin | | ||
| +----------------------------------+---------------------------+ | ||
| | Staff (staff) | Course Staff | | ||
| +----------------------------------+---------------------------+ | ||
| | Limited Staff (limited_staff) | Course Limited Staff | | ||
| +----------------------------------+---------------------------+ | ||
| | Course Data Researcher | Course Data Researcher | | ||
| | (data_researcher) | | | ||
| +----------------------------------+---------------------------+ | ||
| | Beta Testers (beta_testers) | Course Beta Tester | | ||
| +----------------------------------+---------------------------+ | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we have a list of new roles that can't be back-migrated that we can add here? |
||
|
|
||
| *New AuthZ role names are subject to change.* | ||
|
|
||
| **Execution Methods** | ||
|
|
||
| **Automatic Execution** | ||
| Django ``pre_save`` signal handlers trigger migration when flag state changes via Django | ||
| Admin or management commands. See `Authoring Waffle Flag Implementation Spike`_ for details. | ||
|
|
||
| **Management Commands** | ||
|
|
||
| *Flag Management (triggers automatic migration):* | ||
|
|
||
| - Enable globally: ``./manage.py cms waffle_switch authz.enable_course_authoring on | ||
| --create`` | ||
| - Disable globally: ``./manage.py cms waffle_switch authz.enable_course_authoring off`` | ||
|
|
||
| *Manual Migration (for debugging):* | ||
|
|
||
| - Forward migration: ``./manage.py cms authz_migrate_course_authoring | ||
| [course_key|org_name]`` | ||
| - Rollback migration: ``./manage.py cms authz_rollback_course_authoring | ||
| [course_key|org_name]`` | ||
|
|
||
|
|
||
| Consequences | ||
| ************ | ||
|
|
||
| - Comprehensive migration documentation will be created for site operators | ||
| - Database transactions ensure data consistency during migration operations | ||
| - Site operators must test migration processes before legacy system deprecation | ||
| - Automatic migration will execute for remaining courses when the feature flag is | ||
| deprecated post-Willow (Specific mechanism for automatic execution will be defined later) | ||
|
|
||
| Rejected Alternatives | ||
| ********************* | ||
|
|
||
| **Instance-level migration only** | ||
| Prevents granular testing on individual courses or organizations, increasing adoption | ||
| risk. | ||
|
|
||
| **Management command-only approach** | ||
| Creates operational overhead and increases risk of inconsistent role assignments during | ||
| transition. | ||
|
|
||
| **Dual-write approach** | ||
| Maintaining role assignments in both systems simultaneously would create data | ||
| synchronization complexity and potential inconsistencies. | ||
|
|
||
| **Copy-only migration** | ||
| Keeping role assignments in both systems would lead to data duplication, confusion about | ||
| source of truth, and potential security risks. | ||
|
|
||
| **No rollback capability** | ||
| Would make migration irreversible and increase adoption risk for site operators. | ||
|
|
||
| References | ||
| ********** | ||
|
|
||
| * `Understand current course authoring roles and permissions logic Spike`_ | ||
| * `Authoring Waffle Flag Implementation Spike`_ | ||
| * `CourseAccessRole model`_ | ||
| * `ADR 0010`_ | ||
|
|
||
|
|
||
| .. _Understand current course authoring roles and permissions logic Spike: | ||
| https://openedx.atlassian.net/wiki/spaces/OEPM/pages/5639602177/Spike+-+RBAC+AuthZ | ||
| +-+Understand+current+course+authoring+roles+and+permissions+logic+and+propose+reusable | ||
| +solution | ||
| .. _CourseAccessRole model: | ||
| https://github.com/openedx/edx-platform/blob/e6deac0cf12226c0b8d744ad17395373cfe0de03 | ||
| /common/djangoapps/student/models/user.py#L1046 | ||
| .. _ADR 0010: | ||
| https://github.com/openedx/openedx-authz/blob/main/docs/decisions/0010-course-authoring | ||
| -flag.rst | ||
| .. _Authoring Waffle Flag Implementation Spike: | ||
| https://openedx.atlassian.net/wiki/spaces/OEPM/pages/5646221313/Spike+-+RBAC+AuthZ+-+ | ||
| Authoring+Waffle+Flag+Implementation | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just pointing out the case where a legacy role doesn’t have an equivalent in the new system. When the flag is enabled, would it become orphaned?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On a closer read, it seems this scenario won’t occur because all legacy roles will exist in the new system, while not all new-system roles exist in the legacy system. Is that correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct, I think all legacy roles should have equivalents on the new system, I think that's easy to achieve.