grahamgoudeau/mcg-portal

Networking portal for current students and alumni for MCG (http://mcgyouthandarts.org/)

mcg-portal's Issues

Exclude your own resources from connections/jobs/events

Text box with draggable size for job/event details

Add "Visiting Artist" account type

Email notifications

Provide Sam's email instead of mine on Help page

Frontend: Add a new job posting && Backend: add new job posting into server(database)

REST tests should stand up independent instances of everything

Ask client: What pages should be publicly accessible?

Event details?
Jobs?

Provide information about person supplying job posting

On the job details page, we should be supplying:

• first name/last initial of the person supplying the job posting
• the enrollment status of that person if it is non-null

Confirm account changes

Creation and updating

Investigate loading number of admin tasks before sidebar slides open

Provide suggestions when creating a resource

On the account screen, you can list a resource you're offering to the community. MCG would like some suggestions in a dropdown, with the ability to still provide a free-form answer if desired. That list is below.

I added a new component: ui/src/components/connection/ResourceSelector.js that should help with this. You can see an example usage of it on the connections page. Search for usages of ResourceSelector. You provide an onChange prop to it when you use it, and the value of that prop is some function where you use the newly-chosen value.

* Panel Speaker
* Resume Review
* Mock Interview
* Job Shadow
* Career Advising
* Education Advising
* Job/Internship
* Temporary Housing
* Project Funding
* Project Partner
* Other ___

Connection request resolving

Backend: Add more details to user profiles

We need to add OPTIONAL fields in the account table for:

1. bio/personal blurb
2. current role
3. current school
4. current company

Next, add an endpoint to the backend server:

GET /api/accounts/<int:userId>

It should return the following JSON:

{
  firstName: string,
  lastInitial: string,
  bio: string,
  currentRole: string,
  currentSchool: string,
  currentCompany: string,
  enrollmentStatus: nullableString,
}

List events

2. Allow an admin to mark a connection request as "resolved"

Checklist, similar to #2

• The route should be /api/connection-requests/<int:connectionRequestId>/resolved
• It should have the following two annotations: @jwt_required and @ensureOwnerOrAdmin (to ensure only signed-in admins can perform this action)
• Should add a method in the connection request "handler" that we created during issue #2 to handle this new "mark resolved" action
• That should call a new method in the database class
• That new method should run some SQL that looks like: UPDATE connection_request SET resolved = TRUE WHERE id = %s, and of course we substitute in the "connectionRequestId" parameter that we received in the first checkbox above ^

Should test with something like:

curl -XPOST -H 'Content-Type: application/json' -H 'Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpYXQiOjE1OTIzNDk1MDAsIm5iZiI6MTU5MjM0OTUwMCwianRpIjoiYjJmYzQ0YmMtYjBkNy00ZmFiLTk5OTMtZmRlZjRmYjg2MjkxIiwiZXhwIjoyNDU2MzQ5NTAwLCJpZGVudGl0eSI6MSwiZnJlc2giOmZhbHNlLCJ0eXBlIjoiYWNjZXNzIiwidXNlcl9jbGFpbXMiOnsiaXNfYWRtaW4iOnRydWV9fQ.3bCdlwmXChH4Q4RlKaP_u-tmkBqkjciQet7R0f05aes' localhost:5000/api/connection-requests/99999/resolved

but of course swap out 99999 with a real connection request ID. You can find them by running make run-psql and then:

SELECT id FROM connection_request;

Bug: User can be created with no enrollment status

Frontend bug, filing for those who want a bit of a challenge. To reproduce the bug:

1. Visit the user creation page
2. Fill out the form
3. DONT change the enrollment status dropdown
4. Click "Sign Me Up"
5. Check in the database for the user you just created. It will have a NULL enrollment status, when it should be "Current Student"

Add filters to Request Connections page

After #43, we will have pre-set resource names that users can choose to offer. We should add filters to the browse/connections page to take advantage of this.

Should look something like the random example that I found online, attached below. Look at the "Completed Scans" section. We should have floating filter(s) over to the right on that page. Probably one for enrollment status, and one for resource name. Doesn't have to be exact, but something like this.

Bug: Object of type 'Resource' is not JSON serializable

To reproduce:

1. run make run-psql
2. in that postgres shell, run insert into resource values (default, 'test', 1, null); (this will insert a "resource" into the database that we'll try to retrieve in the next step)
3. start the server, then run curl localhost:5000/api/accounts/1/resources

We expect the output to be the JSON representation of the resource we added. But instead we get a 500 Internal Server Error

Manage events and jobs from your profile screen

Password reset flow

Set last initial into account_revision table and propagate it correctly

Export metrics

Ensure no concurrency issues with admin approvals

Probably means locking the table

Connections.js shouldn't duplicate hostname logic

Connections.js is broken in production. We shouldn't be duplicating logic for determining the hostname. The hostname should be passed down to the Connections component through props

Collect site usage metrics

• number of accesses
• number of total users

Make sure events expire correctly

1. Create new event

The structure of this work should pretty closely follow the checklist in #2. So view that ticket for a high-level summary of the work here.

Changes from that ticket:

• use the event table
• the route should be /api/events, and should be a POST request
• in the route function you'll create in server.py, be sure to call the helper function getRequesterIdInt (get the user ID from the secure credentials they provided) to get the value for the organizer_id column. To say another way: Don't accept a user ID through the JSON body, since that isn't secure. Get the user ID from the secure credentials, which can't be faked.

Frontend: Add more details to user profiles

This depends on #42 being done. Once that data is available, there are two things we need to do:

1. Display that info (bio/role/etc.) on a user's personal account page
2. Add a button to the "Request Connection" card that can take you to another user's profile. That page should display the limited personal information that comes back from GET /api/accounts/<int:userId> (the new endpoint from #42)

Multi select in "Create new resource" dialog box

Add "Staff" as an enrollment type

We should consider renaming "enrollment type" since "Staff" isn't an enrollment. Not a required part of this ticket, but keep it in mind in case something good comes up

IMPORTANT: This means that we also need to add logic in the createAccount function of accounts.py, to throw an error if someone attempts to create an account with enrollment type of "Staff". (We should only mark accounts as "Staff" through some other process)

4. List job postings

1. Create a new database table to hold job postings

The table definition should go at the bottom of standUpDB.bash. Follow the pattern of other tables to whatever extent is useful. The table should have a singular name, something like "job_posting".

Be sure to include a boolean column named "pending", defaulting to TRUE. We want the workflow to be that admins have to approve before job postings are seen by others. This is so that minors don't put up job postings.

Add copy about adding custom resource instead of pre-set ones

Backend: Get user account details

Path should be GET on /api/account and it should return a JSON object with the relevant user details (first/last name, email, enrollment status)

Clean up admin-restricted routes in auth middleware

Frontend: Show all members we can connect with

Using the backend implementation done in #19, display the users with their resources on this page. Consult Jose's wireframes on figma (link in our Slack)

Frontend: Show account details

Take a look at Jose's wireframes in Sigma. Should show the user all their information (email, first/last name, enrollment status)

Full editing of name

2. Allow backend to create new pending job postings

Follow the same general overview as #3 and #2. Be sure to let the "pending" column take its default value of TRUE here.

Route should be /api/job-postings/, and we should POST to that route.

Frontend: Show all job postings

Land on profile page after registration

Index on approval request IDs

3. Allow admins to approve a pending job posting

Checklist, similar to #2

We want an admin to be able to come in and approve a job posting after they've verified whatever info they need to about the person posting it (specifically, whether or not the person is a minor, etc)

• The route should be /api/job-postings/<int:jobPostingId>/approved
• It should have the following two annotations: @jwt_required and @ensureOwnerOrAdmin (to ensure only signed-in admins can perform this action)
• Should add a method in the connection request "handler"
• That should call a new method in the database class
• That new method should flip the value of the indicated row's pending column to TRUE.

Fix Jobs UI

1. Create a new connection request

See the table connection_request that we create in standUpDB.bash. We need a way for the backend to create a new connection request that an admin will review.

Requirements:

• The route should be /api/connection-requests and it should be a POST request.
• Create a function in server.py to receive that above route. It should be marked as @jwt_required, and @schema.validate with some schema that we think is reasonable
• Following the pattern of handlers/accounts.py and handlers/resources.py, we should create a new "handler" called handlers/connectionRequests.py that the function in server.py calls. Imitate the pattern of the account and resources handlers here
• That new handler will probably be pretty empty; it should just log whatever message we think might be useful, and then call a new function that you'll create in the db class (db/db.py).

Done!

Job Approval UI

Suggestion for account editing fields populate wrong fields

Frontend: Show all events, event details and add new event && Backend: add new event into the server(database)

Backend: Get all members with the resources they offer

This will be the endpoint that drives the connection requests page. We'll use this data to render the frontend later. It should be a GET to /api/accounts, and it should return an array of JSON data that has the following shape:

{
  "firstName" string,
  "lastInitial" string,
  "resources": array
}

and each item in the resources array looks like:

{
  "resourceName": string
}