- move Handsontable render after load & resize width after load
- stops firing a resize event
- adjusts targets to account for the changed markup
- fixes#9107
The PR #9628 missed the cases, where a TemplateResponse is used, which
defers the rendering to a point outside the override_tz() context
manager. This change re-uses the existing handling for the user's
preferred language.
Fixes#10243
Paginated document search results currently always show the number of
documents per page instead of the total number of documents in the
search results.
For example, if a document search
(at http://localhost:8000/admin/documents/)
returns 100 results, and the results are paginated by 20, the results
view always says "There are 20 matches", when it should instead say
"There are 100 matches".
This commit fixes that bug and adds a unit test to cover it.
- Ensure that the change events bubble as this is the default browser behaviour
- By default, changes to hidden values will not fire a `change` event, nor those that are a result of programatic changes to `value, so instead this needs to be added manually so that other code can listen to changes to chosen fields with DOM event listeners.
- https://stackoverflow.com/questions/6533087/jquery-detect-value-change-on-hidden-input-field/8965804#8965804
- Closes#10187
Fixes issue 10200.
Per the Django docs [0], "if you override from_db_value() you also have
to override get_prep_value() to convert Python objects back to query
values."
The ConvertedValueField inherits from IntegerField, which means that it
stores its data as an integer. But its Python value is of type
ConvertedValue, which is actually a string. The representation of that
string is (potentially) a shifted version of the actual field value.
For example, given a ConvertedValue of 320333593, its string
representation is actually "92467817240" due to the logic here [1]
(which, to be honest, I am not sure I understand the rationale behind).
Because ConvertedValueField wasn't implementing get_prep_value, the
parent IntegerField get_prep_value logic was being called, which
tried to cast int() on the field's value, which is actually the string
representation. So instead of the actual integer value being stored in
the database, it's this shifted value that gets stored.
But, with the recent commit to Django [2], that value could potentially
overflow the supported integer field range in the database -- whereas
the actual integer ConvertedValue value should always be okay.
So, this commit implements ConvertedValueField.get_prep_value to ensure
that the real integer value gets stored, not the shifted string value.
[0] https://docs.djangoproject.com/en/dev/howto/custom-model-fields/#converting-python-objects-to-query-values
[1] d5e4ac5590/wagtail/test/customuser/fields.py (L11-L22)
[2] dde2537fbb
Sage Abdullah