[Core] Leave of Absence System

[mous13]

Right now, alot of communities that have an LOA status, have to run a set of manual actions in order to put someone on LOA or utilise google sheets to track LOAs. My proposed idea removes alot of the manual admin needed for LOAs.

Admins can configure an LOA form, similar to how we setup an enlistment form, then once a user submits an LOA form, it'll appear in the admin submissions page. An admin can then approve, hold, deny it. Once an admin approves it, they can go to a dedicated LOA tracking page that'll show:

• Upcoming LOAs
• Ongoing LOAs
• AWOLs

Once the LOA has been approved, if the LOA start date is not on that day, then once the LOA start date comes around, the system will automatically place the user on LOA, creating the appropriate records needed and send out notifications not only to the user but to the admin that approved the LOA.

On the front end in the operations center, we'll add a new tab for LOAs so people can see their past, present, and future LOAs, and have the ability to request an extension (modal with a new LOA form) and an early return (modal with a return form).

Once a user has submitted an extension or early return, the admin that is responsible for the original LOA would be notified and the form of course will be in the submissions page for them to action. If they request an extension or early return then it'll also display as a status in the LOA table.

The LOA entity would most likely contain the following fields:
start_date
end_date
user
text
actioned_by

You could also look at adding types to LOAs so admins can specify custom loa types (LOA, GenLOA, EduLOA, MilLOA) and the user can select the type that their LOA is.

If a user doesn't return when their LOA is up, a notification is sent to user and the appropriate admin and the user has x amount of time to return otherwise they go on AWOL. (This would be an automated assignment change for status, AWOL status/unit can be configured in configuration).

[jannes-io]

An admin can then approve, hold, deny it

Form statuses are also dynamic, so we'll need some kind of configuration to know if it was approved or denied.

send out notifications not only to the user but to the admin that approved the LOA.

1. For the user, they will already be informed by the assignment record (make sure to pass 'sendNotification' => true in the record payload)
2. For the admin, let's not bother them, they approved it and will have a table to see it, so they know about the upcoming LOAs.

On the front end in the operations center, we'll add a new tab for LOAs so people can see their past, present, and future LOAs.

We already have a submissions list, I doubt many users will have more than a handful of LOAs throughout their "career". So I think the current submissions list will suffice for this purpose.

I am however missing something for the "admins" to get a unit-wide overview of LOAs? I proposed it to be on the operations center, and maybe we can refactor the attendance sheet tab to be more of a "unit information" tab where you can then select attendance sheet or LOA table (and more in the future)

The LOA entity would most likely contain the following fields:
start_date
end_date
user
text
actioned_by

Can you elaborate what this entity would be used for? We have the "LOA form" and "LOA status" in settings, isn't it sufficient to query the submissions and/or users in LOA status?

You could also look at adding types to LOAs so admins can specify custom loa types (LOA, GenLOA, EduLOA, MilLOA) and the user can select the type that their LOA is.

Too unit specific. This can just be a field in the LOA form for units that want that distinction.

[mous13]

Form statuses are also dynamic, so we'll need some kind of configuration to know if it was approved or denied.

Similar to configuring what form will be the LOA form, we will have a setting to set loa approve status and loa deny status.

public const LOA_FORM = 'perscom.loa.form';
public const LOA_APPROVE = 'perscom.loa.approve';
public const LOA_DENY = 'perscom.loa.deny';

and save it using forumify platform's settingRepository

For the user, they will already be informed by the assignment record (make sure to pass 'sendNotification' => true in the record payload)
For the admin, let's not bother them, they approved it and will have a table to see it, so they know about the upcoming LOAs.

Tracking, so no need to setup any notifications as users already get notified in the record payload.

We already have a submissions list, I doubt many users will have more than a handful of LOAs throughout their "career". So I think the current submissions list will suffice for this purpose.

Will scrap the idea of an loa list.

I am however missing something for the "admins" to get a unit-wide overview of LOAs? I proposed it to be on the operations center, and maybe we can refactor the attendance sheet tab to be more of a "unit information" tab where you can then select attendance sheet or LOA table (and more in the future)

Change Attendance Sheet tab to "unit overview". In the tab panel have a drop down menu to switch between Attendance Sheet & LOAs, using live component to dynamically update the content without having to be routed/redirected.

Can you elaborate what this entity would be used for? We have the "LOA form" and "LOA status" in settings, isn't it sufficient to query the submissions and/or users in LOA status?

Initially thought a dedicated entity would simplify the data access and querying, but you're right. We can leverage the existing submission entity, we'd just have to first fetch the configured LOA form ID from settings then use that to query submissions.

Too unit specific. This can just be a field in the LOA form for units that want that distinction.

We can just scrap the idea of customisable statuses for LOA. If there's enough traction in the future from communities then we can look at it again.

IF in the future we do look at doing it, again using forumify platform's settingRepository to create an array of statuses for LOA. So in configuration, you can set multiple types of LOA statuses, then the LOA form can use a choiceType field for the user to select the type of LOA.