1. 12 Jun, 2017 1 commit
  2. 30 May, 2017 1 commit
  3. 25 May, 2017 2 commits
  4. 24 Apr, 2017 1 commit
  5. 18 Apr, 2017 1 commit
  6. 11 Apr, 2017 1 commit
  7. 17 Mar, 2017 2 commits
  8. 30 Nov, 2016 3 commits
  9. 25 Oct, 2016 1 commit
  10. 20 Oct, 2016 1 commit
  11. 07 Oct, 2016 1 commit
  12. 29 Sep, 2016 1 commit
  13. 22 Sep, 2016 1 commit
  14. 11 Sep, 2016 1 commit
  15. 11 Aug, 2016 1 commit
  16. 03 Aug, 2016 2 commits
  17. 22 Jul, 2016 1 commit
  18. 28 Jun, 2016 1 commit
  19. 24 Jun, 2016 1 commit
  20. 04 May, 2016 1 commit
  21. 02 May, 2016 1 commit
  22. 28 Apr, 2016 1 commit
  23. 29 Feb, 2016 1 commit
    • Implement a BaseStudentModuleHistory · 6f9a3911
      This abstract class contains most of the fields (aside from the id and
      foreign key to StudentModule that the subclasses need to manage).  It
      also provides a get_history method that abstracts searching across
      multiple backends.
      
      Move router code to openedx/core
      We need to use it from cms and lms.
      Ensure aws_migrate can be used for migrating both the lms and cms.
      
      Handle queries directed to student_module_history vs default and the
      extra queries generated by Django 1.8 (SAVEPOINTS, etc).
      
      Additionally, flag testing classes as multi_db so that Django will
      flush the non-default database between unit tests.
      
      Further decouple the foreignkey relation between csm and csmhe
      
      When calling StudentModule().delete() Django will try to delete CSMHE
      objects, but naively does so in the database, not by consulting the
      database router.
      
      Instead, we disable django cascading deletes and listen for post_delete
      signals and clean up CSMHE by hand.
      
      Add feature flags for CSMHE
      One to turn it on/off so we can control the deploy.
      The other will control whether or not we read from two database tables
      or one when searching.
      
      Update tests to explicitly use this get_history method rather than
      looking directly into StudentModuleHistory or
      StudentModuleHistoryExtended.
      
      Inform lettuce to avoid the coursewarehistoryextended app
      
      Otherwise it fails when it can't find features/ in that app.
      
      Add Pg support, this is not tested automatically.
      Kevin Falcone committed
  24. 11 Feb, 2016 1 commit
  25. 08 Feb, 2016 1 commit
  26. 27 Aug, 2015 1 commit
    • [LTI Provider] Grade passback for non-leaf blocks. · 9e6c4491
      This change allows graded assignments to be added to a campus LMS
      regardless of the granularity at which the problem sits. Previously
      a grade could only be returned if the usage ID for the problem itself
      was specified in the LTI launch.
      
      The code assumes that courses taking advantage of this functionality
      are arranged in a hiearchy (with sections being parents to verticals,
      and verticals being parents to problems). When a grading event occurs
      it traverses the parent hiearchy to identify any previous graded LTI
      launches for which the new scoring event should generate a grade
      update. It then calculates and sends scores to each of those outcome
      services.
      
      Since grade calculation is an expensive operation, the code optimizes
      the case where a problem has been added only once as a leaf unit. In
      that case it is able to behave as before, just taking the grade from
      the signal without having to calculate grades for the whole course.
      Phil McGachey committed
  27. 03 Aug, 2015 1 commit
  28. 14 Jul, 2015 1 commit
  29. 13 Jul, 2015 1 commit
  30. 09 Jul, 2015 1 commit
    • Optimize grading/progress page to reduce database queries (cache max scores). · 79de77cf
      The progress page did a number of things that make performance terrible for
      courses with large numbers of problems, particularly if those problems are
      customresponse CapaModule problems that need to be executed via codejail.
      
      The grading code takes pains to not instantiate student state and execute the
      problem code. If a student has answered the question, the max score is stored
      in StudentModule. However, if the student hasn't attempted the question yet, we
      have to run the problem code just to call .max_score() on it. This is necessary
      in grade() if the student has answered other problems in the assignment (so we
      can know what to divide by). This is always necessary to know in
      progress_summary() because we list out every problem there. Code execution can
      be especially slow if the problems need to invoke codejail.
      
      To address this, we create a MaxScoresCache that will cache the max raw score
      possible for every problem. We select the cache keys so that it will
      automatically become invalidated when a new version of the course is published.
      
      The fundamental assumption here is that a problem cannot have two different
      max score values for two unscored students. A problem *can* score two students
      differently such that they have different max scores. So Carlos can have 2/3 on
      a problem, while Lyla gets 3/4. But if neither Carlos nor Lyla has ever
      interacted with the problem (i.e. they're just seeing it on their progress
      page), they must both see 0/4 -- it cannot be the case that Carlos sees 0/3 and
      Lyla sees 0/4.
      
      We used to load all student state into two separate FieldDataCache instances,
      after which we do a bunch of individual queries for scored items. Part of this
      split-up was done because of locking problems, but I think we might have gotten
      overzealous with our manual transaction hammer.
      
      In this commit, we consolidate all state access in grade() and progress()
      to use one shared FieldDataCache. We also use a filter so that we only pull
      back StudentModule state for things that might possibly affect the grade --
      items that either have scores or have children.
      
      Because some older XModules do work in their __init__() methods (like Video),
      instantiating them takes time, particularly on large courses. This commit also
      changes the code that fetches the grading_context to filter out children that
      can't possibly affect the grade.
      
      Finally, we introduce a ScoresClient that also tries to fetch score
      information all at once, instead of in separate queries. Technically, we are
      fetching this information redundantly, but that's because the state and score
      interfaces are being teased apart as we move forward. Still, this only
      amounts to one extra SQL query, and has very little impact on performance
      overall.
      
      Much thanks to @adampalay -- his hackathon work in #7168 formed the basis of
      this.
      
      https://openedx.atlassian.net/browse/CSM-17
      David Ormsbee committed
  31. 02 Jul, 2015 1 commit
    • Credit eligibility/provider refactor · e2acf3ab
      * Remove m2m relation between credit course and credit providers.
      * Separate eligibility and provider APIs into different modules.
      * Add API call for retrieving a user's eligibilities.
      * Cache credit course list.
      * Style the dashboard purchase button.
      * Display a link for the credit provider on the dashboard.
      * Add analytics events for clicks on the purchase button.
      * Expose more credit models to Django admin and add search functionality.
      Will Daly committed
  32. 01 Jul, 2015 1 commit
  33. 29 Jun, 2015 2 commits
  34. 07 May, 2015 1 commit