@clong ,
I have a couple more questions.
Are we working from the spreadsheet you originally proposed or the one that gets populated by Google Forms?
I'm thinking the original one would be more useful for other people. I've written the code that identifies the columns based on the headings so that it can be changed with a variable setting rather than changing the main part of the code. But I'm guessing it's going to be easier for most people to use "First" than it is "First name of the employee who needs this Canvas account." That means a little more work for you in copying the information over, but I really think that you'd want to check and verify the information rather than taking another user's input at face value.
What do you think about an action field?
As I was going through writing some code, I was trying to decide how I could decipher what needed done. Here is what I came up with.
- Default action is to add an account. This would happen when there was a first name, last name, login id, and maybe nothing else (some people may not want a SIS ID). Definitely nothing in the created_at column.
- There should be some way to update the user information without resetting the password. Let's say that Tom Smith changed his SIS ID, which in reality, he shouldn't, so you may want to consider some other way of keeping track of information -- Tom might change roles, but you're using a SIS ID to indicate a role rather than a role to indicate a role, which is what roles and enrollments are used for. Anyway, you may need to update information after he has already changed his password
- There should be some way to signify the password has changed -- in case you want to do a soft, but not foolproof reset.
- There should be some way to delete / rename the user
Then, rather than typing the Status, we could let the action dictate the status.
I'm not saying those should be the codes, but come up with some scheme (I like -1 for delete). But then once the action has been completed, it gets reset to 0. that way, you know that there is no pending action for the user and can skip them when you process the next time.
The automatic disenfranchisement of an account seems a little aggressive to me, but I'm not the one managing it. I was wondering if being able to sort by date added and then manually just putting in a -1 for the action would work? Or maybe you could have an expiration date in the date, but I just don't do anything with it. If you really think it's pretty firm and you won't accidentally kill someone's account, then we could write the code to do it.
Do you think it's worth keeping a history or log on another sheet?
There's a part of me that says we should keep a record of when changes were made. But since multiple changes could be made to the same account, we need would have a many-to-one relationship. That doesn't fit with the current single-page form, but we could create another sheet and use it for logging purposes.
I don't know how useful it would be, but I've tracked down enough problems to know that logs sometimes come in handy.
What do you think about word-based passwords?
There are studies that show for one-time passwords, words are easier than digits. I've got a system created that looked at the most common 500 words from the English language, pulled out all the 4, 5, or 6 letter words, and then randomly picks 3 of different ones. You're not going for secure passwords, you actually hope they change it.
Given the number of words I picked, there are over 200 million possible word triplets. Again, it wouldn't be secure, and possibly subject to brute force attack, but definitely easier for people to remember and type. It also gets away from the issue of whether that is an el or a 1 or possibly an oh or a zero. You know, those ambiguous cases that people should never use in a password?
Anyway, if you're good with that, it's already written.
I haven't written anything for the specific to the API yet, I was trying to flush out the rest of things before getting there.