Right now, Wagtail comes with group permissions, to give users the access to certain pages. We would like to figure out a way for Sponsors to have access to certain admin pages (#9) but not all of them (user data).

Must investigate to see what's possible.

Related to #3.

We need a way to store information about bat houses to users. For right now, storing information about houses would be a good place to start. The UML diagram in Sprint 3 should indicate what should be stored.

Now that we have House, HouseInformation (HouseEnvironmentFeatures + HousePhysicalFeatures), and Observation all put in, plus a way to register over API, we need to now implement CRUD for those models. They always needed to be scoped to an authenticated user, and with the system in place, we can now test that.

Once this is in place, the view logic just needs to be made into JSON so that we can expose it for Flightplan, while the administrative side can just pull on the newest records for visualization and record keeping.

Since Wagtail utilizes Django, we need a way to register and authenticate over API (so they can access only their bat houses, for example).

This might be trickier than expected.

Instead of using drf-extra-fields, use django-rest-framework-gis.

This will come after #22 is implemented, because we only use Range for those. However, Range is finicky with how numbers are bounded, so once we don't use it, then we can use a package that has GIS specific serializers.

Instead of serializing the entire model on any particular view, we can have the default GET request for all resources and the default GET request for a specific instance (PK) have different views, to not have to retrieve / send a lot of data over the API.

The main premise behind this interface is that the survey questions asked can be collated into a CSV, along with the responses.

Each house should have a set of environment/physical questions, with their date too, grouped together in some form for later processing.

Currently, it does a relative path to the bat_image due to using ImageRenditionField. We can still use it, we just need to get the proper representation for the image using a HyperlinkedIdentityField (https://stackoverflow.com/questions/49527543/hyperlinkedidentityfield-requires-the-request-in-the-serializer-context)

We need a representation of the data we want to store in our database. This is where model creation comes in. It allows us to give attributes to models, so that we can have a consistent way to store and get data.

Relies on #3 being done.

Once all of the models are created, we need to be able to pull this information through a publicly accessible API. Docs point us to "Adding custom page fields" to achieve this.

Should be able to test this with an API client (at /api/v2/*) and show that it responds in kind. Tests would work well, here!

In case of errors, instead of logging to a file, we should integrate some sort of error tracking to catch the errors and report it someplace.

Sentry comes to mind.

Right now, it shows an Items Enum for fields that we specified are ArrayFields.

Ideally, we have a way to pass in either the Enum version, or the human-readable version when passing a request, while rendering that out to the API in the correct manner.

Documentation might point us in the right direction, but it expects an array.

Right now, there's a default set of information pulled into the admin CMS (Pages, Images, Documents). We would like to be able to pull in information from the bat houses (House, HouseInformation, Observations, Bat) and display it in such a way.

This might be a bigger undertaking than expected.

This should be a part of the bat house itself, and not a part of the physical features.

This requires some destruction of migrations, moving a variable, and making sure that it performs a-okay.

Related to #3.

There's actually a desire to tags which bats have been seen in a bat house. However, the old site did not have a way to have this tracked server side, while providing the information client side.

There is no current UML diagram for this, so reference the UI mockups to see what data might need to be stored. It's possible that certain characteristics (size, amount of pups) can be treated as strings, or even just a text body (based on how it's displayed in app.)

Related to #3, relies on #5.

Instead of storing all of the information given by the API in the House model, we can instead store it in a separate model. Since this should be a one-to-one relationship expressed by a foreign key, the House model should be put in first.

This should be in the Sprint 3 UML diagram.

Fixtures are very helpful to create test data that is loaded every time when you wish to reset the database.

Since we now have APIs, testing APIs would be easier with fixtures, to make sure that certain users cannot see certain data.

We have data currently working, but currently, it only checks if the user is authenticated. If so, it will show all the data for that endpoint.

This cannot be shown during MVP.

In order to leave a few breadcrumbs / thoughts behind design choices, we should include documentation to indicate a lot of the thought process behind why things were done.

Probably in a folder like docs/ that's compiled besides other documentation on API usage.

When using *RangeField in specific PostgreSQL fields, the bounds are always defined as [) (inclusive first number, exclusive last number). This can be changed in the database, but Django does not support changing those bounds.

So, when users enter in data in the administration panel, erroneous behavior can occur.

Say for example, a bat only has one pup per year. That would be entered in as 1 - 1 in the Wagtail interface. Stored in the database, that's [1, 1), which is an invalid range, and defaults to null for the value. This shouldn't be the case.

One solution would be to break it up into two separate fields (min/max_(size|pups)), and create a serializer that ties the two fields for the API, like

"pups": {
    "min": 1
    "max": 1
}

We'll use Wagtail as our administrative CMS + API for the "back-end" portion of our services.

Turns out, DRF tokens don't scale too well.

Looking for a better solution.

Right now, we have an assumption that the data / questions presented on the front-end will be relatively static.

But, it's possible that we would want to tweak questions, and the possible choices associated with such. The problem is, we would need to figure out how to dynamically resolve CHOICES and the respective field it should go into the HouseInformation table.

It's probably possible to version this based off of last updated, along with a slug to denote different versions, with an API to expose the most "recent" version.

On a high level, it looks like

api/
  survey/
    environment/
    bat-house/
    bat-presence/

Then, we can simply have the front-end:

1. retrieve new versions of the survey
2. notify to do said survey
3. cache old questions and keep the answers for offline

We gain the flexibility of modifying the questions at the downside of added complexity of the correct data field and choices linked properly.

Alternatively, we store JSON blobs and then somehow find a way to serialize them in the administrative interface and CSV that is exported.

https://docs.djangoproject.com/en/2.1/ref/contrib/gis/

Allows us to add location data to Houses. Requires PostGIS to be setup to an existing PostgreSQL database.

After #33 is put into place, we can set up a testing database to run our queries against to make sure that our API is tested properly.

Since we want to get the environment/physical features when we access a specific instance of a house (/api/v1/house/PK/), we need to serialize a subset of features for it.

Might be related to #35.

Related to #3, relies on #5.

Instead of having observations made on each bat house stored within the House model, we will split them off to another model. This allows us to easily retrieve from the API just the observations for a certain house.

Sprint 3 should have a UML diagram for it. But, not all fields are there. At minimum, we should keep track of when the observation was made (created).

We want to add some additional fields to keep track of, tied to each user.

• First name
• Last name
• Email
• Phone number (optional)
• Make username immutable

Currently, trying to access any view underneath the API (so /api/bat) redirects to the documents. That should not happen.