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
- Introduce a new controller `MessagesController` to contain the dynamic updating of messages
- Ensure the document updated label does not repeat every time a document is updated
- Using the Stimulus controller with templates approach, icons can easily be pre-loaded for each message type
- Ensure that messages are consistently cleared when new ones are added (this was done ad-hoc across some usage and not others)
- Fixes #9493
The timezone of an admin user was only activated, but never deactivated,
so it leaks into following requests of the current thread.
For example, this affected tests executed AFTER
wagtail.admin.tests.test_account_management (see #9628).
This commit changes the timezone activation to use the override()
context manager from django.utils.timezone, which calls deactivate()
when the context manager is closed.
This is similar to how we use the override() from
django.utils.translation for locale activation in the same decorator.
Either of block_errors or non_block_errors can be omitted; non_block_errors can be passed as a plain list rather than an ErrorList; and the values in block_errors can be ValidationError instances or singleton lists, not just singleton ErrorLists.
Refactor it to allow either of block_errors or non_block_errors to be omitted; allow non_block_errors to be passed as a plain list rather than an ErrorList; and allow the items of block_errors to be ValidationError instances or singleton lists rather than just singleton ErrorLists.
