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
The ``openedx-learning`` project holds Django apps that represent core learning platform concepts.
10
+
*Formerly known as "Learning Core" or "openedx-learning".*
11
+
12
+
The ``openedx-core`` project holds Django apps which represent core teaching & learning platform concepts.
13
+
14
+
Each app exposes stable, public API of Python functions and Django models. Some apps additionally provides REST APIs. These APIs are suitable for use in ``openedx-platform`` as well as in community-developed Open edX plugins.
11
15
12
16
Motivation
13
17
----------
14
18
15
-
The short term goal of this project is to create a small, extensible core that is easier to reason about and write extensions for than openedx-platform. The longer term goal is to create a more nimble core learning platform, enabling rapid experimentation and drastic changes to the learner experience that are difficult to implement with Open edX today.
19
+
The short term goal of this project is to create a small, extensible core that is easier to reason about and write extensions for than ``openedx-platform``. The longer term goal is to create a more nimble core learning platform, enabling rapid experimentation and drastic changes to the learner experience that are difficult to implement with Open edX today.
16
20
17
-
Replacing openedx-platform is explicitly *not* a goal of this project, as only a small fraction of the concepts in openedx-platform make sense to carry over here. When these core concepts are extracted and the data migrated, openedx-platform will import apps from this repo and make use of their public in-process APIs.
21
+
Replacing ``openedx-platform`` is explicitly *not* a goal of this project, as only a small fraction of the concepts in openedx-platform make sense to carry over here. When these core concepts are extracted and the data migrated, openedx-platform will import apps from this repo and make use of their public in-process APIs.
18
22
19
23
Architecture
20
24
------------
21
25
22
-
Learning Core Package Dependencies
26
+
Open edX Core Package Dependencies
23
27
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
24
28
25
-
Learning Core code should never import from ``openedx-platform``.
29
+
Open edX Core code should never import from ``openedx-platform``.
26
30
27
31
We want to be very strict about dependency management internally as well. Please read the `.importlinter config file <.importlinter>`_ file and the `Python API Conventions ADR <docs/decisions/0016-python-public-api-conventions>`_ for more details.
28
32
@@ -37,7 +41,6 @@ We have a few different identifier types in the schema, and we try to avoid ``_i
37
41
* ``key`` is intended to be a case-sensitive, alphanumeric key, which holds some meaning to library clients. This is usually stable, but can be changed, depending on the business logic of the client. The apps in this repo should make no assumptions about it being stable. It can be used as a suffix. Since ``key`` is a reserved name on certain database systems, the database field is ``_key``.
38
42
* ``num`` is like ``key``, but for use when it's strictly numeric. It can also be used as a suffix.
39
43
40
-
41
44
See Also
42
45
~~~~~~~~
43
46
@@ -49,66 +52,10 @@ The structure of this repo follows [OEP-0049](https://open-edx-proposals.readthe
49
52
Code Overview
50
53
-------------
51
54
52
-
The ``src`` folder contains all our Django applications.
# Using your favorite editor, edit the code to make your change.
90
-
vim …
91
-
92
-
# Run your new tests
93
-
pytest ./path/to/new/tests
94
-
95
-
# Run all the tests and quality checks
96
-
make validate
97
-
98
-
# Commit all your changes
99
-
git commit …
100
-
git push
101
-
102
-
# Open a PR and ask for review.
103
-
104
-
Configuring Visual Studio Code
105
-
------------------------------
106
-
107
-
If you are using VS Code as your editor, you can enable the Testing bar by copying from the example configuration provided in the ``.vscode`` directory::
108
-
109
-
cd .vscode/
110
-
cp launch.json.example launch.json
111
-
cp settings.json.example settings.json
55
+
* ``./src/``: All published code. Packages are importable relative to this directory (e.g., ``import openedx_content``). See ``readme.rst`` in each sub-folder.
56
+
* ``./tests/``: Unit tests (not published).
57
+
* ``./test_utils/``: Internal helpers for unit tests (not published).
58
+
* ``./olx_importer/``: Internal utility for importing data for development (not published).
112
59
113
60
License
114
61
-------
@@ -140,26 +87,26 @@ For more information about these options, see the `Getting Help`_ page.
Copy file name to clipboardExpand all lines: docs/decisions/0001-purpose-of-this-repo.rst
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,7 +12,7 @@ The code that operates on learning content in Open edX primarily resides in edx-
12
12
Decision
13
13
--------
14
14
15
-
The openedx-learning repository was created to provide a new place for certain core learning concepts, data models, and APIs to be implemented. These concepts will be more granular and composable than the courses we have today.
15
+
The openedx-core repository was created to provide a new place for certain core learning concepts, data models, and APIs to be implemented. These concepts will be more granular and composable than the courses we have today.
16
16
17
17
This would have two long term goals:
18
18
@@ -24,7 +24,7 @@ This repo will first be piloted with the use case of unit composition in service
24
24
Consequences
25
25
------------
26
26
27
-
The edx-platform repo will eventually have openedx-learning as a dependency. As functionality is implemented in openedx-learning (e.g. unit composition for content libraries), edx-platform will make use of it.
27
+
The edx-platform repo will eventually have openedx-core as a dependency. As functionality is implemented in openedx-core (e.g. unit composition for content libraries), edx-platform will make use of it.
28
28
29
29
Over time, plugin apps should be able to make use of stable APIs in this repo instead of having to call into edx-platform's Modulestore or Block Transformers. This will serve as a third leg of the new in-process extension mechanisms, where openedx-events provides event notification, openedx-filters provides the ability to intercept and modify the workflow of existing views, and this repo will allow content querying capability.
Copy file name to clipboardExpand all lines: docs/decisions/0003-content-extensibility.rst
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -35,7 +35,7 @@ Learning Core data models will be built with extensibility in mind, with the fol
35
35
#. It will be possible to migrate existing content data over time, as new plugin apps become available.
36
36
#. All content and versions of content will have UUIDs to allow for stable references across services.
37
37
38
-
This layering of related models will add complexity to the data model, but we accept that tradeoff to decouple plugin models from the core application and from other plugins. To make this easier to deal with, openedx-learning should provide abstract models for common use cases, and expose those via a ``models_api.py`` module. This will lower the barrier to entry for developers, and allow us to more easily enforce conventions like setting ``primary_key=True`` with our ``OneToOneField`` relationships.
38
+
This layering of related models will add complexity to the data model, but we accept that tradeoff to decouple plugin models from the core application and from other plugins. To make this easier to deal with, openedx-core should provide abstract models for common use cases, and expose those via a ``models_api.py`` module. This will lower the barrier to entry for developers, and allow us to more easily enforce conventions like setting ``primary_key=True`` with our ``OneToOneField`` relationships.
Copy file name to clipboardExpand all lines: docs/decisions/0015-serving-static-assets.rst
+8-8Lines changed: 8 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,18 +8,18 @@ Both Studio and the LMS need to serve course team authored static assets as part
8
8
9
9
This ADR is the synthesis of various ideas that were discussed across a handful of pull requests and issues. These links are provided for extra context, but they are not required to understand this ADR:
10
10
11
-
* `File uploads + Experimental Media Server #31 <https://github.com/openedx/openedx-learning/pull/31>`_
The underlying data models live in the openedx-learning repo. The most relevant models are:
19
+
The underlying data models live in the openedx-core repo. The most relevant models are:
20
20
21
-
* `Content in contents/models.py <https://github.com/openedx/openedx-learning/blob/main/openedx_learning/core/contents/models.py>`_
22
-
* `Component and ComponentVersion in components/models.py <https://github.com/openedx/openedx-learning/blob/main/openedx_learning/core/components/models.py>`_
21
+
* `Content in contents/models.py <https://github.com/openedx/openedx-core/blob/main/openedx_learning/core/contents/models.py>`_
22
+
* `Component and ComponentVersion in components/models.py <https://github.com/openedx/openedx-core/blob/main/openedx_learning/core/components/models.py>`_
23
23
24
24
Key takeaways about how this data is stored:
25
25
@@ -60,7 +60,7 @@ Security Requirements
60
60
**Assets should enforce more granular permissions at the individual Component level.**
61
61
An important distinction between ContentStore and v2 Content Library assets is that the latter can be directly associated with a Component. As a long term goal, we should be able to make permissions check on per-Component basis. So if a student does not have permission to view a Component for whatever reason (wrong content group, exam hasn't started, etc.), then they should also not have permission to see static assets associated with that component.
62
62
63
-
The further implication of this requirement is that *permissions checking must be extensible*. The openedx-learning repo will implement the details of how to serve an asset, but it will not have the necessary models and logic to determine whether it is allowed to.
63
+
The further implication of this requirement is that *permissions checking must be extensible*. The openedx-core repo will implement the details of how to serve an asset, but it will not have the necessary models and logic to determine whether it is allowed to.
64
64
65
65
**Assets must be served from an entirely different domain than the LMS and Studio instances.**
66
66
To reduce our chance of maliciously uploaded JavaScript compromising LMS and Studio users, user-uploaded assets must live on an entirely different domain from LMS and Studio (i.e. not just another subdomain). So if our LMS is located at ``sandbox.openedx.org``, the files should be accessed at a URL like ``assets.sandbox.openedx.io``.
0 commit comments