Applying a filter on a DateTime column in an aggregation was causing
an uncaught error to occur and prevent the page being rendered at
all. Fortunately, this turned out to be a very simple issue to resolve.
Schemas per se are type agnostic, isLookup property is removed. Data is stored and accessed differently based on how it is entered and retrieved.
The crucial change is introduction of the composite key of pid and rid. Previous page data utilizes rid = 0 to differentiate itself. Other types, notably lookup, have autoincrementing rid.
Database migration is not implemented yet.
The datetime picker expects and produces dates / time pairs separated by
the "T" character, not a space. Further, it does not handle seconds at
all.
Therefore, we have to provide the timestamp in the input field separated
by a "T" and for consistency drop seconds altogether. Hence, it
becomes necessary to replace the "T" by a space again before providing it to jQuery
date picker fallback.
Further, we have to actually parse the "T" when validating the
timestamps we receive from the user.
Multiple inputs within a single label in invalid HTML. This bug can not
only occur in multi-fields but also in plugin-provided single fields
which may contain multiple input-fields which are then only combined by
javascript.
Thus, we provide an id which every type can assign to the edit-field
best suited. For multi-types this is usually the new-input-template.
Fixes#292
This fixes a bug, that caused the $STRUCT.table.field$ filter syntax to
be broken for lookup fields. Struct was comparing the row-id of the
argument-column to the raw value of the referenced column at the
filtered lookup.
There were multiple options to fix this bug:
1. Add a new function to the AbstractBaseType() that return raw value by
default (this is the approach implemented by this commit)
2. Add a function to the lookup type only and use introspection to call
it if it exists.
3. Do not compare the values in the referenced columns, but compare only
the row-ids
The problem with approach 3: It is not possible to compare such
lookup-column to any other column except lookups and this is not what we
want.
Approaches 1 and 2 have different trade-offs on where additional
code/complexity is created. I decided for approach 1 because it is the
cleaner overall approach and we might want to use this functionality for future
types as well.
SPR-875
Empty fields where pre and postfixed just as any other field. When
searching for a string that matched a pre/postfix all empty fields where
returned because the pre/postfix matched.
