Project

General

Profile

Actions

Bug #16387

closed

arv-federation-migrate-test failing: can't update is_active to false on cached user record

Added by Peter Amstutz almost 4 years ago. Updated almost 4 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
-
Target version:
Start date:
05/04/2020
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Story points:
-
Release relationship:
Auto

Description

This seems to be a regression

arv-federation-migrate-test: #11 /console

HttpError 500 when requesting https://172.17.0.4:8000/arvados/v1/users?alt=json returned "error updating local user records: request failed: http://localhost:8004/arvados/v1/users/batch_update: 422 Unprocessable Entity: #<ActiveRecord::RecordInvalid: Validation failed: Is active cannot be set to false directly, use the 'Deactivate' button on Workbench, or the 'unsetup' API call

Subtasks 1 (0 open1 closed)

Task #16404: Review 16387-batch-update-deactivated-userResolvedPeter Amstutz05/04/2020

Actions
Actions #1

Updated by Peter Amstutz almost 4 years ago

  • Description updated (diff)
Actions #2

Updated by Peter Amstutz almost 4 years ago

  • Assigned To set to Tom Clegg
Actions #3

Updated by Tom Clegg almost 4 years ago

  • Status changed from New to In Progress
  • Subject changed from arv-federation-migrate-test failing to arv-federation-migrate-test failing: can't update is_active to false on cached user record
Actions #4

Updated by Tom Clegg almost 4 years ago

  • Description updated (diff)
Actions #5

Updated by Tom Clegg almost 4 years ago

Actions #6

Updated by Peter Amstutz almost 4 years ago

Tom Clegg wrote:

16387-batch-update-deactivated-user @ 95e9d44b567a92664939f0f89bd45eedd6db67ab -- developer-run-tests: #1833

Ok, so the logic is, remote users are not subject to the check "must unsetup to deactivate", but remote users are not allowed to call "activate" to reactivate themselves.

The one case this breaks is the case where you are using your remote identity to log into a federated cluster, and that federated cluster has a clickthrough agreement. In that case, you have to "sign" the agreement and then you can self-activate.

However most (all?) federations are in a trusted configuration (either using LoginCluster, or NewUsersAreActive is true, or ActivateUsers is true for that cluster) they go directly to 'active' which skips signing the clickthrough agreement.

Workbench2 also currently doesn't support displaying clickthrough agreements.

It's worth noting that ApiClientAuthorization#validate does this:

        if user.is_active && !remote_user['is_active']
          user.unsetup
        end

So I think it would be less disruptive for batch_update simply turn is_active=false into "unsetup" eg

      if u.is_active && !attrs['is_active']
        u.unsetup
      end
      u.update_attributes!(nullify_attrs(attrs))
      @objects << u
Actions #7

Updated by Peter Amstutz almost 4 years ago

It might make sense to disallow self activate when LoginCluster is set (and ClusterID != LoginCluster).

Actions #8

Updated by Tom Clegg almost 4 years ago

How about just changing the new rule from "if uuid belongs to remote" to "if uuid belongs to remote LoginCluster"? (...then can't self-activate, and can change to is_active=false in a batch update)

I'm wary of changing more than we need to in a bugfix slated for a patchlevel release.

Actions #9

Updated by Peter Amstutz almost 4 years ago

Tom Clegg wrote:

How about just changing the new rule from "if uuid belongs to remote" to "if uuid belongs to remote LoginCluster"? (...then can't self-activate, and can change to is_active=false in a batch update)

I'm wary of changing more than we need to in a bugfix slated for a patchlevel release.

Ok, that works.

Actions #10

Updated by Tom Clegg almost 4 years ago

  • Target version changed from 2020-05-06 Sprint to 2020-05-20 Sprint
Actions #11

Updated by Tom Clegg almost 4 years ago

Actions #12

Updated by Peter Amstutz almost 4 years ago

Tom Clegg wrote:

16387-batch-update-deactivated-user @ eddba1916c4667a3de89f632b2b840dbc1d281fc -- developer-run-tests: #1834

This LGTM

Actions #13

Updated by Anonymous almost 4 years ago

  • Status changed from In Progress to Resolved
Actions #14

Updated by Peter Amstutz almost 4 years ago

  • Release set to 33
Actions

Also available in: Atom PDF