Bulk Disable User Logins Weirdness

John Ronan

All,

I just came upon a need to disable several hundred logins. Last year, I was able to do it quite handily using a ‘user management \\ username’ import . (i.e. category: 'user management' ; import type:‘username’ ).

Since BBID, this import no longer exists, so I was informed that I must instead use a ‘Contact Card-Import/Refresh \\ General User’ import and set the ‘disable_login' column to ‘Yes’.

But the CATCH seems to be this only works in the flavor of import that uses the host_id; not the flavor that uses user_id. (sure enough, the ‘disablelogin’ column is missing from the user_id flavor)

I tried it by using sticking a host_id in a record and the import worked: it disabled the account.

But since we don't generally use hos_tid, it looks like I'm gonna have to jam some [unique] values for all my records simply to do this import.

Is there a reason for this limitation? It seems to impose an extra layer of work for no good reason and a bulk operation like this could cause problems. e.g. How do I ensure uniqueness in the host_ids? The only safe approach I can think of is to jam each record's userid into the host_id but this seems a little wonky if not downright dangerous.

Has anyone run into this? And is there any reason for this restriction?

Thanks.

Susan Ott

@john ronan Can you not use the disable login feature from the BBID authentication page under Core-Security?

John Ronan

There is no “disable login” feature on that page that I see. [though there is a “disconnect”, which is not what I want to do].

Also, the list that is presented there, and the filter criteria, are not sufficient.

Jessi Walters

@john ronan hey there! On the Unregistered tab, you'll be able to Disable accounts in bulk, but we currently only offer this for Unregistered users.

Can you tell me a little more about why you want to disable a group of accounts but not disconnect their BBID? When do you expect they'll need their BBID account to be connected to the school again? Whether disabled or disconnected, the user will have to contact the school and/or a Platform Manager will have to take action so the user will be able to log in again. Also, what filter criteria is missing from the lists? I'd love to hear more about what you're trying to do with as much context as you can provide.

It's worth sharing that the Core team will soon add the “Hide disabled” filter and the Disabled column (matching the User list) to the Registered and Awaiting response tabs on the Blackbaud ID authentication page.

Thanks for the feedback!

Susan Ott

@john ronan there is a disable feature but they have to be disconnected first. If you look on the unregistered tab, you'll see the disable option.

John Ronan

@Jessi Walters, here's our admissions workflow this time of year:

• all applications are in ; reviews of applications are done; we know what decisions we're going to enter
• We're ready to enter financial aid, scholarship info, etc.
• We want to ‘black out’ the parents for the few days we are entering all this data because we need to present the decisions on a specific date next week.
  (Note: we realize there are ‘publish dates’ on some of these items [decision, fin. aid, …], but we don't necessarily trust them and also, some of these ‘publish dates' do not provide a precise time, which we would need.)
• Now we'll convert any review stuff to actual decisions and enter the financial aid info.
• On the exact time we're allowed to publish, [one evening next week], we'll lift the blackout by reenabling the parent accounts.

John Ronan

@Jessi Walters, BTW, I am assuming [and relying on the fact] that disabling an account and subsequently re-enabling it will not involve any BBID stuff….

John Ronan

@Jessi Walters,

The folks we need to disable in bulk include:

• Parents of candidates applying to 9th grade for 23-24 to the “Academy/Honors” school program
• Parents of current 8th graders

And it gets even more complex than that sometimes. I wouldn't expect your team would be able to satisfy by adding additional filters ad hoc.
Our plan is to pull up these records via an advanced list and deal with them that way.

The only way to manage all future needs, it seems to me, is to either enhance your list capability at a very basic level, allowing the creation of lists that use any criteria having to do with the objects needed [in this case, candidates and students] or for this particular case, allow us to throw an advanced list at the disable account feature.

The former is preferred, though I'm sure would require some deep rethinking of the list system, but, honestly, it was available and much loved in EE… ?