bcstudentsoftwaredevteam / lsf-oss Goto Github PK

Shibboleth and Local login are both working (mostly). But, code is everywhere.

Notes:

1. refactor to use a before_app_request decorator to load the current user, handling shib or local gracefully and not in the controllers
2. Remove logic from controllers for dealing with current user, since it'll be everywhere from 1.
3. Consider removing the login_manager or making it handle everything more gracefully as well.

If a user logs in with their email address (e.g., [email protected]) instead of their username (e.g., heggens), the system handles the user correctly by adding them to the supervisors table:

Invalid User: [email protected] not found in Tracy database
Adding mcguirem to supervisor table

However, the user gets an Access Denied error page. This is likely because the system does not handle changing their username for each page load. It only handles adding them to the database as a supervisor.

create a small dropdown near the logout button in the sidebar that allows the developer to quickly switch between users/user types (admin, supervisor, student).

Create an interface allowing the evaluation of the work experience by the students.

Rough notes:

• Integrate into supervisor portals for reviewing evals
• Integrate into student portals for completing evals
• Open/close dates + times for evaluating, reviewing, locking
• Create a "transcript" of supervisor/department/division/college labor progression over time (this semester, all-of-time, ...)
• Allow labor administrators to "customize" evaluations prior to the evaluation (based on LEE Committee work; see Scott).
• Allow departments to "customize" evaluations prior to the evaluation (based on LEE Committee work; see Scott).

The Tracy/UTE database holds department information, which we use in the departmental compliance features. Admins will need a way to edit this information. I envision two solutions: 1) a back-end utility for mass import of departments (which does not support the removal or editing of departments); or 2) a UI update to the Manage Departments interface to allow for add/edit/remove (which will make bulk importing harder).

The solution may be to do both of these. This is not a priority issue.

The system should provide labor administrators with the ability to easily process payments to students:

Rough notes:

• Allow labor administrators to set pay rates per position/position level/individual
• Allow labor administrators to view pay for given pay periods (weekly, bi-weekly, monthly, ...)
• Allow labor administrators to send information to an external payment processing system (check printer, finance office, ...).

1. Would you use a local login provider or a campus provider (LDAP, OAuth, SSO, Shibboleth, etc.)
2. How are your labor departments organized? (At Berea, there's labor departments, and departments can have multiple orgs such as the Facilities department has grounds, maintenance, janitorial, etc.)
3. How are student positions organized? (at Berea, each department has positions, and each position has a Work Level Status between 1 and 6 to indicate responsibility level).

Make the logo customizable during install (?). Uploadable any time? In a config file?

During install.sh, the installer asks for a username and password. If the username already exists, it reports the following:

ERROR 1396 (HY000) at line 1: Operation CREATE USER failed for 'test'@'localhost'
User successfully created!

This could be handled more gracefully.

Additional things to check:

• if the username is given a new password, does it change?

The shell of a test suite exists, but a more robust suite should be created, so future development requires it. See CELTS app for a good example.

Currently the system automatically creates terms based on the assumptions that classes run on a semester system. This should be modified to handle a quarterly (and probably other) systems.

Other work colleges need a timecarding system, similar to our Tracy Ultratime system. A minimal timecarding system should:

• Allow a student to clock in and clock out
• Allow a student to review their time cards
• Allow the supervisors to view, edit, delete, and add entries
• Allow the supervisor to approve, reject entries
• Allow supervisors to schedule students for specific hours
• Allow supervisors to view summaries of hours (bulk students, bulk hours/weeks/months/life, ... )
• Warn supervisors of over- and under-hour situations
• Allow labor administrators to do everything a supervisor can do
• Allow labor administrators to review hours for payroll processing (see issue about payroll system)

Rough notes:

Create a config file for managing first install:

• install.sh script that creates the DBs
• read application config to prevent db overwrite
• Implement python's config2 for smarter configuration management across prod/stage/dev

A good config2 example from CELTS app:

• Add code from 12 - 41: https://github.com/BCStudentSoftwareDevTeam/celts/blob/development/app/__init__.py

Create an interface allowing the evaluation of students by their supervisor(s).

Rough notes:

• Integrate into supervisor portals for completing eval
• Integrate into student portals for reviewing eval
• Open/close dates + times for evaluating, reviewing, locking
• Create a "transcript" of your labor progression over time (this semester, all-of-time, ...)
• Allow departments/supervisors to "customize" evaluation prior to the evaluation (based on LEE Committee work; see Scott).

There are essentially four databases needed for the system:

1. The login server (BC uses Shibboleth). This provides the application with the logged in user identity and authorization.
2. The main db. This provides the application with active work college information (student's current and past positions, approval status, ...) and is the database we created for the system.
3. The Tracy Ultratime system. This provides the application with all static work study information (all available positions, all departments, all supervisors, ...). This database is external to the existing application, but Peewee models exist for it already.
4. Banner. This provides the application with a database to hold official records of employment. After a student is hired in our system, the record is added to Banner.

Item 1 should be handled probably through Flask login. The implementer should be able to choose the type of login service they want to use (local login, shibboleth, LDAP, ...).

Item 2 is fully within the existing application. No changes should be needed here.

Item 3 was implemented for testing/development purposes. It should be fully implementable if the user choses to use it (on install).

Item 4 is completely external, with the exception of hooks to write to that database. It should be integrated into the application as well. It only exists because our LSF system had to be able to work with the existing records which were held here. In theory, it could go away (option to make it go away?) and the existing application serves as the record of hiring and firing of students.

PEM is used to migrate that database, for example in reset_database.sh. When PEM cannot find a migration file (e.g., lsf_migrations/0001_migration_202109241252.py), it throws:

FileNotFoundError: [Errno 2] No such file or directory: 'lsf_migrations/0001_migration_202109241252.py'

The reset_database.sh script should handle this error and avoid crashing the reset, putting the database in an unknown state.

Students should be able to evaluate their supervisor. This could be integrated in to the Work College evaluation (Issue #8), or a separate evaluation (more similar to the student performance evaluation).

Based largely on LEE Committee work (contact @sheggen for details).

Rough notes:

• Allow student to view/review/complete evaluation from the student portal.
• Allow supervisor to view/review evaluation from supervisor portal.
• Allow labor administrators to modify the evaluation year-to-year.
• Allow departments to generate reports about departmental performance (or other similar reports; needs brainstorming).
• Allow labor administrators to review supervisor/department performance.