Placement Approval

Permission to approve a placement:

More explanations about the permission, see this link: https://hee-tis.atlassian.net/wiki/spaces/NTCS/pages/1379172363/Placement%2BPlanning%2BTool%2BPPT%2BWhere%2Bwe%2Bare%2Band%2Bwhat%2Bstill%2Bneed%2Bto%2Bbe%2Bdone.#Permissions%3A

TPD: user who doesn’t have approval permission

• create draft

• update draft → draft

approved → draft

Admin: user who has approval permission

• create draft

• update draft → draft

draft → approved → create NEW ESR notification

approved → draft

approved → approved → create DateChange ESR notification

Bulk upload User:

• create approved

• update approved → approved → create DateChange ESR notification

draft → approved → create NEW ESR notification

Dealing with EsrNotifications when adding approval process:

see the red part above.

Notification Types:

more notification types definition, see this link: https://hee-tis.atlassian.net/wiki/spaces/NTCS/pages/1611464734/Notifications#Notification-Types

New notification (type code = 1)

Datechange notification (type code = 1 & 4)

Why PlacementLog table:

A field LifecycleState was added to the Placement table to record if the current placement is a draft or is approved. Think about the 2 scenarios below:

Scenario 1:

1. approved 23/11/2019 - 30/11/2019  --> NEW notification

2. draft         24/11/2019 - 30/11/2019  --> no notification (not sending WITHDRAWL notification)

3. approved 24/11/2019 - 30/11/2019  --> NEW notification (but it should create a dateChange notification)

The first time when the placement is approved, it will create a NEW notification, and then, when it’s converted to a draft and the dateFrom field is modified, it won’t create any notification. But when it’s approved again, because we can only get the current state draft from the placement table, we don’t know if this placement has once been approved before, it will be treated as 'draft → approved', so a NEW Esr notification would be created. But actually, we need a dateChange notification here.

Scenario 2:

1. approved 23/11/2019 - 30/11/2019  --> NEW notification

2. draft         24/11/2019 - 30/11/2019  --> no notification

3. approved 23/11/2019 - 30/11/2019  --> NEW notification (but it shouldn't create any notification)

The first time when the placement is approved, it will create a NEW notification, and then, when it’s converted to a draft and the dateFrom field is modified, it won’t create any notification. But when it’s approved again with the dateFrom changed back, it will be treated as ‘draft → approved', so a NEW Esr notification would be created. But actually, we do NOT need this notification, because it has been already created before.

According to the scenarios analyzed above, we do need the history of placement changes. That’s why we created a PlacementLog table to save them.