Allow staff-api to ignore approval workflows for any given type of booking

[w-le]

In many scenarios, a booking workflow does not require an approval process.
In these cases, frontend apps will create (POST) the booking with .approved=true and that will persist.

HOWEVER, when a booking is EDITED (e.g. moved to a different resource or the start time changes), staff-api will always change .approved to false when processing the PUT:
https://github.com/PlaceOS/staff-api/blob/master/src/controllers/bookings.cr#L230

As a result, the app will show the booking as "Declined", which is not desirable in scenarios where there is no approval process (that is most scenarios).

There should be a staff-api configuration flag (perhaps set in PlaceOS Domain.internals or in staff-api.tenant that defines whether the staff-api expects certain bookings (e.g. of type 'desk' or type 'room') to have an approval workflow or not.

The current default is that all Bookings have an approval workflow, but I believe a better default is that there is no approval workflow (because this is a more common scenario), and one can optionally be enabled with a setting like the above. Though if we implement in this way we would have to add to Release Notes that the new setting to enable approval needs to be added to any existing deployments (with approval workflows) that get upgraded.

When there is no approval workflow configured, then staff-api should not change the booking.approval value on edits.

[jeremyw24]

Clear approval flags vs setting to false in staff-api bookings controller.

[chillfox]

Looking at the code I think the app should only show a booking as "Declined" if "rejected" is true

[w-le]

ok I'll let @MrYuion and @stakach decide whether to implement this as a front or backend change

[stakach]

Yeah I agree, rejected == true indicates rejected
approved == false just means it hasn't been approved yet and might not require approval

[w-le]

I see it's closed but in the comments it's unclear what the outcome is -

• Is there no action to be taken now? (closed not an issue)
• or does it mean frontend changes will be made to address the issue in the OP? (moved to a gh issue in the placeos/user-interfaces repo)

[chillfox]

The front end should be updated to use both the rejected and approved fields to determine the state of a booking instead on only relying on the approved field.

I don't know if an issue has been created in placeos/user-interfaces.

[w-le]

ok good thing I asked then, cause there was an intended action for another team, but no replacement issue to track it, so the intended action would've been forever lost. fyi @jeremyw24 I've now created a new issue to replace this one.

[MrYuion]

Hmm... the frontend already uses both for determining the status of a booking.
https://github.com/PlaceOS/user-interfaces/blob/b333879d29258e21e4abd07e3f3492d779329f29/libs/bookings/src/lib/booking.class.ts#L130

[w-le]

ok there's disagreement so i'm re-opening until there's a clear agreed action/path to resolution/