When doing so from calling code, the property is not persisted when
filtering/paging (or any AJAX interaction); instead, it should be
set from within the report instance itself.
- Add SCSS code for border direction utility classes to the Boostrap 5 bridge SCSS file
- Replace all occurrences in the codebase (border-left > border-start, border-right-0 > border-end-0, ...)
- Add SCSS code for text direction utility classes to the Boostrap 5 bridge SCSS file
- Replace all occurrences in the codebase (text-left > text-start, text-sm-right > text-sm-end, ...)
- Add SCSS code for float utility classes to the Boostrap 5 bridge SCSS file
- Replace all occurrences in the codebase (float-left > float-start, float-sm-right > float-sm-end, ...)
Some places where using the wrong icon and now that they have changed,
they need to be updated. For instance:
- i/settings (cog) should be used for settings or configure.
- t/edit (pen) should be used for editing
- Methods add_columns_from_entity(), add_filters_from_entity() and
report_element_search() have been moved from
\core_reportbuilder\datasource class to \core_reportbuilder\base class
in order to be available also for system reports
Make the display of both custom and user profile fields consistent in
column callbacks. The defaults for each should be considered when both
rendering the column data and also when aggregating them (specifically
for numeric columns to ensure calculations are accurate).
When such fields are filtered, and they have user defined default
values then we should also take that into account to ensure that the
same values rendered in columns can always be filtered for.
During this change, I've updated some of the variables to improve
readability and future maintainability of these classes. Annoyingly
there are a non-zero number of changes just for Oracle support.
Where columns were previously of type `TYPE_INTEGER` or `TYPE_FLOAT`
but did not provide numeric data on output, we should change their
type to `TYPE_TEXT` (i.e. the default) to ensure that future work on
numeric aggregation doesn't affect them.
All setUp(), tearDown(), setUpBeforeClass() and tearDownAfterClass()
must, always, call to parent, to ensure that everything is properly
set and cleaned.
While in a lot of situations this is not needed (parents may not
have anything to run), with PHPUnit >= 10 this can become more
important because we are going to move the reset code from current
placement @ runBare() to setUp()/tearDown().
Note that all the changes performed in this commit have been detected
and fixed by moodle-cs (ParentSetUpTearDownSniffTest).
