rit-sse / node-api Goto Github PK

When I try to update an officer's end date, I get the following error:

I'm currently adding memberships under "Public Relations", which is technically incorrect.

Related to #54, but the documentation is also unfinished.

Quotes are served to http requests, even when they have not been approved

I was looking through the apiary docs and apparently I described an entrypoint endpoint
http://docs.sse.apiary.io/#reference/sse-api-root/retrieve-the-entry-point/retrieve-the-entry-point

Not a terrible idea.

It would be advantageous to set up a development API for the SSE so we don't have to run our own every time we want to make a change to any SSE repo that uses the API. Setting up a dev API will also lower the barrier of entry for working on and maintaining SSE repos, and as a result potentially increasing participation and collaboration.

I want to search for members. My life is difficult.

Currently, Historian has been making spreadsheets / tables of each event that happens during the semester and whether we have pictures for that event.

We have all the data to generate this automatically, so we can save Historian some time.

This feature requires #64 to be implemented, so that we can associate Photographers w/ Events.

There are a few possible ways to go about this:

1. The node-api generates a CSV file w/ Date of Event, Time of Event, Event Name, Committee Name, List of Photographers, (and if possible, the Week # each event took place). We'd either have to make a shell command to make this file or a button in the OneRepo to hit an endpoint and generate it. [Difficulty: Easy, Time: Medium]
2. We query the node-api for Events w/ Photographers from the OneRepo and make a printer-friendly page which displays this information in a table (so that you could print the page, or for example, in Chrome, "Print" -> "Save As PDF") [Difficulty: Easy, Time: Medium]
3. The node-api generates a PDF file directly of 2. [Difficulty: Hard, Time: Long]

@DanSwtmn How are you currently using this data? Which way helps you the most?

This is a really overly broad issues but we should probably filter out some of the things we don't really use or endpoints that shouldn't exist in the first place.

If you have anything to add, put it in the comments with a description.

• committee post/put -- committees are really only created with officers.
• agenda -- using google docs so probably don't need it.
• tips/lingo -- why are these even here?

As mentioned in Issue #42, the project description of this repo needs to be updated since we have a new subdomain.

It currently reads:

The SSE new and improved unified API https://sse.se.rit.edu/api

It should read:

The SSE New and Improved Unified API https://sse.rit.edu/api/v1/

Currently, Historian has people who take pictures at events zip them up and submit them through a Google Form. Then Historian has to manually add memberships for the people who submitted photos. Finally, Historian updates a spreadsheet of all the events that happened during the year including who took pictures at those events (if any).

This could be streamlined:

• Person takes photos
• Person goes to the SSE website and looks up the event that they went to
• Person clicks 'Submit Photos' button on that event
• Person must log in if they are not already
• Person is given a form that captures their name (from their login), the event (from what they clicked on), and a dropzone file upload form
• Once the form is submitted, the files are uploaded to Google Drive using its API
• A pending membership is automatically created for that person for that event for the Historian committee

On the API, the following functionality would be needed:

• Make another table & model for "Photographer". Events have many Photographers.
• Make an authenticated events endpoint (eg. POST /events/:id/photos) which takes images. This endpoint looks up the User submitting, makes a new Photographer row, associating this person w/ the event. images accepts a single JPG, JPEG, PNG, GIF, or ZIP and sends it off to a Google Drive folder (specified as an environment variable). Then a new pending membership is added for this person.

Stretch Goal:

• Incorporate Slack: Post a notification to #sse-historians when images have been uploaded w/ a link to view them (the folder permissions would likely have to be set to "Allow anyone from RIT to view")

@DanSwtmn Anything else?

This way we can manually at the end dates for officers.

This might fix a lot of our existing issues.
For example:
sequelize/sequelize#5106 is probably the fix that will make committees?active work again.

See rit-sse/scoreboard-2.0#41

Probably because we changed to /api/v2, probably just have to update https://github.com/rit-sse/node-api/blob/devlop/apiary.apib#L2

There are a lack of them

While this isn't explicitly a code issue, since this is a web API having a valid SSL cert is important if there is one :)

The current certificate expired on 1/30/2016, which is almost 8 months ago at this point in time.

Edit: This appears to be because the link in the description of the project leads to the wrong URL.

This should be corrected to https://sse.rit.edu/api/v1/ most likely, or a link to the Apiary docs?

Like github does.

Related to #55

There are routes in the Apiary definition which were implemented and then removed.
There are routes in the Apiary definition which aren't implemented.
There are routes that aren't in the Apiary definition.

To Remove From Apiary:

• Anything to do w/ Agendas
• Anything to do w/ Lingo
• Anything to do w/ Tips

To Implement:

• Create a Committee
• Update a Committee
• Delete a Committee

To Add to Apiary:

• /go/:shortlink
• /scoreboard

Also, double check the mentoring-related routes – there's probably stuff missing in them.

👎

The setup command expects the output of npm run keygen before it runs the command, resulting in errors.

The node-api has some basic support for mentoring related things (headcounts, mentors, shifts, specialties); however, we don't currently use them, and our frontend doesn't use them (specifically commented out).

Is it still desired to have mentoring related endpoints in the node-api w/ some sort of frontend for them? (If so, I would like clarification on what we actually need, so we can modify/build the right thing)

Or, have we found suitable alternative tools, and should we remove the existing mentoring related features?

@vuzDylan @khanny17

Probably should. Probably the right call.

I'll get to it eventually.

Authentication and Authorization

And you know other things like that.

1. Create an event w/ a valid image URL
2. Update the event w/ "" for image URL

What should happen:

• The event is updated with an empty image URL (or sets that column value to null)

What currently happens:

• Validation error: Image must must be a valid URL

See Here

We talked about sending an email to people when they get their first membership of the semester congratulating them and explaining what membership gives them.

Mailgun has 10K free emails a month which seems like a viable option.

Acceptance Criteria:

• Integrate w/ Mailgun
• Create email template w/ body copy
• Send the email to users if this is the first membership they are given this semester

fix auth [inprogess]

Whoops...