Previous documentation seemed to incorrectly imply that
the default value for `log_action` was `True` when it is
in fact `False`. This can confuse readers not looking at
the method signature.
Fixes #10427.
In d51ec00ce1, the target was changed from
'[data-field] > .handsontable' to '.handsontable', as the .handsontable
element is no longer a direct descendant of the [data-field] element.
However, this means that we're marking ALL elements with .handsontable
as resize targets, which is not ideal as pretty much all elements
generated by Handsontable have that class.
The original logic would presumably only select the outermost element
with the .handsontable class, which is equal to the element with the
foo-handsontable-container ID (we store this in the containerId
variable).
Frankly, removing this selector outright would also fix the issue. That
said, let's keep this selector in anyway, to match the logic in older
releases.
Regression in 933a730928 introduced in 4.2.
This causes the discrepancy seen between 4.1 vs 4.2 (and later). In 4.2,
this check was broken, which means the event handler never gets added.
The combination of the event handler and the incorrect selector (fixed
in the next commit) would resize all Handsontable elements, resulting in
the bug where the table cannot be interacted with.
The commit b9f8a6b6c0 fixed another cause
of the issue, which was calling `resizeWidth(getWidth())`. The
getWidth() function should only be used to set the Handsontable's
settings, while resizeWidth should be called with '100%' as done within
the event handler.
However, seeing that the event listener is not even attached in 4.2
onwards, dispatching the resize event might not be necessary and
Handsontable might already handle this correctly. That said, let's
avoid making other changes that could potentially cause issues.
With this commit, the bug should reappear in 4.2 and later releases,
making it consistent with 4.1. The bug will be fixed in the next commit.
The searchtests.0002_bookunindexed migration had a dependency on taggit migration 0005, which was added in django-taggit 3.0, but Wagtail only specifies django-taggit >=2.0, so this fails on older django-taggit versions. We don't want to bump this yet (since people could still legitimately be using django-taggit 2.x against Django 3.2 LTS), so fix this migration to work against older django-taggit releases.
Previously, we rely on the fact that the SubMenuItem itself is a dismissible. So, we decide how to show/hide the number badge based on the value for the SubMenuItem's dismissible ID on the server. However, this means that if the user has dismissed the SubMenuItem and we add new dismissible child items within it (e.g. update the ID for the 'What's new in Wagtail version' child item), the number badge will not show up. This commit changes the logic to show/hide the number badge based on whether there are any undismissed items within the SubMenuItem and whether the it has been opened or not.
