Skip to content

Refactor Person and GuestPerson classes #53

Open
@rsdoiel

Description

The structure of Person and GuestPerson behaves like GuestPerson is a subclass of Person. The Person class should be the parent and not sited to a specific database presentation or storage. A subclass would then be used for stored Person objects via the ORM. This will allow us to store a minimal class of users while allowing general access through the fact of having a Shibboleth/Basic Auth managed account.

Person class when instantiated holds a default user description with the uname assigned on instantiation (e.g. the value that Shibboleth passes as REMOTE_USER). It should contain the following attributes - uname, display_name, role. The person class would define a standard set of methods like has_role() these would return results based on the attributes held in the object instance.

A generalize function like person_from_environment() could then return a Person compatible object based on either the default Person class or the subclass where the attributes are populated via the ORM.

Ideally the server code should think all Person objects are the same but behind the scenes we only store rows in the SQL person table for specific people who require more than the minimum access.

The eventual goal is for people.py and people-manager to become a common package use across applications that we build for apps.library.caltech.edu.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

Labels

Enhancement ✨New feature or requestRefactoring ✄Functional code that needs revision for ease of maintenance for future improvements

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions