Uploaded image for project: 'Sakai'
  1. Sakai
  2. SAK-39274

Course enrollment doesn't update when viewing the course roster

    Details

    • Type: Bug
    • Status: CLOSED
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 10.0
    • Fix Version/s: 10.0, 11.0
    • Component/s: Kernel
    • Labels:
    • 10 status:
      Resolved
    • Previous Issue Keys:
      SAK-6261, KNL-1183

      Description

      The main issue here is that the CourseManagementProvider isn't called to update the course participants list when viewing the roster or gradebook student listing or any other tool that lists the student enrollments. This results in the list of students shown in the roster to be out of date until the user goes to SiteInfo (which typically forces it to refresh).

      We discovered that this is a bit more serious that first thought. It actually affects Sakai 2.8 -> 11 (we didn't test anything else). The issue is that accessing site info and viewing participants fixes things up, but otherwise accessing other tools does not result in updated data.

      There is an additional extra bad case (with 2+ sections) where the data is always stale in the authz realm role group table even after accessing the site info. The only workaround in the UI is to remove and readd the groups in a tool like roster. This affects roster 1 and 2.

      We think the existing patches could be made to work with some fixes (use of scs.getInt and removing the older comments that are wrong and also removing use of a map to replace with a cache). That is only a half measure really though.

      -------- OLD desc below
      In 2.2.x the CourseManagementProvider isn't called to update the course participants list when viewing the gradebook's roster or any other tool that lists the student roster. This results in the list of students shown in the roster to be out of date until the user goes to worksite setup and clicks 'Update Roster', which is not an obvious workflow for teachers...

      Jon Gorrono proposed the following solution:

      We have an implementation of a fix which we will be putting into production in a few weeks....

      There are probably a bzillion or maybe a little fewer ways to fix this but I thought that the getAuthzGroup(id) in the AuthzGroupService was the best place because it is the most often 'asked question' from the clients of the API.

      To wit, I added an oddly named method to the API (public void, in case someone wants to call it directly) called updateAuthzGroupsIfNecessary() ... not an unheard of naming scheme, but odd nonetheless.

      I added a call to this method in the above getter in the abstract class ... the base impl of the API

      This method is overridden with a no-op method, also right in BaseAuthzGroupService ... this is to mimic current function of the getter

      Then in DbAuthzGroupService (as 'way down' in the impl as we get),added a call to the db storage object's refreshAuthzGroup(id) method (which is pretty much all the 'Update Participants' button does), and implemented a childish timer mechanism which amounts to a hash of authzgroupIds and Timers

      ... that is to keep some respect for the performance hit.... added default, Spring wired, and sakai.props specification of the timeout...

      So, instead of the 6 or so groupings of calls to getAuthzGroup(id) that occur in practice all banging at the provider with futility, only the first for each group gets through in the allotted time.

      ... all that designed to make sure that a call to the getter for an authzgroup is no more out of sync than the external data source for the providers.

      I can you make a patch if interested.... poof!...there, you're a patch. (sorry, too much coffee)

        Gliffy Diagrams

          Attachments

          1. KNL-1183_2.8.x.patch
            4 kB
          2. KNL-1183.patch
            0.6 kB
          3. refreshAuthzGroup.patch
            8 kB
          4. SAK-6261.patch
            6 kB

            Issue Links

              Activity

                People

                • Assignee:
                  relong Bob Long
                  Reporter:
                  joshua.ryan@asu.edu Joshua Ryan (Inactive)
                • Votes:
                  1 Vote for this issue
                  Watchers:
                  12 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:

                    Git Source Code