Added normalize column to export grade book to remote gradebook #201
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ssue using gradebook summery
amir-qayyum-khan
force-pushed
the
enhancement/aq/two_way_grade_calculating_legacy_gradebook_mitocw#147
branch
from
ad096bc to
a72a8dd
Compare
|
I think you may also need to cherry-pick https://github.com/edx/edx-platform/pull/10213 and https://github.com/edx/edx-platform/pull/10395 as well. These precede @pwilkins's commit. |
|
Unfortunately, I'm having trouble getting this to run. I think you may have a dependency on a post-cypress version of grades.py See the stacktrace at http://dpaste.com/07YXX1W I tried just cherry-picking the commit that contained the missing function, but it's huge and came with a bunch of other dependencies. I'm not sure if it's better to refactor to avoid using |
amir-qayyum-khan
added
Needs Review
CCX
legacy dashboard
and removed
in progress
labels
|
@pdpinch done with testing on cypress. Also I have to cherry pick some comments. |
| @@ -225,4 +225,36 @@ Alessandro Verdura <[email protected]> | |||
| Sven Marnach <[email protected]> | |||
| Richard Moch <[email protected]> | |||
| Albert Liang <[email protected]> | |||
| <<<<<<< HEAD | |||
amir-qayyum-khan
force-pushed
the
enhancement/aq/two_way_grade_calculating_legacy_gradebook_mitocw#147
branch
3 times, most recently
from
d59a3c5 to
4516c49
Compare
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.
…scores). 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 openedx#7168 formed the basis of this. https://openedx.atlassian.net/browse/CSM-17
This will put the actual score and actual max score in scope for the the return_csv function, so actual scores can be dumped. The ultimate goal is to provide this data in the CSV dump that is passed to Stellar via pylmod. This is PR openedx#10395 on edX, and issue 95 on mitocw's edx fork. https://github.com/edx/edx-platform/pull/10395 #95
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.
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.
amir-qayyum-khan
force-pushed
the
enhancement/aq/two_way_grade_calculating_legacy_gradebook_mitocw#147
branch
from
4516c49 to
bbb0c7f
Compare
|
@noisecapella Fixed issues sorry I dont understand:
Can you refer me the fix if there is in cypress or dogwood PRs , because i am cherry-picking commits cc @pdpinch |
|
Can you make a separate PR with the cherry picked commits? The cherry picked commits also need to be cleaned up. |
|
Done @noisecapella |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Background
This PR resolves #147, resolves #187 and resolves #188
What is done in this PR
Studio Updates: None
LMS Updates:
@pdpinch @pwilkins