Each endpoint is linked to the url in the docs, these links should be removed as they will not be usable after auth is added

Before launching officially, I need to take the time to setup stripe so that users have to pay to keep their accounts active. Please note, I have no intention of profiting from this project. I'm going to have a super low subscription cost, like $1/month, just to cover the fees of hosting the project. It may raise as the server cost raises due to popularity. If this catches on I would like to create an opencollective account for full transparency with my audience.

I want to use a service like stripe instead of a simple donate button because I do not believe the donation funding model. Users should pay for the service they utilize. However, I want to keep this as cost efficient as possible. I would like this to be so dirt cheap that there is no extra money, and users won't have to think twice about whether the service is worth it.

Add a method to POST fermentables to the API. Set with an is_approved flag.

#31

Description: #32
Depends on #20

The styles, yeast, yeast types, fermentables, fermentable types, hops, hop types all need an additional model built for them to store suggestions for each model.

For a yeast suggestion, the suggestion would consist of a foreign key to a new yeast object. This object contains all the values given by the user when they made their suggestion. It will also have a null-able foreign key to the yeast model, which will represent if the suggestion is replacing another yeast object. Then, we will need the yeast suggestion to have an indicator as to whether it was accepted/regected, and a foreign key to the user account and token used to submit the suggestion.

The fermentable model needs refactoring as pointed out by some brewers on reddit. We need to be able to track who makes the fermentable, what year the data is from, as well as some additional values regarding grain and potential sugars. If you know of values that this should have please include them here.

It might also be nice to have a notion of a 'product line' or something like that, so you can get all the grain from a specific manufacturer and see how it's values changed with each harvest year.

All models will need an is_active flag and an is_verified flag. All GET endpoints for data/ should have a corresponding POST where you can send suggestions. These should get created with is_approved set to 0.

A recipe should consist of a name, pre-boil volume, post-boil volume, efficiency, fermentables, hops, yeasts, adjuncts, and notes.
A sample recipe would look like:

{
  id: 0,
  name: "Recipe Name",
  style: "Ale",
  imperial_units: true,
  pre_boil_volume: 6,
  post_boil_volume: 5,
  efficiency: 0.70,
  fermentables: [],
  hops: [],
  yeasts: []
  adjuncts: [],
  notes: []
}

The yeast data model should be expanded to include any data potentially useful to a brewer. You should also be able to track 'product lines' of yeast and see how they vary over the year. Add to this issue any attributes you feel the yeast model should have.

#31

Description: #32
Depends on: #22

There are API endpoints in the brew_data module that have not been updated to accept the new TokenAuthentication mechanism defined in brewcenter_api/accounts/auth. To do this you'll have to import accounts and add accounts.auth.TokenAuthentication to the authentication classes for each class based view.

May just want to use django rest frameworks builtin docs but with enhanced views. Either way, this needs an index of all the endpoints, and an overview of the data structure, without giving away all the data.

Go through the code base and replace all imports referencing . with either accounts, brew_data, or brewcenter_api.

Description: #32
Depends on: #23

A new endpoint /waterprofiles should be made to return a list of water profiles in the system. Each water profile should consist of measurements for Ca+2, Mg+2, HCO3-1, Cl-1, Na+1, and SO4-2. This should be formatted as such:

[
  {
    name: "Dublin",
    ca: 1.11,
    mg: 1.11,
    hco3: 1.11,
    cl: 1.11,
    na: 1.11.
    so4: 1.11
  },
  ...
]

In the database these should also have an in_active and is_verified field

Description: #32
Depends on: #19

Depends on #31.

We need views where callers can POST suggested improvements for each model in the brew_data module.

Requirements:

• The endpoints should require JWT Auth OR TokenAuth as defined in the accounts module.
• Each endpoint should make a new entry in the corresponding table, as well as the corresponding suggestion table. E.g. if I post a new yeast suggestion, it should create a new yeast model which is inactive, and a new yeast_suggestion.
• New suggestions should be set to unapproved by default
• We'll also need an endpoint for an admin user to accept suggestions.

The hop model needs to be expanded to hold additional values and represent different harvest years. The hop manufacturers should also be tracked. There should probably be a notion of a "product line" as well so, for example, Citra can be tracked through harvest years. Please add to this issue any values you think the hops model should have.

#31

Description: #32
Depends on: #21

There should be an admin only panel which allows methods for accepting/rejecting user-suggested ingredients/data and allows the admin to create new data entries
Blocked by #2

It would be nice to return the first 3 results of all the brew_data endpoints if no authentication is used, just for testing and seeing the data structure.

#31

All the views we currently use need to be switched to use viewsets and the default router:
http://www.django-rest-framework.org/api-guide/viewsets/

Description: #32
Depends on: #24

#31

Description: #32
Depends on: 25

#31

I would like the api to have a single view that returns all the data in the api. Things should be separated logically by type, of course. The purpose of this endpoint is for applications calling this API to update their internal data.

BONUS POINTS: Implement a method of using query parameters such that you can request to be sent all the data in the api that was created after X date.