project: Moodle
summary: Integrate Moodle Workplace Report builder for Moodle 4.0
description: We intend to integrate the Report builder tool| currently exclusive to Moodle Workplace, into Moodle in time for the 4.0 release This epic is effectively comprised of two main tasks, along with dependant sub-tasks, being worked on until integration in order of: System reports () Convert existing reports (, ) Custom reports () Create report sources (, ) Custom report audiences () Custom report schedules () Custom report display on narrow devices () System reports will lay the foundations and set most of the APIs that will be required for subsequent work in Custom reports While implementing System reports we will convert some existing Moodle reports over to them, to use as examples and for demonstration purposes

1.summary: Report builder: Implement functionality for creating system reports
description: Create all APIs, tests, documentation, examples to allow for the creation of system reports For a pictorial overview of a system report please refer to ^reportbuilder_overview.pdf . Columns Column instances define the data captured/displayed within a report column - typically: How the data is retrieved, either a simple SQL table.field fragment or an expression that returns a value They type of data that is being retrieved (int, text, datetime, etc) How that data should be presented in a report (for instance calling userdate() on datetime types) . Filters Report filters can be defined for a report and allow users to narrow down (filter) the data that is displayed in a report They define the data being filtered, either a simple SQL fragment or expression The type of filtering being performed (int, text, datetime, etc) Filter types are extendable, allowing for the addition of many more as suits each use case. We have provided common ones that cover most use cases Note that filters & columns are entirely separate concepts in the report, and each can be used without a matching column/filter (that is to say, we can add a report filter for a user field without needing the column for the same field to be present in the report) . Entities Entities are simply collections of report elements (currently columns and filters). They allow for common elements to be defined once, and then re-used in all reports - developers can choose to use as many or as few of the elements from each entity as required. We have provided user and course entities. They can be joined to reports using standard SQL query syntax All report elements can be defined within the reports themselves - but entities mean its much easier to create re-usable components, and will also help in the long term with custom reports . Actions Report actions can be defined in system reports to provide CTA links for each row in the report. Using :placeholder elements in the action URLs allows them to be specific to the row content - e.g. to always provide a link to the current user/course of the current row . System reports System reports are a consistent way of providing reporting data, with paging, filtering, exporting standardized across them. Once the groundwork is done in defining the report elements in entities, its possible to implement them with minimal code just by adding entities to the report, and defining which elements you want to use from them
2.summary: Report builder: Implement functionality for creating custom reports
description: Create all APIs, tests, documentation, examples to allow for the creation of custom reports API for the definition of custom report sources (_datasources_) in other components and/or third party plugins; User interface for the creation of custom reports by end users
3.summary: Convert configuration changes report to a system report
description: As part of epic, we will convert the configuration changes report to a system report defined using Report builder
4.summary: Convert task logs report to a system report
description: As part of epic, we will convert the task logs report to a system report defined using Report builder including the following: Filters Column callbacks Actions
5.summary: Create "Cohort members" custom report source
description: As part of epic (specifically ), we will create a custom report source (datasource in Report builder terminology) for "Cohort members" - this will become a good example of a many-to-many relationship between entities, and as such is a good candidate for testing report aggregation: Show me all/filtered cohorts with aggregated list of their members Show me all/filtered users with aggregated list of their cohorts . Columns Cohort Context Name ID number Description Visible Component Time created Time modified Source Theme Cohort member Time added User . Filters Cohort Context (default) select filter; all available contexts in use by the report Name (default) text filter ID number text filter Time created date filter Cohort member Time added date filter User . Conditions Same as filters (no defaults)
6.summary: Create "Courses" custom report source
description: We have a courses entity from - it will be straight forward to create a report source based off it (and also the best way to stress test it :)) . Columns Course category Name (default) ID number Description Course Shortname (default) Fullname (default) ID number (default) . Filters Course category Name (default) select filter ID number text filter Course Fullname (default) ID number (default) . Conditions Course category Name (default) Course
7.summary: Reload report filter form via fragment when resetting, avoid page reload
description: When resetting a report filters, the current implementation performs a page reload in order for the form itself to be reset when the page is next rendered This is problematic because it means the filter form is closed on page load, so effectively disappears after the button is pressed, and also presents a problem in the custom report editor when transitioning between screens We can use the Fragment API to just re-render the form after resetting, therefore loading it in its initial/blank state and not requiring a page reload
8.summary: Implement configurable view for reports on narrow viewports
description: As mikelmart ncorrales implemented in WP-2757 for Workplace, however this was finished well after the editor being written for was close to completion This work will allow users to configure, via the report editing interface, how their custom report will be displayed when viewed on a small device (its "Card view") such as a mobile device Configuration of such will be via "Settings > Card view" panel, below "Conditions | Filters | Sorting" configuration: Number of columns \int: how many columns are displayed in the card view\ Show first column title \bool: whether the first column title is displayed in the card view\ Expected outcome: !1.png|thumbnail! When viewing the report on a narrow device: !2.png! A toggle is displayed to allow me to expand/collapse the whole card beyond the initial number of configured columns: !3.png!
9.summary: Implement custom report audiences
description: The goal of this task is to allow report editors to have fine-grained control of which users can access their reports We will implement base audience classes and APIs for interrogating report audiences, in a pluggable manner which will allow any component/subsystem to define their own audience types according to requirements The audience types to be implemented here: All users Specific users Cohort members System role assignments Alongside allowing user to configure audiences for their report, we will also implement a means for them to see a report of all users who match the configured audience for their report(s) When users view their listing of available reports, the audience of each report will be considered to ensure they can only access reports in which they are part of the intended audience As a follow up to this task, report audiences will be used to define delivery schedules ()
10.summary: Implement custom report schedules
description: The goal of this task is to allow report editors to configure the automatic delivery of reports to specific audiences () via email Each schedule contains three parts: Basic information Schedule name is only used in the list of schedules Format: Any file format that has been allowed in Site administration > Plugins > Data formats > Manage data formats Date: Specifies when the report is to be sent for the first time Recurrence: whether the report should be sent once (Does not repeat) or sent frequently (Daily, Weekly, Monthly, Annually, Daily Weekdays) If the report is empty: what to do in this case Send email without the report Send email with an empty report Dont send the email View report data as: Schedule creator Schedule recipient Specific user Recipients: define which users will receive the scheduled report by selecting at least one report audience Custom message: Standard elements of any email message, namely Subject and Message. The cron process will trigger the execution of the report. The report can be sent immediately using the "Send option" from the actions in the list of schedules. When using this option, the user will be asked to confirm the action. The text in the confirmation dialog will depend on the "if report is empty" setting value: If "Do not send email" is selected, we add a warning note. Are you sure you want to queue Schedule for sending? (Note no email will be sent if the report is empty) Otherwise, we just ask for confirmation: Are you sure you want to queue Schedule for sending? (see Rafaels comment| for prototypes)
11.summary: Implement relative date options in the Reportbuilder date filter
description: We currently support absolute dates only Support relative dates (previous two days, etc) to be used as either filters or conditions - provide simple API to switch between modes (absolute/filter vs. relative/condition) and also allow developer to mix and match which operators they want to use for their filter (note: this is already possible in current filter API)
12.summary: Report builder aggregation follow up
description: To consider, and organise into coherant tasks to complete: -"Unique" aggregation, define what it _should_ do- (discussed in team, created ) Sort "Comma separated distinct values" methods, note we can sometimes sort by the aggregated field itself, but not always "Comma separated distinct values" methods on column with multiple fields (currently we just use the first) "Comma separated distinct values" methods with callbacks, see also 3 -Allow columns to set specific callbacks per aggregation type- (no longer needed, edit created later at ) Define whether aggregation type can be sorted in report output Set column GROUP BY SQL fragment Ability to disable aggregations per column (e.g. user.picture is TYPE_INTEGER but makes no sense to perform integer aggregation on it: sum, avg, etc) Behat tests . Wishlist (for later) Determine current support for "Comma separated distinct values" in Oracle & SQL Server (at time of initial implementation, there was none - see ) Allow result of aggregated column to be used as a condition/filter (created )
13.summary: Indicator for when report filters form contains instances that are active
description: It would be nice if when using Report builder, the _Filters_ button indicated the number of active filters (where "active" means the filter is currently being applied to the report/returning some SQL) rafaellechugos mockup/comment follows: !Screenshot from 2021-09-27 13-09-18.png!
14.summary: Display report editor full screen, removing rest of the page elements
description: As described by rafaellechugo below :D Clicking on a report to edit it will open the editor in a page layout such that it is displayed full screen; An _Edit details_ button will be added to open the report details modal; A _Close_ button will be added that will close the editor and return the user to the list of reports
15.summary: Consistent layout/language strings in date-based filters
description: We should improve/fix the following: Reduce spacing between elements (compare to _Is equal to: Success_); Hide the unit value field in the date _Current: Unit_ filter; Make the unit lang strings consistent (currently a mix of _Day(s)_ vs. _days_ at the moment) !72774.png! For both the _Date_ and _Duration_ filter types
16.summary: Custom report option to display unique row values
description: This is in reference to point 1. from : quote"Unique" aggregation, define what it _should_ do quote It was decided within the team that this is not an appropriate column aggregation type because it doesnt perform aggregation on a given column, it performs aggregation on an entire row To implement: A new option per report: "_Show unique rows_" (current wording TBC) If no columns are being aggregated, show unique rows If columns are being aggregated, has no effect Setting as blocked by , because mikelmart ncorrales is adding a generic report settings API there that we can use here
17.summary: UI/UX behaviour Improvements on Report Builder audiences
description: During the review of Jun added these comments on the review that we need to address: Getting a toast notification when I add an audience category but not when I actually save it seems a bit strange. Probably good to add a form change checker to prevent the user from accidentally navigating away from the audiences setup page, especially when they havent saved the changes yet for the audience category that theyre setting up for the report. Also: -Remove animation when expanding/collapsing audience sidebar (so its consistent with the sidebar/conditions bar in editor tab).-
18.summary: Move category elements from course entity to category entity
description: The course_category entity was added as part of - we should move the category column/filter/condition from the course entity to it The _Course > Course category_ column actually shows the complete category path, rather than just the name of the category the course belongs to - move this to the category entity: !Screenshot_2021-11-01 72961.png! The _Course category > Category name_ and _Course > Course category_ conditions (and filters) are identical - remove from the course entity: !Screenshot_2021-11-01 72961(1).png! To improve resilience of future reports, we should also gracefully handle any element models that refer to elements that are no longer defined in the report/entity they are linked to
19.summary: Add appropriate admin breadcrumbs to report view/edit pages
description: Now that we have admin breadcrumbs back () we should make sure the report builder view/edit pages set them appropriately, to make navigation easier when working on reports
20.summary: Report condition to limit returned data to current user
description: As a report creator I want to create reports that are customised to each user So that each user gets personalised reports related to themselves
21.summary: Create JS confirmation dialogue that returns a promise, use in Report builder
description: This proposal came from a chat with dobedobedoh while Andrew was reviewing We can improve the usage of Notification.confirm to use the new method being added here that acts in the same manner but returns a promise, so it can be used as part of the promise chain and avoids deep nesting when defining the saveCallback callback Andrew also recommends the use of string prefetching, to improve UX and reduce number of requests required to get UI element strings
22.summary: Improve definitions of previous/next relative date filters
description: This issue is to collect together thoughts on improving how the _Previous_ and _Next_ relative date condition/filter values are Presented to the user; Implemented See the testing steps on to see how _Previous_ currently works Given today is Friday 17:20 When I select "Previous 2 days" Then I see data for Wednesday 00:00 to Thursday 23:59 (Option A: i.e. current) This may not be what users expect, alternatives B) Wednesday 00:00 to Friday 17:20 C) Wednesday 17:20 to Friday 17:20 - See comments: this was chosen as the solution to implement here, in addition to changing "Previous" to "Last" D) Thursday 00:00 to Friday 17:20 Suggestions also include changing "Previous 2 days" to "Last 2 days" (thanks tsala)
23.summary: Move the report builder "toggle" template to core
description: As requested by sarjona in her review of : quoteI have only one comment: I think the reportbuilder/templates/local/toggle.mustache you have created should be moved to the main library and be added to the component UI library. Im not going to block this issue for that (because were trying to introduce the Component library| little by little, as we did with other features in the past, such as unit tests), but I think it should be done before the 4.0 release. Please, could you create a new issue and prepare a patch for it quote
24.summary: Allow Custom Reports to be disabled by site admin
description: Site admins can only prevent users from accessing to Custom Reports with capabilities but they cant disable the functionality completely. This improvement is to introduce a setting to allow Site Admins to disable Custom Reports feature completely. I suggest the following: Add a new settings page for Report Builder. -Site Administration / Reports / Report Builder / Report Builder settings- Edit: use standard location for feature switches (_General > Advanced features_) Add a new setting: Enable Custom reports (enablecustomreports), default = Yes. This new setting must be supported in config.php, to allow disabling Custom reports via the config file. When "Enable custom reports" is not enabled: Dont allow access to Custom reports and raise an error in "/reportbuilder/index.php": -"Custom reports are not enabled"- Edit: use standard access denied messages from adminlib, existing exception messages Disable scheduled reports

