sfu-fas / coursys

Course management, administrative tasks, advisor notes, this blob of Django code does it all.
Other
63 stars 22 forks source link

need better handling of role accounts #62

Open gregbaker opened 9 years ago

gregbaker commented 9 years ago

Proposal: Create AnyPerson as an abstract model class (https://docs.djangoproject.com/en/1.8/topics/db/models/#abstract-base-classes). Person inherits from it. So does the new RoleAccount.

That way we can have more fine-grained control over what role accounts can do: receive email yes; log in to make decisions no.

philb61 commented 8 years ago

We wrote this differently, see the AnyPerson model class. However, we still do need to decide exactly what to do with the RoleAccounts in there.

philb61 commented 8 years ago

Some extra data: calling the API call from userid_to_emplid (see coredata/queries.py), we see that we get back a fake emplid for role accounts (one starting with '0000'), so that could be a way to detect them.

The issue here being that we may want to create Person objects automatically for people the first time they log in (for example, if they need to be authenticated to fill in forms. Right now, some people logging in will have a User record, but not a Person record. In the case of online forms, this is problematic, since they are detected as logged in, but will get an error message when trying to access forms). If we decide to go this way, we will most likely want not to create a real Person account for Role Accounts, but rather a RoleAccount record, linked to an AnyPerson record.

philb61 commented 8 years ago

Huzzah: We sort of already have logic for this, See: ensure_person_from_userid in coredata/queries.py

However, we need to: Make sure in the case of a Role account emplid, create one of our new RoleAccount -> AnyPerson objects instead of just creating a real Person. We can then decide what to do with them then. Also: Need to migrate current RoleAccounts to this new feature, BUT, we first need to decide how to handle them....