(1) it is messy - when seeing an account name ‘ericf’ we no longer know if this is research or class user,
Well to me, the current approach is actually messier, even if it may be convenient given the current interfaces. My preferred approach is always to explicitly structure the data type on the backend to track the relevant information (such as account type), and then make it easily queryable through the user interfaces – i.e., mrg list users --type edu (or some such), or a dropdown list on the GUIs.
The current approach encodes semantics of the account type into the naming scheme. This is fine but it introduces a constraint that Merge is not aware of anywhere – anyone could happily come along and create an account that matches this regex and then run the risk of polluting statistics, not to mention possibly getting caught in automated recycle processes.
I don’t think we need to belabor this issue, it’s just a difference in our tastes. Perhaps we do both things: 1) enforce restrictions on how restricted accounts are named, and 2) explicitly track account types.
(2) it requires more work on our end to implement - the way it is now I can transfer everything to new platform easily, just need some help with GUI. With your suggested solution I will need more ops time to also add all the controls in the backend.
It may require more work, but I am not so sure about that. As I said, most of what I propose above already exists in Merge. What you propose seems simple enough but that will be a question for Geoff to answer once he’s dived into kratos internals. I also don’t know what TBD constraints will arise on how we have to handle IDs, authorization, account resets etc. once we implement CILogon support.
(3) it puts more work on students, which means more questions for us.
We are just talking about clicking a button to create an account, correct? Am I missing something?
Admittedly, I do tend to overlook how things I think are simple are not always simple for students.
(4) we and instructors can no longer debug student issues because we cannot login as a student.
We cannot login as students, but as I said, we can login as ourselves and, via the Merge policy layer, be given permission to see exactly what they see and debug issues from their perspective.
Think about this as akin to ssh briankoco@system, followed by sudo su - mirkovic. I didn’t login as you, but I can see all of your data. Just about the only thing I could not directly debug are the actual login or SSH issues you might have been experiencing.
As I noted, this already mostly exists, I am not proposing to build any complex new functionality.
(5) instructors are already used to what we do so far, so they have to change their workflows too.
(6) it complicates demos - I can no longer pre-create accounts with set passwords for 30 people and just hand them over in a demo.
Point taken on both of these.
On the other hand, the solution we have works now, it is portable to our new platform and really does not require more than one small change to check if there’s a duplicate mail and introduce the alias into our system. From that point on demos work, HotCRP works, classes work and we only have GUI work to port education functionalities to our new platform.
I understand this, but getting something to “work” on the system is only part of the task. We also need to make sure we can operate it and maintain it, and possibly extend it as needed in the future. While the points I’m raising above might seem like me making a mountain out of a mole-hill, it’s all oriented towards trying to abide by the way in which Merge is designed, so that people like Joe can maintain it.
I agree that auto-generated restricted accounts have some very nice uses, especially around bootstrapping demos. I’ve seen demos where ~30 mins of a ~60 min demo slot is spent getting accounts created for people. And I can see some of the benefits for classes. So I am not really pushing back against that at all.