Investigate - Unable to provide extension on NR

[mengdong19]

Describe the bug in current situation
Please reference to ops ticket 3091.
https://github.com/bcgov-registries/ops-support/issues/3091
User have no option to renew or extend NR.
[Uploading... image.png]

Please investigate.

Link bug to the User Story

Impact of this bug
Describe the impact, i.e. what the impact is, and number of users impacted.

Chance of Occurring (high/medium/low/very low)

Pre Conditions: which Env, any pre-requesites or assumptions to execute steps?

Steps to Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Actual/ observed behavior/ results

Expected behavior
A clear and concise description of what you expected to happen. Use the gherking language.

Screenshots/ Visual Reference/ Source
If applicable, add screenshots to help explain your problem. You an use screengrab.

[eve-git]

It appears to be an NR expiration issue.

From the data, I could not find when the "expired" state updated. But the last_update time of the request record is at 2023-09-13 08:01:17.128023+00, which is next day of the OPS ticket time.

Here's a possible explanation: At that time, NR had not yet updated the status to 'Expired,' but the expiration time specified in the requests.expiration_date had been reached.

For further discussion: Is the renewal action available in this scenario?

[eve-git]

#18567 indicates that the NR expiration states are updated a day after the expiration date. Therefore, the issue may be resolved once #18567 is fixed.

[eve-git]

The current conditions for displaying the reapply button are as follows:

1. The NR state is in ('CONDITIONAL', 'APPROVED').
2. The expiry date is equal or less than 14 days from now.
3. The expiry date is after the current date.

Typically, when the expiry date is reached (condition #3 not satisfy), a batch job updates the NR state to 'Expired,' making condition #1 unsatisfied and preventing the reapply button from showing up.

The expiration process involves setting the NR state to 'Expired' and removing the name from Solr conflict names. However, if the state hasn't been updated to 'Expired' by the batch job upon reaching the expiry date, the names remain in the conflict name list, affecting names cannot be used in other requests. In this case, I believe it is acceptable to allow users to reapply. Therefore, it may be unnecessary to include condition #3 above.

[eve-git]

Testing the functionality of the REAPPLY button involves a series of checks to ensure its proper behavior under different circumstances:

Normal Case:
Confirm that the REAPPLY button appears when the NR (New Request) is in states 'APPROVED' or 'CONDITIONAL.' and the NR expiration date is within the next 14 days.

Transition to 'EXPIRED':
Ensure that the REAPPLY button is hidden once the NR transitions to the 'EXPIRED' state.

Special Case:
Trigger a scenario where the NR expiration_date is reached, but the state is not 'EXPIRED' (in case of day job issue). To mimic the scenario, consider adjusting the NR day job schedule to run at the end of the day (not midnight at 00:01 am). This adjustment allows a full day to test scenarios involving NRs expired on the day but the states do not updated to 'EXPIRED' yet.

[oanyahuru]

@eve-git the option to renew the NR is available. This NR expires tomorrow
Private Zenhub Image

[oanyahuru]

The option is no longer available now the ticket is expired