Auto expiration for users

[squidgetx]

From Chris:

Hi Dev Team,

I wanted to check in regarding the privileges of graduated seniors. Does Reservations automatically ban them or do I need to do this myself?

Graduated seniors no longer have active bursar accounts, which means if they check out equipment, there's not actually any incentive for them to return it, because we have no way of billing them, so it's pretty important that we remove their reservation privileges. If they'd like to continue reserving equipment, I'm definitely open to retroactively unbanning them once we figure out some way to keep them accountable, but they should have to email us if they want to do it.

Thanks!

A feature that auto-banned users would be cool, I guess. How long do seniors keep their netIDs for, though?

[dgoerger]

I've heard reports as an ST that NetID/VPN access lasts at least three years, so, it's a while sans Bursar.

Thought: in the admin or maybe superuser mode, allow said user to select all users of a given affiliation (e.g. "YC TC 2013") and mark them as banned. We could allow searching by partial matching (e.g. "2013"), so for Yale you wouldn't have to go through each of the college and school affiliations for a given year. If we wanted to get super-fancy we could display the matching users in a table, with check boxes ("check all / none"), so exceptions could be made for e.g. continuing employees.

I suggest this as opposed to a regular cron job or reservation-time check, because (1) other organizations will have different expiration times than us, and (2) the vast majority of patrons will not be trying to check out equipment post-graduation and I do not think it would be wise to query the database on every login or reservation-attempt, just to check if the user should be auto-banned.

[squidgetx]

True. However, isn't it trivial to edit affiliation? We'd have to also rework the permissions (#419, #547)

Edit: Well, I mean anyone with staff level permissions and up can edit affiliation.

[dgoerger]

Oh, true, patrons can definitely edit their own affiliation. We would however encounter this problem, regardless of the implementation (how else would we automatically determine year and eligibility?). I'm not too keen to prevent users from editing their own affiliation, either, but if we're okay doing that, I guess we're okay doing that to patrons. :-/

[squidgetx]

On development there's no button to edit users, though (at least when using 'view as patron') I can still edit my own profile via appending /edit/ to the user url. I'm not sure if that's intended behavior though.

[dgoerger]

There's an edit button on the bottom of your user page in the patron view; no need for URL hacks. :-)

[mnquintana]

I agree with David's solution. We should be able to pull class year and affiliation from LDAP (they're separate fields, so we wouldn't need to do any string searching really), and make those fields un-editable by users.

Then we should:

1. Create a new view for this batch processing feature (I think it should be a more general batch processing feature, rather than a specialized "batch expiration" feature)
2. Render all users in a table with checkboxes next to each record.
3. Present filtering options to the admin. These should include things like Class Year, Affiliation, Role, etc.
4. Allow admins to select / deselect all results that match the selected filters.
5. Allow admins to make batch changes to the selected users, including marking as Banned.

It might be useful to add an option in app config to let admins turn on some kind of reminder feature set to a date of their choice, so that every year when they sign in say, on Commencement, they'll be reminded to "ban" all graduating seniors.

Although in the future we might want to add a "Graduated" attribute, if only for semantics. (Imagine if a user tries to come in, and their profile is marked Banned - are they Banned because they abused the equipment, or are they Banned because they graduated? Those are two very different use cases that would affect how they would be seen at the front desk. So even though they'd have essentially the same business logic, I think it'd be semantically useful to distinguish between Banned and Graduated users.)

[dgoerger]

I'm hesitant to establishing another reliance on LDAP, an open standard but one which we shouldn't expect everyone to use, for whenever we finally implement non-CAS login in #2. If we're comfortable requiring LDAP for this feature, yes, a 'quick' series of queries should be easy, although I think keeping it within Reservation's database is probably the better track.

I really like the idea of a sortable/filterable table with checkboxes, and for admin-reminders.

The differentiation for Banned/Graduated users seems a justified one. My only reservation is introducing a very school-centered term ("graduated") to a general purpose application. Perhaps we can hash out some sort of compromise term in #553. :-)

[squidgetx]

Could we use the string search functionality that we have implemented on most of the model index pages? (User affiliation should show up on the index page anyway).

• then disallow patrons from editing affiliation (similar to how they cannot edit their netIDs)
• add checkboxes to the user table and wrap it in a form
• jquery select/deselect all
• deactivate/ban/graduate all selected

This seems fairly doable, doesn't use LDAP, and also automatically allows batch filtering based on any attribute (or part of an attribute). The only issue is if a user is cross-referenced in search (eg, if an admin filters by '12' and someone's netID has a '12' in it). This really wouldn't be a major issue (because of the unliklihood of this happening, esp. with larger search terms like '2012') but if there's an easy way to restrict the filter by data column, then hey, problem solved.

[dgoerger]

That route should be doable through adding another two columns to the datatable, for one for the checkbox and another for affiliation. The admin would have to be clever enough to up the number of viewable users per page (datatables is paginated), and might have to perform the action multiple times if there are more than 100 matching users (we could alternately provide an option for displaying 500 or 1000.. I think the current options are hard-coded), but that is on the whole a minor inconvenience relative to deactivating users one at a time.

[orenyk]

Note that this can currently be handled by importing a list of expiring users by username (either CAS or e-mail), selecting "Update existing", and selecting the "Banned" role. It's not great and might end up creating unused banned users if LDAP is enabled, but is better than nothing. We should eventually try and implement this, though.

[orenyk]

Ok, after some further thought, I think that we should actually reserve the ActiveAdmin interface for this. Technically we could easily add an "expiration date" to users and a rake task to ban them after that date, but it would be unwieldy to set through our current interface and we definitely shouldn't be tying this to any kind of LDAP status. The truth is, our current solution of:

1. search database via RailsAdmin for users with a given year in their affiliation
2. export those users as a CSV file
3. tweak the headers so that the users can be re-imported
4. import the users and ban them

isn't too far from what we're trying to accomplish. I would say we can merge this into #1063, set up a custom search to pull all users with an affiliation match to some query string and ban them. More generally, we'd be setting up a way to search for and add users to a batch, and then have a set of actions that can be performed on those users (requirements, status, etc). I'm closing this issue and will comment in #1063 with a summary of the plan for this request.