Below is an instruction that describes a task, paired with an input that provides an epic with this format: 
"project": "Name of the project" 
"summary": "Summary of the epic user story" 
"description": "Description of the epic user story". Write a response that appropriately completes the request.### Instruction:
Break this epic user story into smaller tasks to help the developers understand the epic better, you can divide this epic into as much as you want depending on the complexity of the epic.
### Input:
project: Moodle
summary: Integrate Moodle Workplace Report builder for Moodle 4.0
description: We intend to integrate the Report builder tool| currently exclusive to Moodle Workplace, into Moodle in time for the 4.0 release This epic is effectively comprised of two main tasks, along with dependant sub-tasks, being worked on until integration in order of: System reports () Convert existing reports (, ) Custom reports () Create report sources (, ) Custom report audiences () Custom report schedules () Custom report display on narrow devices () System reports will lay the foundations and set most of the APIs that will be required for subsequent work in Custom reports While implementing System reports we will convert some existing Moodle reports over to them, to use as examples and for demonstration purposes

### Response:
1.summary: Report builder: Implement functionality for creating system reports
description: Create all APIs, tests, documentation, examples to allow for the creation of system reports For a pictorial overview of a system report please refer to ^reportbuilder_overview.pdf . Columns Column instances define the data captured/displayed within a report column - typically: How the data is retrieved, either a simple SQL table.field fragment or an expression that returns a value They type of data that is being retrieved (int, text, datetime, etc) How that data should be presented in a report (for instance calling userdate() on datetime types) . Filters Report filters can be defined for a report and allow users to narrow down (filter) the data that is displayed in a report They define the data being filtered, either a simple SQL fragment or expression The type of filtering being performed (int, text, datetime, etc) Filter types are extendable, allowing for the addition of many more as suits each use case. We have provided common ones that cover most use cases Note that filters & columns are entirely separate concepts in the report, and each can be used without a matching column/filter (that is to say, we can add a report filter for a user field without needing the column for the same field to be present in the report) . Entities Entities are simply collections of report elements (currently columns and filters). They allow for common elements to be defined once, and then re-used in all reports - developers can choose to use as many or as few of the elements from each entity as required. We have provided user and course entities. They can be joined to reports using standard SQL query syntax All report elements can be defined within the reports themselves - but entities mean its much easier to create re-usable components, and will also help in the long term with custom reports . Actions Report actions can be defined in system reports to provide CTA links for each row in the report. Using :placeholder elements in the action URLs allows them to be specific to the row content - e.g. to always provide a link to the current user/course of the current row . System reports System reports are a consistent way of providing reporting data, with paging, filtering, exporting standardized across them. Once the groundwork is done in defining the report elements in entities, its possible to implement them with minimal code just by adding entities to the report, and defining which elements you want to use from them
2.summary: Report builder: Implement functionality for creating custom reports
description: Create all APIs, tests, documentation, examples to allow for the creation of custom reports API for the definition of custom report sources (_datasources_) in other components and/or third party plugins; User interface for the creation of custom reports by end users
3.summary: Convert configuration changes report to a system report
description: As part of epic, we will convert the configuration changes report to a system report defined using Report builder
4.summary: Convert task logs report to a system report
description: As part of epic, we will convert the task logs report to a system report defined using Report builder including the following: Filters Column callbacks Actions
5.summary: Create "Cohort members" custom report source
description: As part of epic (specifically ), we will create a custom report source (datasource in Report builder terminology) for "Cohort members" - this will become a good example of a many-to-many relationship between entities, and as such is a good candidate for testing report aggregation: Show me all/filtered cohorts with aggregated list of their members Show me all/filtered users with aggregated list of their cohorts . Columns Cohort Context Name ID number Description Visible Component Time created Time modified Source Theme Cohort member Time added User . Filters Cohort Context (default) select filter; all available contexts in use by the report Name (default) text filter ID number text filter Time created date filter Cohort member Time added date filter User . Conditions Same as filters (no defaults)
6.summary: Create "Courses" custom report source
description: We have a courses entity from - it will be straight forward to create a report source based off it (and also the best way to stress test it :)) . Columns Course category Name (default) ID number Description Course Shortname (default) Fullname (default) ID number (default) . Filters Course category Name (default) select filter ID number text filter Course Fullname (default) ID number (default) . Conditions Course category Name (default) Course
7.summary: Reload report filter form via fragment when resetting, avoid page reload
description: When resetting a report filters, the current implementation performs a page reload in order for the form itself to be reset when the page is next rendered This is problematic because it means the filter form is closed on page load, so effectively disappears after the button is pressed, and also presents a problem in the custom report editor when transitioning between screens We can use the Fragment API to just re-render the form after resetting, therefore loading it in its initial/blank state and not requiring a page reload
8.summary: Implement configurable view for reports on narrow viewports
description: As mikelmart ncorrales implemented in WP-2757 for Workplace, however this was finished well after the editor being written for was close to completion This work will allow users to configure, via the report editing interface, how their custom report will be displayed when viewed on a small device (its "Card view") such as a mobile device Configuration of such will be via "Settings > Card view" panel, below "Conditions | Filters | Sorting" configuration: Number of columns \int: how many columns are displayed in the card view\ Show first column title \bool: whether the first column title is displayed in the card view\ Expected outcome: !1.png|thumbnail! When viewing the report on a narrow device: !2.png! A toggle is displayed to allow me to expand/collapse the whole card beyond the initial number of configured columns: !3.png!
9.summary: Implement custom report audiences
description: The goal of this task is to allow report editors to have fine-grained control of which users can access their reports We will implement base audience classes and APIs for interrogating report audiences, in a pluggable manner which will allow any component/subsystem to define their own audience types according to requirements The audience types to be implemented here: All users Specific users Cohort members System role assignments Alongside allowing user to configure audiences for their report, we will also implement a means for them to see a report of all users who match the configured audience for their report(s) When users view their listing of available reports, the audience of each report will be considered to ensure they can only access reports in which they are part of the intended audience As a follow up to this task, report audiences will be used to define delivery schedules ()
10.summary: Implement custom report schedules
description: The goal of this task is to allow report editors to configure the automatic delivery of reports to specific audiences () via email Each schedule contains three parts: Basic information Schedule name is only used in the list of schedules Format: Any file format that has been allowed in Site administration > Plugins > Data formats > Manage data formats Date: Specifies when the report is to be sent for the first time Recurrence: whether the report should be sent once (Does not repeat) or sent frequently (Daily, Weekly, Monthly, Annually, Daily Weekdays) If the report is empty: what to do in this case Send email without the report Send email with an empty report Dont send the email View report data as: Schedule creator Schedule recipient Specific user Recipients: define which users will receive the scheduled report by selecting at least one report audience Custom message: Standard elements of any email message, namely Subject and Message. The cron process will trigger the execution of the report. The report can be sent immediately using the "Send option" from the actions in the list of schedules. When using this option, the user will be asked to confirm the action. The text in the confirmation dialog will depend on the "if report is empty" setting value: If "Do not send email" is selected, we add a warning note. Are you sure you want to queue Schedule for sending? (Note no email will be sent if the report is empty) Otherwise, we just ask for confirmation: Are you sure you want to queue Schedule for sending? (see Rafaels comment| for prototypes)
11.summary: Implement relative date options in the Reportbuilder date filter
description: We currently support absolute dates only Support relative dates (previous two days, etc) to be used as either filters or conditions - provide simple API to switch between modes (absolute/filter vs. relative/condition) and also allow developer to mix and match which operators they want to use for their filter (note: this is already possible in current filter API)
12.summary: Report builder aggregation follow up
description: To consider, and organise into coherant tasks to complete: -"Unique" aggregation, define what it _should_ do- (discussed in team, created ) Sort "Comma separated distinct values" methods, note we can sometimes sort by the aggregated field itself, but not always "Comma separated distinct values" methods on column with multiple fields (currently we just use the first) "Comma separated distinct values" methods with callbacks, see also 3 -Allow columns to set specific callbacks per aggregation type- (no longer needed, edit created later at ) Define whether aggregation type can be sorted in report output Set column GROUP BY SQL fragment Ability to disable aggregations per column (e.g. user.picture is TYPE_INTEGER but makes no sense to perform integer aggregation on it: sum, avg, etc) Behat tests . Wishlist (for later) Determine current support for "Comma separated distinct values" in Oracle & SQL Server (at time of initial implementation, there was none - see ) Allow result of aggregated column to be used as a condition/filter (created )
13.summary: Indicator for when report filters form contains instances that are active
description: It would be nice if when using Report builder, the _Filters_ button indicated the number of active filters (where "active" means the filter is currently being applied to the report/returning some SQL) rafaellechugos mockup/comment follows: !Screenshot from 2021-09-27 13-09-18.png!
14.summary: Display report editor full screen, removing rest of the page elements
description: As described by rafaellechugo below :D Clicking on a report to edit it will open the editor in a page layout such that it is displayed full screen; An _Edit details_ button will be added to open the report details modal; A _Close_ button will be added that will close the editor and return the user to the list of reports
15.summary: Consistent layout/language strings in date-based filters
description: We should improve/fix the following: Reduce spacing between elements (compare to _Is equal to: Success_); Hide the unit value field in the date _Current: Unit_ filter; Make the unit lang strings consistent (currently a mix of _Day(s)_ vs. _days_ at the moment) !72774.png! For both the _Date_ and _Duration_ filter types
16.summary: Custom report option to display unique row values
description: This is in reference to point 1. from : quote"Unique" aggregation, define what it _should_ do quote It was decided within the team that this is not an appropriate column aggregation type because it doesnt perform aggregation on a given column, it performs aggregation on an entire row To implement: A new option per report: "_Show unique rows_" (current wording TBC) If no columns are being aggregated, show unique rows If columns are being aggregated, has no effect Setting as blocked by , because mikelmart ncorrales is adding a generic report settings API there that we can use here
17.summary: UI/UX behaviour Improvements on Report Builder audiences
description: During the review of Jun added these comments on the review that we need to address: Getting a toast notification when I add an audience category but not when I actually save it seems a bit strange. Probably good to add a form change checker to prevent the user from accidentally navigating away from the audiences setup page, especially when they havent saved the changes yet for the audience category that theyre setting up for the report. Also: -Remove animation when expanding/collapsing audience sidebar (so its consistent with the sidebar/conditions bar in editor tab).-
18.summary: Move category elements from course entity to category entity
description: The course_category entity was added as part of - we should move the category column/filter/condition from the course entity to it The _Course > Course category_ column actually shows the complete category path, rather than just the name of the category the course belongs to - move this to the category entity: !Screenshot_2021-11-01 72961.png! The _Course category > Category name_ and _Course > Course category_ conditions (and filters) are identical - remove from the course entity: !Screenshot_2021-11-01 72961(1).png! To improve resilience of future reports, we should also gracefully handle any element models that refer to elements that are no longer defined in the report/entity they are linked to
19.summary: Add appropriate admin breadcrumbs to report view/edit pages
description: Now that we have admin breadcrumbs back () we should make sure the report builder view/edit pages set them appropriately, to make navigation easier when working on reports
20.summary: Report condition to limit returned data to current user
description: As a report creator I want to create reports that are customised to each user So that each user gets personalised reports related to themselves
21.summary: Create JS confirmation dialogue that returns a promise, use in Report builder
description: This proposal came from a chat with dobedobedoh while Andrew was reviewing We can improve the usage of Notification.confirm to use the new method being added here that acts in the same manner but returns a promise, so it can be used as part of the promise chain and avoids deep nesting when defining the saveCallback callback Andrew also recommends the use of string prefetching, to improve UX and reduce number of requests required to get UI element strings
22.summary: Improve definitions of previous/next relative date filters
description: This issue is to collect together thoughts on improving how the _Previous_ and _Next_ relative date condition/filter values are Presented to the user; Implemented See the testing steps on to see how _Previous_ currently works Given today is Friday 17:20 When I select "Previous 2 days" Then I see data for Wednesday 00:00 to Thursday 23:59 (Option A: i.e. current) This may not be what users expect, alternatives B) Wednesday 00:00 to Friday 17:20 C) Wednesday 17:20 to Friday 17:20 - See comments: this was chosen as the solution to implement here, in addition to changing "Previous" to "Last" D) Thursday 00:00 to Friday 17:20 Suggestions also include changing "Previous 2 days" to "Last 2 days" (thanks tsala)
23.summary: Move the report builder "toggle" template to core
description: As requested by sarjona in her review of : quoteI have only one comment: I think the reportbuilder/templates/local/toggle.mustache you have created should be moved to the main library and be added to the component UI library. Im not going to block this issue for that (because were trying to introduce the Component library| little by little, as we did with other features in the past, such as unit tests), but I think it should be done before the 4.0 release. Please, could you create a new issue and prepare a patch for it quote
24.summary: Allow Custom Reports to be disabled by site admin
description: Site admins can only prevent users from accessing to Custom Reports with capabilities but they cant disable the functionality completely. This improvement is to introduce a setting to allow Site Admins to disable Custom Reports feature completely. I suggest the following: Add a new settings page for Report Builder. -Site Administration / Reports / Report Builder / Report Builder settings- Edit: use standard location for feature switches (_General > Advanced features_) Add a new setting: Enable Custom reports (enablecustomreports), default = Yes. This new setting must be supported in config.php, to allow disabling Custom reports via the config file. When "Enable custom reports" is not enabled: Dont allow access to Custom reports and raise an error in "/reportbuilder/index.php": -"Custom reports are not enabled"- Edit: use standard access denied messages from adminlib, existing exception messages Disable scheduled reports
