* Displays escalation email on Special Exams tab of instructor dashboard. MST-274
* updates for requested changes
* updates necessary for unit testing
* Fixes for pylint warning
* fix for quality tests
- Have it load dates from edx-when, not just write to it. This
fixes self-paced courses where edx-when is only place dates are
kept.
- Have it read original date for a homework from edx-when when
resetting a date. This fixes the message it gives the instructor
about whether it was successfully reset.
- Have it recursively set a date, rather than assuming that dates
are only ever set on the subsection layer. This fixes setting
dates on self-paced courses (where dates are set all the way
down) and just in case somebody somewhere edits the course xml
to have a date where it's not expected.
This stage does the following:
- Includes a data migration to copy the values from old to new field.
- Changes business logic to switch to using new field.
- Deletes all code references of the old field.
This reverts commit 84de6bc6de
which reverts commit cebeab4348
which implements the first stage of the `values` column rename in
SiteConfiguration. However, I included a small change:
This time, we set a default value on the new `site_values` column so
that the ORM will happily deserialize the JSONField without throwing a
JSONDecodeError.
This is a follow up from MST-16, which was commited
in 3858036a4e.
Changes:
* Enrich course teams_configuration from a plain Dict
to a custom XBlock field that uses the new TeamsConfig
wrapper class.
* Remove teams_conf property from course, as the previous
change made it redundant.
* Update teams_enabled implementation.
* Remove teams_max_size field from course, which is
no longer semantically correct, as max team size
is now defined on a teamset level.
* Remove teams_topics in order to discourage use of raw
teams config dict.
* Add convenience properties teamsets and teamsets_by_id
to course.
* Allow periods and spaces in teamset IDs to avoid breaking
existing course teams.
Some parts of the code still use the old raw config data
(identifiable by searching "cleaned_data_old_format"),
which we expect to be slowly factored away as we build
new teams features. MST-40 has been created to remove any
remaining references if necessary.
MST-18
* fix: bokchoy test
* fix: remove pdb break
So making this code change took a few hours. But then deciding that it
was the right one of the many options available took the next 3 days.
When changing to the new rounding function, we had a test that started
failing. It appears as if our new rounding function is not the same in
some way as the one built into python 2.
```
>>> round(.0045*100 + .05)/100
0.0
>>> round_away_from_zero(.0045*100 + .05)/100
0.01
```
Doing the math by hand we see that the new function is actually correct
but the old one is clearly rounding incorrectly in this case. Looking
closer at this I discovered that it was due to a floating point issue
where .0045*100 is represented as 0.44999999999999996 so when we add
0.05 to this number we get 0.49999999999999994. This is all because of
the limitations of floating point arithmetic.
See https://docs.python.org/3/tutorial/floatingpoint.html#tut-fp-issues
for more on that.
Because python does its rounding at the bit level in C code. It treats
the .4999... as below the .5 cutoff and rounds down. Whereas our code
does more simple arithmetic which causes the number to correct itself
before we round and so correctly rounds up to 0.01
The result of this change is that previously, the rounding threshold used to
be that any number > .0045 would ronud to 0.01 and now any number that
is >= .0045 rounds to 0.01
Note that if we only care about the two most significant digits of
number between 0 and 1, this error only manifests itself in such a way
that other than the case of going from 0.00 to 0.01 eg. from 0% to 1%
none of the other cases where we would now round up cause the 2 most
significant digits to change. Given this level of impact, we're fine
with this change.
In our tests we see this for one case, where an incomplete turns into an
F in a test. I'm updating the test here to be more correct.
As we were looking at it we speculated as to why we were adding the .05
to the number. Could it be to counteract this floating point issue? It
turns out not.
Looking at this commit(a1286b1c7d) we see that it
looks like this was intended to always round up to the nearest
percentage point. However, there's a typo here. If you wanted to
ensure that we always rounded up to the nearest percentage point you
would have the math be `round(final_grade_percent*100 + 0.5)/ 100` or a
simpler way to do this would be
`math.ceil(final_grade_percent*100)/100`. However, that is not what
happened and 7 years later, there have been a lot of people graded with
the wrong rounding where essentialy anyone with a grade of 89.45 gets a
90 when the intended impact was supposed to be that anyone with a grade
above an 89.0 would get a grade of 90.
Changing it now requires a lot of conversation and wolud have a large
impact on existing learners. So we are not going to change it as a part
of the python 2 -> python 3 upgrade. I have created
https://openedx.atlassian.net/browse/TNL-6972 to capture this issue if
we want to address it in the future.
changes made to pass tests with python 2 and other minor changes
Updated the tests to fix the string/bytes input
changes made to pass tests with python 2 and other minor changes
made some changes as suggested
made changes as suggested
changes made as suggested
