Fun with Authorization
Hello again, and a happy Friday to you! I'm back with a sequel update to the inaugural update. If you're thinking "too soon", that's good feedback. I won't know it because it's a thought in your head, but I appreciate the feedback nonetheless.
In any case, let's proceed with the update. As you'll no doubt recall, we declared last week that the main impetus for the coming week had to do with user authorization in Whally, a new system for running schools. Indeed, the entire week was consumed with such. Substantially gratifying progress is evident 7 days later.
What is authorization?
Authorization is a word in the English language that means "you're allowed to do such-and-such". For example, children often ask "hey mom am I authorized to have a granola bar?" At such time and every such time, a decision must be made. Should the granola be allowed, or denied? What policies apply to this situation? Then an answer: "nope". Or "sure, I'm tired, whatever."
Considerations
The are various ways to approach such decision-making. The easy way is a single policy that always applies to everyone, like: adults get granola, kids don't. Or vice-versa. I thought about using this strategy and being done with the task in a few hours.
But people quickly become annoyed by strict, inflexible policies and demand exceptions. But what about when I turn 12? As almost-adult, kid policy shouldn't really apply. So we need to adapt the rules over time depending on the case. This is where roles and permissions come in.
A permission is a specific action, like "unwrap the bar". Another might be "actually eat the bar". In theory, you could allow one and not the other, but good luck. A role can be thought of as a consistent collection of allowed permissions, like "Uncle Noah can always unwrap AND eat the bar". We'd like to codify such a role and apply it where appropriate, rather than coming up with unique rules every time.
Initial features
Whally now understands such things. You can define a user to have a role. which confers a configurable set of permissions. You can also create any number of custom roles to meet specific needs, and apply these to any user in your organization. In doing so, it's easy to understand at a glance who can access and affect what in the system.
This now exists in the brand-new administration interface in Whally. People in the organization can be managed:
Any number of roles could be invented to suit one's purposes. There will be some standard roles to make things easy:
Fun aspects
User authorization might seem super boring, but it actually has some fun or interesting aspects. For example, what about access to specific items? You might want to "share" a single file or student record to a specific person, like a parent, to allow viewing or editing that information alone. This requires a second layer of access, which Whally now understands and will further manifest.
Also, authorization is a performance-sensitive process. Literally every time you do anything in the system, a decision has to be made about whether you are allowed. There is no "I'm tired, go for it" in the systems world. Ensuring these decisions can be made very quickly and efficiently is a perfect opportunity to bring OCD overengineering to bear.
Other news
In other news, the initial layout for the app is taking shape. One aspect is the Students view, which is the primary place student information is managed. Quite a bit has already emerged here, with instant full-text search and support for many data types including images, files, dates, configurable selections, and more.
Up Next
Once authorization is buttoned up, work can begin in a new, hopefully less tedious area. More soon on what becomes of that.