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

Decouple action events APIs from the logged in user

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.4
    • Fix Version/s: 3.7
    • Component/s: Calendar
    • Labels:

      Description

      Some calendar APIs allow us to pass a list of userids to retrieve events (e.g. calendar_get_legacy_events) but, internally, calendar local APIs make direct use of $USER to calculate priorities, events overrides and event types restrictions, examples of this are:

      1. Core *_is_event_visible implementations in core (both assign and feedback modules) contain uses of $USER and methods calls that internally rely on $USER
      2. get_raw_events_legacy_implementation, totally coupled to $USER and overriding its $courses argument
      3. external functions APIs do not have $user argument
      4. some new calendar local APIs do not have $user either (some of them have, although it may not be used because of other code restrictions)

      Would be nice to fix public interfaces (that is why I'm flagging this as a bug) and also to keep internal vs external consistency by adding $user arguments everywhere. This would be really helpful for analytics as we would have another way to detect activities that required action. Most of the changes these points would require would fix #1 point above. This issue is related to MDL-58768 (#2 point above)

      Calendar api docs page (https://docs.moodle.org/dev/Calendar_API#calendar_get_legacy_events.28.29) includes references to calendar_get_legacy_events, which $users filter does not work properly as $USER is used internally. I am adding a note there about it.

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                1 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Fix Release Date:
                  20/May/19

                  Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 25 minutes
                  25m