When 500 options or more are presented in a group filter, PHP `max_input_vars` limits may prevent the filter from working. This fix passes selected options through as a JSON string to get around the limits.
The bug occurred because if specific fields aren't detected in onRefresh(), the entire Form widget HTML will be returned as the result instead of specific fields. This created a problem because the october.form.js JS is not setup to gracefully handle having the entire root form DOM node completely replaced in the middle of a request being completed. Specifically, this would cause problems when trying to detect empty tabs, and then the problems would cascade from there as there would be an instance of october.form.js attached to the page with broken references to no-longer existing DOM nodes.
This fix solves the immediate issue of `field@context` using the `dependsOn` feature breaking by ensuring that the actual final field name for a given field is used instead of the name used in the configuration of the field. Future work should probably be done to better support an entire form being re-rendered if no fields are detected in onRefresh however.
If a column is defined as searchable, that is not actually searchable (like a partial) and a user filters a list using the searchbox, an Exception is thrown.
Unfortunately, this errorenous search term has already been persisted to the session so on subsequent page loads, the user is presented with an Exception with no way to resolve it themselves.
This PR catches any exception that happens during the search and resets any persisted search terms so that the user can continue working after a page load.
The exception itself will still be thrown.
To reproduce the issue this PR solves:
Set a partial column in any list as searchable: true
Submit a search query
Hit F5
Fixes#3595. Replaces #4736. Credit to @SebastiaanKloos for the initial solution.
Also fixes a longstanding issue where dynamically added fields were not considered when refreshing dependant fields.
This change removes the default postback handler for the datatable
widget (onSave) and instead relies on the closest form's request
handler. While `onSave` was a safe default, it did not take into account
the relation widget using other handlers.
The table widget will use an explicitly specified handler first, then it
will try and use the form's request handler, before using `onSave` as a
fallback, although this should really never occur.
Fixes#4776.
The upgrade to the latest Dropzone.js brought in a new `timeout` configuration variable, which defaults to 30s. This removes the time limit and restores original functionality.
Fixes#4869
This occurs due to a race condition in the rendering where the scrollbars enable and disable over and over because of a slow height calculation. Giving any height number appears to close the loop by never letting the height resolve to 0
Refs #4632
If the DataTable widget is loaded in a Popup, the .focus() call does not
seem to focus the target element correctly, which leads to the problem,
that the updateCellFromFocusedItem method fails to find the focused
item.
This commit passes the target item along since it is already known.
When the value is null [id >= ''] an error is thrown, not being an integer, while [id >= null] will return nil results, curiously. Here we emulate infinity by using a large-ish number instead of null. In future if this becomes a problem we may need to resort to multiple condition definitions as a more verbose solution, for example:
- For when both are set (conditions: id >= ':min' and id <= ':max')
- For when min is set (conditionsMin: id >= ':min')
- For when max is set (conditionsMax: id >= ':max')
When ordering is applied externally, ie. by a relation config, the orderBy call in the List widget simply adds an additional field to the ordering clauses, which prevents lists in these scenarios from being re-ordered correctly. This changes the order clause so that the ordering is reset and only the specified column is ordered when the user sorts a column.
Developers can continue to use the `extendQuery` event to do specialised custom ordering if required.
Fixes#4439.
- Allow minimum or maximum to be unspecified, meaning you want everything up to maximum, or everything above minimum.
- Allow for zero values to work
- Tweak display of infinite values
Fixes#3982.