Consolidate learner logic for picture login

[bjester]

❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.

Overview

Over the course of the Picture Login project, several implementations were created that iterate and apply picture passwords to learner records. Some implementations took more performant routes than others. These can be consolidated to ensure business logic is centralized and consistent in both purpose and performance.

Complexity: Medium
Target branch: develop

Context

The picture login project implemented assignment over multiple learners in:

• an async task that processes learners when the setting is enabled
• a post-sync hook that processes learner records when it detects the setting is enabled
• a sync conflict resolution operation that resolves conflicting picture passwords during deserialization

The project also implemented logic to generate passwords for individual learners in a few places, which would also benefit from a code structure flexible enough to call for those use cases.

The async task iterates over learners and calls assign_picture_password. The assign_picture_password function determines what the available passwords are and assigns one to the user it is invoked with. When this is called repeatedly, this causes repeated queries for determining what passwords are already assigned.

In contrast, the post-sync hook first determines what the available passwords are then loops of the learners and directly sets the password on the records, bypassing assign_picture_password.

The Change

The places where we assign picture passwords should use one utility that determines the available pool of passwords and is able to assign those passwords to one or more learners. The utility should be flexible enough to work with the conflict resolution operation, which is the oddball of the implementations.

The logic for what users are applicable should be consolidated across this utility and the LearnerCounterCache which is used for calculating password exhaustion.

Depending on the approach, one or both of the utilities should consider facility settings to remove repetitive checks on whether the feature is enabled.

How to Get There

• A class or function should exist to iterate over eligible users
  • This should be integrated into or replaces core parts of LearnerCounterCache
• Assignment of picture passwords should be operated through a class, which should:
  • be instantiated with a facility
  • query and cache a pool of available passwords
  • have a method to assign a password from that pool
  • handle exhaustion correctly (see existing implementations)
• The existing locations where we assign picture passwords should refactored use the above utility
• An audit should be made to ensure the business logic is consolidated

Out of Scope

Frontend aspects, as long as the existing APIs provide the frontend the necessary information.

Testing

• Full test coverage of the utilities should be implemented and those should thoroughly verify the business logic
• Redundant test coverage over existing assignment operations should be removed or updated to verify it utilizes the utilities correctly

References

Introduced technical debt by not consolidating logic:

• Resolve picture_password sync collisions via PicturePasswordCollisionOperation #14699
• Assign picture passwords to synced learners missing them on receiver #14650

Individual assignment logic:

• Update CreateSessionSerializer to support learners logging in with a picture password #14550
• Auto-assign picture_password to new learners and clear on role assignment #14551
• Assign picture password when user's last role is deleted #14566

Initial logic:

• Register task to assign picture password #14565
• Implement logic to assign picture password to learners #14469
• Add utility for picture passwords exhaustion #14560