Issue Summary

Currently, the Alert TinyID count resets after 99,999 (as per the documentation here). 

For large customers generating a lot of alerts each day, who use the tinyID of alerts in reporting, this can be troublesome 

Example:

End user got SMS notification for an alert like below:

The link embedded in the notification is redirecting to an alert with URL like "https://<<Cloud URL>>/jira/ops/alerts/61626" which is incorrect, since, the notification was generated for the alert "https://<<Cloud URL>>/jira/ops/alerts/27d13770-145f-43b3-8241-2dccd2a6f3c7-1707333052626". This happens because tinyIDs resets after 99999 and its being used later on for new alerts getting generated in the system.

Expected Results

End user should be redirected to the alert for which notification was sent.

It would be good to see this increased to 999,999 to prevent such scenarios as much as possible. It would be good to "Add Validation mechanism during redirection from the notification so that end users do not end up in wrong URLs". 

Actual Results

End user is redirected to the incorrect alert which contains "tinyID" in its URL since in the SMS notifications tinyID is embedded instead of the actual Alert GUID.

Workaround

Delete the alert with "tinyID" in its URL (If feasible) after which end user will be redirected to the correct Alert from the SMS notification.