- added the abstract and concrete layers of enrollment report provider
- created a celery task.
-added the button in the e-commerce reports section
added the enrollment data backend
added the payment data and start writing the test cases.
updated the code with the feedback suggestions and wrote some test cases.
- all the downloadable reports are now visible in the ecommerce download section.
Pending instructor tasks is also visible in the ecommerce section
added the fields in the user profile information
changed the report store configuration key
added the new http endpoint for financial reports to add more permissions for finance_admin to access.
fix quality issues
added test cases to check csv content data
rebased with master and resolved conflicts
changed the log messages
added the changes as per code clintonb suggestions during code review
updated the test cases for the finance_admin decorator
changes suggested by clinton.
Created and moved Table level filters to the Custom Manager for the CourseEnrollment model.
ecommerce.js file was loaded twice in the instructor_dashboard.js fixed the issues
added the registration code column in the csv
added the full gender in the csv file
Update data sources and add display name translations for the report columns
fix meta name
Make sure the reports section does not appear on non whitelabel courses
pylint fixes
expand out enumerated values
The existing pattern of using `override_settings(MODULESTORE=...)` prevented
us from having more than one layer of subclassing in modulestore tests.
In a structure like:
@override_settings(MODULESTORE=store_a)
class BaseTestCase(ModuleStoreTestCase):
def setUp(self):
# use store
@override_settings(MODULESTORE=store_b)
class ChildTestCase(BaseTestCase):
def setUp(self):
# use store
In this case, the store actions performed in `BaseTestCase` on behalf of
`ChildTestCase` would still use `store_a`, even though the `ChildTestCase`
had specified to use `store_b`. This is because the `override_settings`
decorator would be the innermost wrapper around the `BaseTestCase.setUp` method,
no matter what `ChildTestCase` does.
To remedy this, we move the call to `override_settings` into the
`ModuleStoreTestCase.setUp` method, and use a cleanup to remove the override.
Subclasses can just defined the `MODULESTORE` class attribute to specify which
modulestore to use _for the entire `setUp` chain_.
[PLAT-419]
Move modulestore config for tests to an importable location
Disable pylnt warning for lms imports in common tests
Refactor all testcases that loaded all xml courses
TE-610
TE-489
This commit adds the non-courseware lms/djangoapps and lms/lib.
These keys are now objects with a limited interface, and the particular
internal representation is managed by the data storage layer (the
modulestore).
For the LMS, there should be no outward-facing changes to the system.
The keys are, for now, a change to internal representation only. For
Studio, the new serialized form of the keys is used in urls, to allow
for further migration in the future.
Co-Author: Andy Armstrong <andya@edx.org>
Co-Author: Christina Roberts <christina@edx.org>
Co-Author: David Baumgold <db@edx.org>
Co-Author: Diana Huang <dkh@edx.org>
Co-Author: Don Mitchell <dmitchell@edx.org>
Co-Author: Julia Hansbrough <julia@edx.org>
Co-Author: Nimisha Asthagiri <nasthagiri@edx.org>
Co-Author: Sarina Canelake <sarina@edx.org>
[LMS-2370]
When creating an instructor task total_num_items may change between the
time it and the number of subtasks is calculated and the time the
subtasks are actually queued (all of this cannot happen in one transaction).
In such a case the extra items are distributed among the subtasks of the
last query.
LMS-2090
Instead, we use XModule field default values when creating an empty
XModule. Driven by this use case, we also allow for XModules to be
created in memory without being persisted to the database at all. This
necessitates a change to the Modulestore api, replacing clone_item with
create_draft and save_xmodule.
