devcom-iitb / instiapp-api Goto Github PK

Apparently, the build environment was also accidentally pushed to git, so now a history rewrite would be required to fix the repo, which has become thousands of objects as a result of this. Should be done ASAP, as this would diverge everyone's forks and local branches.

The refresh token given by SSO should be stored and used to refresh the profile when it nears expiry. The expected behaviour is that if the user revokes the token, then they should be logged out.

Events marked as archived will not show up in the regular feed, but are still accessible through a separate section. Create a separate issue for automatically archiving old events once this is done.

1. Create UserProfile
2. Destroy UserProfile

After the body is created, the persons should be able to create roles. #46

This issue serves as a tracker for each endpoint. Create a separate issue for each.

With priority for Events, implement pagination and other filtering at server side.

Make this into an institute role #46 #47

Common privilege for roles #46

Pull details such as program of study, year of study and expected year of graduation from SSO. These fields also need to be added to the UserProfile model first.

Will help to prioritize content easily. Currently only hyperlinks are returned.

Events can be tagged and users can mark tags as interested. The prioritizer will give more weight to tags with interests.

wercker offers a free CI/CD service for private repos, so we can use it to automate testing. I've setup the same on my fork (check the README) and it runs the tests as expected.

@ydidwania you can set it up on this repo too (would've done it, but it needs admin rights). You will need to set the WERCKER_SOURCE_DIR environment variable to $WERCKER_ROOT/backend. I've already added the YAML which should work as expected.

#46

#46

When logging in, check if Hostel information is present in SSO and pull it in if yes. Update UserProfile models for storing this if necessary.

The number of people who have liked the content or the the number going/interested can be updated from Facebook events, if the creator provides a Facebook link. While doing this, make sure it is done only for active events.

We want at least the person's name and roll no. Revoke the token and show and error if these aren't there.

This is returned as 'username' in the profile, provided we have the scope. If we don't, but we have the roll no. store that as a fallback.

Fix #18 before this.
Whole list of logged-in endpoints at #28

See if it's possible to implement retrieving UserEventStatus relations using a ManyToMany field. Something similar here

If present, the client may want to show a separate button to open it.

Institute roles (for now) mainly relates to creating bodies #46

Logs should not be verbose, but include critical information including creating and modifying entities, and managing user permissions etc.

#46

#46

An endpoint for getting mess menus of the user's hostel

All logged-in user endpoints at #28

Fix #27 before this.
Whole list of endpoints at #28

After #47 is done. #46

Only check if the user is authenticated to create locations. An InstituteRole(#47) is required to update and delete. #46

The current default is a hard-coded "iitbuser". Since we desire some level of uniqueness (though this is completely optional, obviously), the default username should be the id returned by SSO.

Common privilege for roles #46

When inheritable is true, the role should satisfy all children bodies of the body recursively #46

Implement the User Permissions model which will assign permissions to users for creating events for bodies etc.

Tracker for authorizing various endpoints

Featured events (similar to promotional) will have an extra weight which can be added only by users with high elevation.

Only the user themselves should be able to update UserProfile #46

Why does our API spec violate every industry convention?
This is a nice list, you'll find the same elsewhere.

More specifically:

1. There should be no verbs in URIs
2. Using PUT and DELETE where appropriate is very important
3. Singular/plural have been messed up in a couple of places
4. Should specify proper nesting (e.g. bodies should inherently contain related events)

Create a separate role permission
#46

Each person who is supposed to create events for a body will have a 'Role', which will have permissions over the body. Any role may be satisfied by multiple users and a user may have multiple roles.

Whole list of logged-in endpoints at #28

Returning all associated events with the body itself including HATEOAS should make working with the API easier. This will also reduce load times since the separate events call can take place only after the body call, adding another RTT. Children bodies may be returned without the events with self links recursively (should make caching effective).

May be implemented as a separate endpoint in case there are situations where it is unnecessary.

Note: The response size should not be a concern as gzip works wonders on JSON and we won't usually have >50 events for one body

Common privilege for roles #46

After #47 is done. #46

Events should be prioritized by the server and attached "weights". This would involve writing the algorithm used to prioritized, which can initially be empirical.

Some venues like Behind ED Lab may not have any reuse value, so there should be some mechanism to store them but not suggest them the next time a user is creating an event.

#46

Are there plans to implement featured events (events that will be shown with priority to everyone regardless of whether they are following the bodies)?