## Original issues on JIRA:
- Initial: CUS-43 "Add notification possibility for motion sensors"
- Added: CUS-92 "Add admin panel switch to turn on/off motion sensor notification"

## What's not clear from these issues:
- Scope: only web-api support / push-notifications or Seintjes or both / On- and Offline-detection or not / finished app-frontend or not / finished native app or not
- HIK or SB motion sensor; also is the other immediately deprecated or not? (solved by a quick question of course but this is a very impactful point so should definitely be in the issue description)
- Behaviour of motion sensor (what exactly does it send when / when exactly should a notification be triggered)

-> When and where to decide / split up in the case of larger-issues-but-not-quite-epics? Would prefer to discuss before the issue goes to planned as these choices can highly impact expectations & time consumption

## In-hindsight-preferred-issues, in order:
1. Determine the above missing info / create and verify the below issues based on that
2. Add admin panel switch to turn on/off motion sensor notification (0-impact DB migration, feature flag testable)
3. Implement processing of motion sensor GeneralMessages including updating SP-sim / adding unit-tests, but no consequences for app-backend/app-frontend/phones unless feature-flag is set
4. Implement app-backend & app-frontend-parts

Follow-up issues (already added to Jira):
- Implement on/offline-detection for motion sensors
- Implement motion detection push-notifications & seintjes in Native app

# Idea for general feature issue/MR approach
### Every point should be a JIRA issue with seperate MR, if applicable:
- Design & implement persistent data support for {feature}
Data support: new data structure(s) per database (i.e., new state-collection in Redis, new columns in Postgres, new record types in Influx).
Forces to deliberately think about storage location / data structure
- Migrations can include new tables/fields/any data migration into the newly created structures, no cleanup of any kind
- Should include all new data structure-related typescript types
- Can include interfaces in internal tooling (admin-panel/grafana/temporary console logging) to allow testing on staging/prod
- Should always run `yarn update-types` in `shared/lib` before making MR

- Design & implement any base code structure changes/refactoring needed for {feature}

- Design & implement actual web-api processing for {feature}
- If this results in *any* new output towards app-backend (evented data) or phones (notifications), make sure there's a feature flag that fully disables the feature unless enabled
- Should include SP-sim support for any new GM's for testability
- Should include unit-tests
- Can include temporary console logging if wanted for testing

- Verify up until production that everything is working as expected

- Design & implement client-facing parts (probably good to split into seperate issues)
- Changes to app-backend (evented/live-data/new endpoints/...)
- Changes to app-frontend
- Changes to native app

- Add cleanup migration

# My main question marks with this approach:
- In my experience, especially the bigger issues are not usually well-defined enough in advance where you can oversee all implications, and even if they are, it is still easy to overlook something (more so when sticking to the above steps). Worst-case this means finding out an assumption on the data-structure turns out to be invalid at the point where the first version of the front-end ends up on develop. From this point there's 2 options:
- Preferred but time-consuming: start again from step 1, making all needed changes in the correct order
- Not preferred but a lot quicker: duct-taping around the problem

This is mostly solved by always starting with a simple-as-possible PoC as final deliverable (at the very least the impact is minimized)

- For bigger issues, because you have to think of in advance & keep track of a lot of code parts during programming (DB/web-api processing/app-backend propagation/user interface), context switching is especially expensive. As such I prefer to do issues like this in one go. The main consequence is that if you make a MR & it is not immediately reviewed, you can really only branch off of your first MR's branch, but if the review results in a lot of changes, this results in extra work getting the following branches up to date. Alternatively, waiting for review comes at the cost of context-switching.