openedx-authz 2.5.0__tar.gz → 3.0.0__tar.gz

{openedx_authz-2.5.0 → openedx_authz-3.0.0}/CHANGELOG.rst

@@ -56,6 +56,13 @@ Changed
 ========
 
 * Static roles may declare an empty permission list when ``role_extensions`` contribute their permissions. Permission lists used by extension edits remain non-empty.
+* Built-in Content Library and course authorization definitions now live in capability applets. The compiled authorization schema, the permission constants, and the role keys remain unchanged.
+
+Removed
+=======
+
+* Removed the role permission lists from ``openedx_authz.constants.roles``, such as ``COURSE_ADMIN_PERMISSIONS`` and ``LIBRARY_ADMIN_PERMISSIONS``. Role constants now identify a role and have an empty ``permissions`` list. Use ``openedx_authz.api.get_permissions_for_single_role`` or the compiled schema to read a role's permissions.
+* Removed ``COURSES_CREATE_COURSE`` (``courses.create_course``) from ``openedx_authz.constants.permissions``. No schema file defined it, so no role could include it.
 
 Fixed
 =====

{openedx_authz-2.5.0 → openedx_authz-3.0.0}/Makefile

@@ -1,5 +1,5 @@
 .PHONY: clean clean_tox compile_translations coverage diff_cover docs dummy_translations \
-        extract_translations fake_translations help pii_check pull_translations paragon_icons \
+        extract_translations fake_translations help pii_check pull_translations paragon_icons compiled_schema \
         paragon_icons_check quality requirements selfcheck test test-all upgrade validate \
         install_transifex_client
 
@@ -43,6 +43,9 @@ paragon_icons: ## regenerate the vendored @openedx/paragon icon-name allow-list
 paragon_icons_check: ## fail if the vendored Paragon icon list is out of date (CI)
 	python scripts/generate_paragon_icons.py --check
 
+compiled_schema: ## regenerate the compiled schema snapshot in docs/references/compiled-schema.yaml
+	python scripts/generate_compiled_schema.py
+
 quality: ## check coding style with pycodestyle and pylint
 	tox -e quality
 

