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
approved → create NEW ESR notification
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:
approved 23/11/2019 - 30/11/2019 --> NEW notification
draft 24/11/2019 - 30/11/2019 --> no notification (not sending WITHDRAWL notification)
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:
approved 23/11/2019 - 30/11/2019 --> NEW notification
draft 24/11/2019 - 30/11/2019 --> no notification
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.