You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* adds optional taxonomy_class property+field to Taxonomy
* adds Taxonomy cast() method to use this class
* oel_tagging.api uses Taxonomy.cast() whenever practical
* moves ObjectTag validation back to Taxonomy
* removes ObjectTag.resync() logic -- we don't need it yet.
* removes ObjectTag.object_type field -- we're not using it for anything.
* squashes migrations from previous commits
Copy file name to clipboardExpand all lines: docs/decisions/0007-tagging-app.rst
+2-13Lines changed: 2 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,15 +19,15 @@ Taxonomy
19
19
20
20
The ``openedx_tagging`` module defines ``openedx_tagging.core.models.Taxonomy``, whose data and functionality are self-contained to the ``openedx_tagging`` app. However in Studio, we need to be able to limit access to some Taxonomy by organization, using the same "course creator" access which limits course creation for an organization to a defined set of users.
21
21
22
-
So in edx-platform, we will create the ``openedx.features.content_tagging`` app, to contain the models and logic for linking Organization owners to Taxonomies. There's no need to subclass Taxonomy here; we can enforce access using the ``content_tagging.api``.
22
+
So in edx-platform, we will create the ``openedx.features.content_tagging`` app, to contain the models and logic for linking Organization owners to Taxonomies. Here, we can subclass ``Taxonomy`` as needed, preferably using proxy models. The APIs are responsible for ensuring that any ``Taxonomy`` instances are cast to the appropriate subclass.
23
23
24
24
ObjectTag
25
25
~~~~~~~~~
26
26
27
27
Similarly, the ``openedx_tagging`` module defined ``openedx_tagging.core.models.ObjectTag``, also self-contained to the
28
28
``openedx_tagging`` app.
29
29
30
-
But to tag content in the LMS/Studio, we need to enforce ``object_id`` as a CourseKey or UsageKey type. So to do this, we subclass ``ObjectTag``, and use the ``openedx.features.tagging.registry`` to register the subclass, so that it will be picked up when this tagging API creates or resyncs object tags.
30
+
But to tag content in the LMS/Studio, we need to enforce ``object_id`` as a CourseKey or UsageKey type. So to do this, we subclass ``ObjectTag``, and use this class when creating object tags for the content taxonomies. Once the ``object_id`` is set, it is not editable, and so this key validation need not happen again.
31
31
32
32
Rejected Alternatives
33
33
---------------------
@@ -38,14 +38,3 @@ Embed in edx-platform
38
38
Embedding the logic in edx-platform would provide the content tagging logic specifically required for the MVP.
39
39
40
40
However, we plan to extend tagging to other object types (e.g. People) and contexts (e.g. Marketing), and so a generic, standalone library is preferable in the log run.
41
-
42
-
43
-
Subclass Taxonomy
44
-
~~~~~~~~~~~~~~~~~
45
-
46
-
Another approach considered was to encapsulate the complexity of ObjectTag validation in the Taxonomy class, and so use subclasses of Taxonomy to validate different types of ObjectTags, and use `multi-table inheritance`_ and django polymorphism when pulling the taxonomies from the database.
47
-
48
-
However, because we will have a number of different types of Taxonomies, this proved non-performant.
0 commit comments