[Migration] Introduction of the System Template

Describe the issue: With the introduction of the System Templates with https://github.com/wso2/product-is/issues/20996, there is a minor behavior change in the API.

Quoting the design document, There is a minimal impact where when we try to delete a system template it won’t get deleted but instead it will get reverted back to the default state.

Having the ability to delete system default template, leads to failures in the scenarios that needs these templates, so not giving the ability to delete these templates considered as a bug fix, that avoid having the user to lead such errors in the runtime..

However, this change must be noted in the migration guide.

How to reproduce: Delete a email templates that is available in the default pack (in a fresh tenant). In earlier version delete operation completely delete the template. If the same template try to retrieve after the delete, it is returning 404..

But with 7.1.0 deleting the template, doesn't lead to delete the resource completely, rather its reset the content to default (if there are any changes has been made).. And if the same template try to retrieve after the delete request, its returning the template with default content (rather returning a 404).

Expected behavior: N/A

Due to the introduction of system email templates, a behavior change can be ocurred in email sending for account locking an unlocking scenario due to the code logic as follows:

https://github.com/wso2-extensions/identity-event-handler-account-lock/blob/71a72cab5555445f5a15ac49165a8990f1850219/components/org.wso2.carbon.identity.handler.event.account.lock/src/main/java/org/wso2/carbon/identity/handler/event/account/lock/AccountLockHandler.java#L733-L747

This code was introduced with https://github.com/wso2-extensions/identity-event-handler-account-lock/pull/58

 String emailTemplateTypeAccUnlocked = AccountConstants.EMAIL_TEMPLATE_TYPE_ACC_UNLOCKED;
                if (notificationInternallyManage) {
                    if (isAdminInitiated) {
                        if (AccountUtil
                                .isTemplateExists(AccountConstants.EMAIL_TEMPLATE_TYPE_ACC_UNLOCKED_ADMIN_TRIGGERED,
                                        tenantDomain)) {
                            emailTemplateTypeAccUnlocked =
                                    AccountConstants.EMAIL_TEMPLATE_TYPE_ACC_UNLOCKED_ADMIN_TRIGGERED;
                        }
                    } else {
                        if (AccountUtil.isTemplateExists(AccountConstants.EMAIL_TEMPLATE_TYPE_ACC_UNLOCKED_TIME_BASED,
                                tenantDomain)) {
                            emailTemplateTypeAccUnlocked = AccountConstants.EMAIL_TEMPLATE_TYPE_ACC_UNLOCKED_TIME_BASED;
                        }
                    }

Possible behavior changes:

If the earlier IS tenants didn't have accountUnlockTimeBased/ accountUnlockAdmin email templates, the endusers have recieved accountUnlock template for both cases of unlocking user account by unlock time passing and admin unlocking the user cases. With new system email template support accountUnlockTimeBased and accountUnlockAdmin will be available for that tenant and email triggering will pick the specific scenario based unlock template. If the accountUnlock has been customized, there is a behavior change
Similar pattern exists in account lock scenario https://github.com/wso2-extensions/identity-event-handler-account-lock/blob/71a72cab5555445f5a15ac49165a8990f1850219/components/org.wso2.carbon.identity.handler.event.account.lock/src/main/java/org/wso2/carbon/identity/handler/event/account/lock/AccountLockHandler.java#L795-L804

There can be similar cases available for different email templates

wso2 / product-is

[Migration] Introduction of the System Template #21304