2427 internal users can transfer a facility or operation

[Sepehr-Sobhani]

ISSUE 1949
&&
ISSUE 2427

🗒️ NOTES:

• Added cas_analyst as the new user role
• Excluded all from backend error util if error was a generic backend error (We don't want to see All:<rest of the error> in the UI)
• Removed unused jsonSchema
• Fixed allowedRoles prop on dashboard tile links
• Updated some fixtures
• We still need to add the cronjob (Reg\Transfer Entity\Cronjob to apply transfers on effective dates #2040) to be able to transfer entities in the future

🧪 TEST:

• Log in as cas_analyst
• Click the Transfer link
• Click Make a Transfer button
• See transfer form

[BCerki]

I'm making some notes here, not finished testing yet so I might rescind them as I get further along.

Is the transfers dashboard meant to have another tile? (If it is I suggest separate card and PR)

This might just be a dev data thing, but I don't think I'm getting the full list of operations. Existing Operator 2 has lots of operations but I'm only getting Operation 7:

If I transfer something with a date in the past, I get a confirmation that says it's already been transferred, and then I see the transferred status in the table instead of complete. Is that correct?

[BCerki]

Made some comments, anything that has a w in it means I want to talk about it in the walkthrough

[BCerki]

At first I wasn't sure what this service is meant to do based on the name and return value. Are we trying to get the info for whomever the facility currently belongs to? If so, get_current_designated_operation might be clearer.

If I've understood the PR correctly (I made some notes in the docs), then I suggest adding a comment to explain why there's only going to be one record without an end_date

[BCerki]

Suggest adding what happens in the TransferEvent model at this point

[BCerki]

same as above

[BCerki]

Suggest adding something about how the models, statuses, and dates all interact throughout this process. That was the most confusing part for me. I'll type up how I ~think it works for looking at the code, feel free to use some of this in the docs if it's helpful.

When an internal user creates a transfer, it goes into the TransferEvent model with a status of TO_BE_TRANSFERRED and the effective date from the form. (Provided there aren't any existing transfers that it overlaps with.) If the effective date is in the past, the transfers is immediately processed and a record is created in the timeline table with a status of ACTIVE and an empty end date. If there was already a timeline record, that one gets an end date set and the status set to TRANSFERRED. The TransferEvent model then gets the status set to COMPLETE? (When would we ever use the TRANSFERRED status in this model?)

If the effective date is in the future, nothing happens to the timeline tables. Once the date passes, the chronjob adds to the timeline tables as described above.

As a result of all this, we can always trust that the record in the timeline table that doesn't have an end_date is the active one. (We never check or filter for ACTIVE status, but checking for a null end date is the same thing.)

[BCerki]

Could we pass the legal_name instead of the id? (Is that stored in the form state anywhere, or only in the schema?) Then we wouldn't need to additionally pass operators

[Sepehr-Sobhani]

We are not storing the legal_name here, we just store IDs, that is why we need to pass the whole operators down.

[Sepehr-Sobhani]

I'm making some notes here, not finished testing yet so I might rescind them as I get further along.

Is the transfers dashboard meant to have another tile? (If it is I suggest separate card and PR)

I'm not aware, so for now, I'm going to remove that sub-dashboard step because it doesn't make sense.

[BCerki]

This is great, Sepehr, thanks for including so much detail and the examples!

[BCerki]

thanks for the docs

[BCerki]

Great work on this!!