Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-72275

Timeline block "sort by courses" sometimes fetches incorrect or no results for time periods

XMLWordPrintable

    • MOODLE_310_STABLE, MOODLE_311_STABLE, MOODLE_39_STABLE
    • MOODLE_310_STABLE, MOODLE_311_STABLE
    • MDL-72275-master-2
    • Hide

      All logic fixes are covered by existing and/or new behat tests.

      To test the mustache fix:

      1. Log in as a student.
      2. Visit the dashboard (and add the timeline block if it is not visible).
      3. Open the due date filter dropdown and select "Next 6 months".
      4. Refresh the page.
      5. **Once the page has finished loading, re-open the due date filter dropdown.
      6. CONFIRM that the bullet point is next to the "Next 6 months" option and CONFIRM that option is not highlighted blue.
      7. CONFIRM that the "All" option is highlighted blue.
      Show
      All logic fixes are covered by existing and/or new behat tests. To test the mustache fix: Log in as a student. Visit the dashboard (and add the timeline block if it is not visible). Open the due date filter dropdown and select "Next 6 months". Refresh the page. **Once the page has finished loading, re-open the due date filter dropdown. CONFIRM that the bullet point is next to the "Next 6 months" option and CONFIRM that option is not highlighted blue. CONFIRM that the "All" option is highlighted blue.
    • 0
    • HQ Team International Sprint 7, HQ Team International Sprint 8, HQ Team International Sprint 9, HQ Team International Sprin 10

      There are two bugs related to fetching information into the timeline block:

      First bug - first loading block with "all" set

      When first switching to the "sort by courses" view of the timeline block when "All" time is selected (either manually switching the view, or at load time where the block remembers that is the last view),  the block shows no results, even if some actions are required.

      Switching the time period to something else (eg  7days), then back to "All" fixes the issue.

      This appears to be an issue with the time periods being sent to the core_calendar_get_action_events_by_timesort web service. In the buggy scenarios, the timesortfrom and timesortto params sent are the same timestamp, so the web service does not find anything within that zero second timeframe. Switching away and back to "All" gets around this, because it correctly omits the timesortto value.

      The solution here would be to either fix the buggy calls so they don't send a timesortto where relevant, and/or we should update the webservice so that if the timesortto and timesortfrom are equal, we ignore the "to" value.

      We should also create a behat test to confirm the fix is working.

      Second bug

      When switching the ordering (by date or by course), there is an unexpected behaviour where the results shown for each ordering "remember" that ordering's previous timeframe, and revert to it even when the time dropdown has been changed when in the other ordering. For example:

      1. Block loads ordered by date, with the "all" timeframe. All action events are several months in the future.
      2. Switch to order by course, set the timeframe to 7 days (which has no results).
      3. Switch back to order by date, set the timeframe to "6 months" (which has some results).
      4. Again switch to order by course. The timeframe dropdown will show "6 months", but no events are shown, as the data being fetched is for the "7 days" timeframe, not the expected "6 months timeframe.

      The expected behaviour would be that whatever is set in the dropdowns is what is fetched/displayed. The fix for this is to ensure that when switching the order option, the currently selected timeframe is adhered to.

      Bonus bug

      There is an addition in the mustache template which means that if the "6 months" timeframe is set when the block is first loaded (from the previous time it was opened), that value will be highlighted (in addition to the topmost value), which isn't the case for any other values. Although it seems to me like the "current" value should be the one highlighted and not the top one, there is an existing issue raised for that to be fixed across Moodle, so I will not include any other fix related to that in this issue, it can be looked into after the related issue has been resolved (in case it fixes is in this block also). There were also some difficulties with the order by dropdown breaking when I attempted to apply similar changes, so safest to get the other bug fixes landed and revisit this in more detail later.

        1. MDL-72275_master.png
          MDL-72275_master.png
          124 kB
        2. MDL-72275_v3.10.png
          MDL-72275_v3.10.png
          126 kB
        3. MDL-72275_v3.11.png
          MDL-72275_v3.11.png
          128 kB

            michaelh Michael Hawkins
            michaelh Michael Hawkins
            Simey Lameze Simey Lameze
            Adrian Greeve Adrian Greeve
            Angelia Dela Cruz Angelia Dela Cruz
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved:

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 3 days, 6 hours, 37 minutes
                3d 6h 37m

                  Error rendering 'clockify-timesheets-time-tracking-reports:timer-sidebar'. Please contact your Jira administrators.