grozdanowski / booking-for-relief-backend Goto Github PK

We want to be able to log the last known location of terrain workers (if they opt-in to do so) - it doesn't need to be perfect, it doesn't need to record historic data - but it'll cut down significantly the amount of communication and miscommunication that happens in the field

As said in title. Idea is to have a predefined set of tags to offer from, so people can tag more precisely. Of course, there's still the option of putting in something else other than what's offered.

• We want to allow facebook login/signup for everybody
• People who are reporting cases don't need to be logged in with facebook, but we want to encourage them to do so through UI design
• Operators & admins - volunteers, terrain workers, dispatchers etc need to be facebook-logged in

For better visibility.

Ie

1. Install node like this
2. Using this ide import project like this
3. Start this database and create user and db with this username/pass
4. Run db migrations like this
5. You need to import these credentials here
6. Run tests, make sure they pass
7. Run dev server like this

At this point the person should be able to develop any part of the system without stupid config errors slowing them down

We already have services that need integrating

https://booking-for-relief.vercel.app/trazim-pomoc/2

No need to comment 🙂 we need to secure the backend

We should prevent the backend API to do anything the frontend API doesn't want the user to do, but given the timelines, at the very least:

1. we want to prevent privilege escalation - a JSON payload saying "editor should be super admin" shouldn't pass, or sending a different user_id of who initiated it shouldn't change the initiator i, in short:
   1. foreign keys should be protected
   2. roles should be protected
2. we want to have an audit logging mechanism - if we miss something and someone manages to change something someone shouldn't - we want to have a audit logging trail about it - ideally this would be something like Audited - that you plug in on all models and not worry to much about

BUG: Dodijeljivanje kao prođe, ali u biti ga ne dodijeli..

We need this audit trail for cooperation with law enforcement, we can store the client IP in the DB, but it would be good to have a richer data set in the logs so we can help police investigation with browser headers etc

When someone adds an issue, they need to leave their contact phone. However there's no way for us to check whether the number is actually functional or whether that is the actual number of the person that's adding the entry.

What are the possibilities for us here?

Open cases need to be commentable - maybe we have this already, I forgot?

We currently have enabled a search that searches by tags. Do we want to extend that to search by any string in an entry?

1. Handle "potres_app_metadata" field

When a new entry will be firstly entered in potres.app, the sync to potres2020 will insert/update this data there.

Since the backend is already handling sync from potres2020, to avoid data duplication, use the field potres_app_metadata from potres so handle these updates correctly.
Data in potres_app_metadata will be in JSON format:

{
  "model": "aid-collection|aid-request|transport|accommodation",
  "id": 12,
  "updated_at": "2021-01-05T15:14:55.694Z"
}

2. Store last updated timestamp / version from potres2020 in potres.app

To properly handle updates on entries in potres2020, which were originally created in potres.app, make sure to add an additional field which will keep track of the version of the potres2020 data. It could be called: potres2020_lasted_updated and there store the value of the field updated from the potres2020 json model.
Example:
https://potres2020.openit.hr/api/v3/posts/921
"updated":"2021-01-10T14:28:46+00:00"

To correctly apply changes from potres2020, make sure you apply them only if the new_sync_entry.updated > potres2020_lasted_updated.

Tags are assigned by logged in operators and visible on the index screen. Tags would be pre-defined on system level and expanded as necessary.

We want to be able to use this to ie filter all cases that need a carpenter - or for other purposes

😄 ❤️

Self explanatory. Helps in terrain for quick reference.

Currently, the location field is used for the address, at least on the frontend when a new post is created. But when data is coming from potres2020 webhook, location is used to store the title field value of the post in potres2020.

From the UI/UX perspective, we should maybe introduce a field title and then for all potres2020 synced posts (original_app_id != null) move the values from location to title. For the posts that were originally created in the app, we could take few words from the description field and put them in the title flowed by the dots (...)

Introducing the title field in the model, would make the UI more clear, since we would not have the biggest UI element the location, which often contains similar data... so there is no differentiation between posts on the potres.app UI.

Examples of a post synced from potres2020:
https://potres.app/trazim-pomoc/374
https://relief-app-backend.herokuapp.com/aid-requests/374
https://potres2020.openit.hr/api/v3/posts/970