Re-evaluate interaction between admin mode feature and sidekiq jobs
Context
With the introduction of the admin mode feature (feature flag protected), the "administrator" status of a user is checked with declarative policies.
The current implementation checks all active sessions of a user to determine if a user has enabled admin mode in one of them. Meaning that if a user has enabled admin mode in one session, it will be enabled on all the others.
Originally one of the reasons for this was to mimic the smartcard authentication implementation and support sidekiq jobs that happen in the background, potentially requiring administrator access.
Problem
Admin mode has a timeout (6 hours) or can be manually disabled. Since we have no guarantees about the execution timeframe of sidekiq jobs, this could have unintended effects. Jobs would fail and the action triggered by the admin would not complete.
In practice this might be less of a problem, since most sidekiq jobs are quite fast, so they should run within a few minutes after triggering them at most. Admin mode makes sense for the UI but we cannot really guarantee any deadline for jobs.
In addition, we also need to deal with scheduled jobs.
Considered Solutions
- (Being developed in !21792 (merged)) Inject admin mode as state that is persisted as part of the job fields via sidekiq middleware. When the job is created the admin mode status is checked and injected into the job, this way we have no issues about the variable duration of the job. Changes added to
CurrentUserMode
to be able to bypass the session in that case. - Enable automatically admin mode for all sidekiq jobs as we do for API requests. This requires fiddling with the policies and add potentially to check
Sidekiq.server?
inside the policies
Original discussion in !18214 (comment 240114962)