{openedx_authz-2.5.0/src/openedx_authz.egg-info → openedx_authz-3.0.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: openedx-authz
-Version: 2.5.0
+Version: 3.0.0
 Summary: Open edX AuthZ provides the architecture and foundations of the authorization framework.
 Author-email: Open edX Project <oscm@openedx.org>
 License-Expression: AGPL-3.0-or-later

{openedx_authz-2.5.0 → openedx_authz-3.0.0}/docs/concepts/core_roles_and_permissions/course_roles.rst

@@ -36,7 +36,6 @@ The following permissions are associated with the course roles:
 Course Access & Content
 =========================
 - **View course** (``courses.view_course``): Allows users to view the course and access the course outline in read-only mode.
-- **Create course** (``courses.create_course``): Allows users to create a new course in Studio.
 - **Edit course content** (``courses.edit_course_content``): Allows users to edit course content, outline, units, and components.
 - **Publish course content** (``courses.publish_course_content``): Allows users to publish course content.
 
@@ -132,7 +131,6 @@ Roles and Permissions Summary Table
    **Access & Content**
    --------------------------------------------- -------------- -------------- --------------------- --------------
    courses.view_course                           ✅             ✅             ✅                    ✅
-   courses.create_course                         ❌             ❌             ❌                    ❌
    courses.publish_course_content                ✅             ✅             ❌                    ❌
    courses.edit_course_content                   ✅             ✅             ✅                    ❌
    **Files**

{openedx_authz-2.5.0 → openedx_authz-3.0.0}/docs/decisions/0032-applets-for-built-in-authorization-capabilities.rst

@@ -179,6 +179,17 @@ References
 * `ADR 0026`_
 * `ADR 0033`_
 
+Addendum: 2026-11-04
+********************
+
+Each applet keeps the permission and role constants it owns in one ``constants.py`` file. Clients import these constants from ``openedx_authz.authz``, while ``openedx_authz.constants.permissions`` and ``openedx_authz.constants.roles`` remain compatibility exports.
+
+``ActionData``, ``PermissionData``, and ``RoleData`` live in ``openedx_authz.data``. This keeps the dependency direction from ``openedx_authz.api.data`` to ``openedx_authz.authz``, then to the applet constants, and finally to the low-level data classes. It also avoids the circular import that previously required action and permission data classes to move below the public API layer in `commit 2b732c3`_.
+
+YAML remains the source of truth for role composition. Role constants identify roles without listing their permissions, so callers use the public API or the compiled schema to read a role's complete permission list.
+
+This addendum replaces the import paths, dependency direction, and role constant behavior described earlier in this decision. The :doc:`Built-In Python Constants <../references/built-in-constants>` reference documents the public imports.
+
 .. _Issue #484: https://github.com/openedx/openedx-authz/issues/484
 .. _PR #421: https://github.com/openedx/openedx-authz/pull/421
 .. _ADR 0005: 0005-architecture-and-data-modeling.rst
@@ -188,3 +199,4 @@ References
 .. _ADR 0023: 0023-extend-static-roles.rst
 .. _ADR 0026: 0026-rest-api-domain-ownership-boundary.rst
 .. _ADR 0033: 0033-shared-applet-for-course-team-roles.rst
+.. _commit 2b732c3: https://github.com/openedx/openedx-authz/commit/2b732c3560b6392b82a5f835e2bf254eefe70d7c

openedx_authz-3.0.0/docs/how-tos/index.rst

@@ -0,0 +1,7 @@
+How-tos
+#######
+
+.. toctree::
+   :maxdepth: 1
+
+   use-built-in-constants

openedx_authz-3.0.0/docs/how-tos/use-built-in-constants.rst

@@ -0,0 +1,25 @@
+Use Built-In Permission and Role Constants
+##########################################
+
+Import built-in permissions and roles from ``openedx_authz.authz``. Pass their external keys to the convenience functions in ``openedx_authz.api``:
+
+.. code-block:: python
+
+   from openedx_authz.api import assign_role_to_user_in_scope, is_user_allowed
+   from openedx_authz.authz import COURSE_ADMIN, COURSES_VIEW_COURSE
+
+   can_view_course = is_user_allowed(
+       user_external_key="alice",
+       action_external_key=COURSES_VIEW_COURSE.identifier,
+       scope_external_key="course-v1:edX+DemoX+2026",
+   )
+
+   assign_role_to_user_in_scope(
+       user_external_key="alice",
+       role_external_key=COURSE_ADMIN.external_key,
+       scope_external_key="course-v1:edX+DemoX+2026",
+   )
+
+Role constants identify roles without containing their complete permission lists. Use ``get_permissions_for_single_role`` or the compiled schema when a client needs to inspect the permissions assigned to a role.
+
+See :doc:`Built-In Python Constants <../references/built-in-constants>` for the import and compatibility paths.

openedx_authz-3.0.0/docs/references/built-in-constants.rst

@@ -0,0 +1,13 @@
+Built-In Python Constants
+#########################
+
+Applications import built-in permission and role constants from ``openedx_authz.authz``:
+
+.. code-block:: python
+
+   from openedx_authz.authz import COURSE_ADMIN, COURSES_VIEW_COURSE
+
+Each applet keeps the permission and role constants it owns in one ``constants.py`` file. The YAML schema remains the source of truth for role composition, so role constants identify roles without copying their complete permission lists.
+
+``openedx_authz.constants.permissions`` and ``openedx_authz.constants.roles`` remain available as compatibility imports. New code should use ``openedx_authz.authz``.
+

openedx_authz-3.0.0/docs/references/compiled-schema.rst

@@ -0,0 +1,11 @@
+.. _Compiled Authorization Schema:
+
+Compiled Authorization Schema
+#############################
+
+The built-in applets each contribute part of the authorization schema, so a role's complete permission list only exists after the schema pipeline composes the base definitions with the ``role_extensions`` from every applet. This page shows that compiled result for the built-in applets, where each role lists its permissions grouped by the applet that adds them, and each permission and category names the applet that defines it. Installations may add more definitions through their own schema contributions, which this snapshot does not include.
+
+The snapshot is generated from the applet schemas with ``make compiled_schema``, and a test fails when it no longer matches the compiled schema, so any change to an applet schema also shows its effect on the compiled roles in the same diff. You can also :download:`download the snapshot <compiled-schema.yaml>`.
+
+.. literalinclude:: compiled-schema.yaml
+   :language: yaml