city-of-bloomington / account_tracker Goto Github PK

We want the transition from server-side backend to JS frontend to be as seamless as possible. The html for the backend should probably be templated to match the markup of the frontend

Staff should be able to see the list of pending account requests. This screen should support various search filters. The account requests results should provide links to view an individual request that was filed; as well as link to the Employee Info screen for the employee in the request.

#17

We should add CAS authentication. We may want to replace the LDAP authentication backend, once we do. CAS authentication will not be an authentication backend.

When querying a service profile (/api/profile/), it would be helpful to tack on the name of the service.

For example (current):
"services": [2,...]

Want:
"services": [{"id": 2, "name": "3D Home Architect 5.0 Deluxe"},...]

We want to be able to deploy this application with Ansible. That way we can store and version all the needed configurations in our cob-inventory.

Profiles are the predefined values to be used to create all the resources for an employee. These will need to be organized and saved somewhere. Administrators should be able to edit profiles to fix resource values.

#17

There is some content here that is test content.

We need to be able to display the requested account information that was submitted. This allows Staff to review the requests before approving and creating the accounts.

#17

When an Account Requests pings for their Services Request initiation, we should check to ensure that it's not a duplicate request.

Staff wil need to be able to modify the account requests before they are approved and the user accounts are created. Permitted staff should be able to change any of the user account values that are being requested.

#17

We probably do not want to use sqlite in production. We're going to want to do storage on a database. MySQL is our preferred database engine these days. We should add mysql support.

These are two separate applications that must be deployed separately and with different web servers. It would help during deployment to have them organized into separate directories. It might even be worth having the frontend be a completely separate Github repository.

Construct a Users, "full name - full_name," from their first, middle, last & suffix.

Doing so helps simplify things on the frontend.

This should be included in the User results at /request/

Current:

first_name: Adam
middle_name: G
last_name: Butcher
suffix: Jr.

Goal:

first_name: Adam
middle_name: G
last_name: Butcher
suffix: Jr.
full_name: Adam G Butcher Jr.

We need a screen to allow Hiring Supervisors to search for employees in the HR system. They should be able to find and choose the employee they are wanting to activate user accounts for.

#17

This form should ask a Hiring Supervisor the minimal amount of questions needed to create all the employee's user accounts. After filling out the form, we should display request review, displaying all the user accounts that are being requested for that employee.

#17

We've started this project without a clear plan for what we were building. There has been good progress, but we're getting cramped for time.

We should write up the desired features of the software, so we have something we can share and point to, in order to prioritize future work.

We must not update AD via an unauthenticated web service API. The HMAC strategy seems like the best route to implementing authenticated web services.

When hitting /api/ to authenticate a User, the data returned to the frontend needs a little more info.

Currently, this is what is returned upon success

{
    "request": "http://127.0.0.1:8000/api/request/"
}

Helpful things to include would be:

• Name (first/last)
• Email
• ID

• HMAC authentication
• CAS authentication
• HTML for backend and frontend matches

Screens to build

• Employee search
• Employe info display
• Profiles
• Activate accounts form
• Review account request
• Account Requests search
• Account request info
• Account request edit

All of our configuration values need to be removed from settings.py and any other file inside the project directory.

Configuration values should be read in from an external file and assigned inside settings.py. Typically, we use an .ini file to store our values, and settings.py reads the values in from production.ini or development.ini

We need a screen to show user account information for any employee in the HR system.

When the employee does not have any user accounts, we should have a link to "Activate" user accounts for the employee. If the employee already has user accounts, we should provide a link to "Change" or "Terminate" the user accounts for the employee.

#17