pennlabs / penn-mobile Goto Github PK

There are a lot of redefinitions on def APIError(ValueError). I think it might be a good idea to store this generically in utils.py. After that, there are two options:

1. Write a from ... import APIError on every file
   or...
2. Find a way to automatically import this file in every Django application! This is optional. But, these two pieces of documentation should give you a good starting point: here and here

We would really prefer option #2

A user should be able to invite a member to a group even if that member is not yet in the DB. Thus, we should save invitees as Pennkeys or Penn IDs and use those to map to an account.

Probably worth to do in terms of increasing performance of ORM

Because we often receive a large influx of new dining items, we want to speed up the performance of loading all of these new objects into the DB. Here is a quick TODO to help us do this! See if you can initialize this list with a set length. That way, we can avoid the overhead cost of doubling the array size every time w hit capacity!

Since we have a wide variety of events being collected, we need to find a way to make this more personal to the user. Otherwise, a billion irrelevant events will show up on their feed, and because of that they stop using the feature.

Possible suggestions could include the ability to swipe-delete an event from their main feed, some form of aggregating events, etc.

When sending an authenticated request to Platform's /accounts/me route, some people simply do not have any information regarding grade, major, etc. when it should have been loaded in upon their first login to a Penn Labs product.

For applications such as dining, laundry, and notifications, there are incomplete unit tests. Some things that we would like to do:

• Boost code coverage
• Refactor unit test code to make it more concise
• Add more comments to the methods to make the tests more understandable

We have just released the new menus fix! That said, we will need your help to document this function and all sub functions for us!
Try your best to start navigating code here!

Need to get this repopulated.

Sometimes, when working with UPenn's GSR API, the requests unexpectedly fail, and we don't account for that case. Ideally, we should catch the error and try again, and if it fails a second time, propagate the error upwards and return a useful response to our users.

For error handling, a lot of our views need try-excepted similar to: https://github.com/pennlabs/penn-mobile/pull/198/files/5e419b8b39050c0852ae941541f0e71be449356f, so that we can return the appropriate response.

To not have to re-write this code everywhere, a helper wrapper function/decorator could be useful.

Need to follow up with Charley from OpenData to get this resolved

Some of the methods we write can become quite large or confusing. Help clear up the confusion by writing Python docstrings for individual methods.

The type of docstring we want is called reST (examples). While reST is recommended by PEP 287, there are many other ways to do docstrings in Python. At the end of the day, we want consistent formatting, but if you believe there's a strong case to be made for using a different style than reST, we're happy to hear it!

An example method that would be quite useful to have a docstring for can be found here.

After some recent debugging with iOS and Android teams, we feel like storing 40x Errors and well as error messages are extremely useful in terms of uncovering bad behavior, since we do not store non 500 code paths

We seem to have a lot of repeated gsr = GSR.objects.filter...; if not gsr: in the codebase. It would be a good time to switch over to having a (possibly lambda?) function for this.

As we were in a rush to fix dining menus, we left out key error catching! Here is one example. Help us verify the date and make sure it is within range (if today is Monday, then we want the date to be no further than next Sunday).

Ideally should have an endpoint for enabling/disabling usage of your pennkey as well as endpoints for enabling/disabling notifications for a user on a group by group basis.

This information should also be returned whenever a user requests their groups (/users/salib/). Ideally, this should be formatted like the following so its easier to parse for us :)

    "username": "salib",
    "booking_groups": [
        {
            "name": "Penn Mobile Test",
            "id": 1,
            "color": "blue",
            "userSettings": {
                "pennKeyActive": {
                    "descr": "Sample Description",
                    "isEnabled": true
                },
                "notificationsOn": {
                    "descr": "Sample Description",
                    "isEnabled": false
                }
            }
        }
    ]
}