codeforpdx / dwellingly-db-do-not-use Goto Github PK

What elements of the API are still up in the air? (Aside from #2, obviously).

For example, are there endpoints that still need to be constructed? Is the current FIrebase function set that calls into Firestore extensible enough? Should we fish or cut bait?

Things we know will need to be created:

• Business logic
• Joins in data (right now we can get all users or all tenants, but there is no join of data to get all the tenants that belong to a particular property)
• Stretch goal: there was, at one point, the idea that we might have multiple organizations. What changes need to be made to the data structures to handle this?

Right now, there's an entire endpoint for each element in the API and a duplicate set of tables for the "archiving" feature.

Questions:

1. Does this functionality make sense? Couldn't "isArchive" be a boolean just as easily?
2. Could the entire archiving feature set get moved back to a later phase of the project?
3. What changes need to be made to the API?

Update the docs

Right now, if you have a copy of Postman, you can get any data from any of the API endpoints, regardless of whether or not you should access that data.

We need to lock down the API so that:

• Only authenticated, authorized users can request data
• Users only see the data they are authorized to see. For example, a property manager should not be able to request data on a tenant that does not live on one of their properties.