SLAs with "Comment: for customers" condition wrongly recalculated and corrupted

Issue Summary

The changes added for https://jira.atlassian.com/browse/JRASERVER-70137 in Jira changed the way we check for visible comments for our users, and since JSD has a new type of user ("Customer") those changes affected us since "Customer" type users do not have BROWSE_PROJECTS permission (and should not have).

This bug causes all recalculations of SLAs with the "Comment: for customers" condition to be wrongly recalculated and corrupted, explaining what we are seeing in this ticket.

Steps to Reproduce

1. Create a new project in an empty JSD
2. Create a new SLA configuration like this: Start: Issue created, Pause: Status: Waiting for Customer, Stop: Comment: for customer
3. Create a new customer user using self sign-up
4. Use that customer to open a ticket through the customer portal
5. As an agent, go to the ticket and add a public comment. The SLA will be correctly stopped and complete.
6. Now, to break the SLA: delete the SLA values for the issue using the following SQL:

   delete
   from customfieldvalue
   where issue in (
       select id as issue_id
       from jiraissue
       where project = (
           select id as project_id
           from project
           where pkey = '{PROJECT_KEY}' -- project key
       )
         and issuenum = {ISSUE_NUMBER} -- issue number
   )
     and customfield in (
       select id as sla_custom_field_id
       from customfield
       where customfieldtypekey = 'com.atlassian.servicedesk:sd-sla-field' --sla field type key
   );
   

7. Now execute a call like below to Jira's REST to clear the cache (replace the auth strategy with whatever makes sense):

   curl --location --request DELETE 'http://localhost:2990/jira/rest/internal/1.0/cache/app' \
        --header 'Authorization: Basic {BASE64_AUTH_STRING}' 

8. Call the reconstruct API on the issue (we might need to enable the sd.sla.fix.timeline feature flag here (again, replace the auth strategy with whatever makes sense):

   curl --location --request POST 'http://localhost:2990/jira/rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct' \
        --header 'Authorization: Basic {BASE64_AUTH_STRING}' \
        --header 'Content-Type: application/json' \
        --data-raw '["{ISSUE_KEY}"]'

Expected Results

The SLA should be in a correct state after calling the full reconstruction API.

Actual Results

SLA is now in a broken state. For example, SLAs that should have been paused / stopped are still running

Workaround

Workaround for a specific issue in 3.16.x

1. Add Browser projects permission to the Reporter role (accessing a URL like this: http://localhost:2990/jira/secure/admin/EditPermissions!default.jspa?schemeId=10000)
2. Find an issue in a broken state (aka: with a Comment: for customer stop condition that should’ve been triggered but isn’t)
3. Run the reconstruction for the affected issue via REST API, like so (remember to change the authorisation strategy to something that makes sense for the instance):

   curl --location --request POST 'http://localhost:2990/jira/rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct' \
        --header 'Authorization: Basic {BASE64_AUTH_STRING}' \
        --header 'Content-Type: application/json' \
        --data-raw '["{ISSUE_KEY}"]'

4. SLA is now fixed
5. After fixing the issues needed, we can remove the permission we added in step 1.

Workaround for a specific issue in 4.5.x

1. Add Browser projects permission to the Reporter role (accessing a URL like this: http://localhost:2990/jira/secure/admin/EditPermissions!default.jspa?schemeId=10000)
2. Find an issue in a broken state (aka: with a Comment: for customer stop condition that should’ve been triggered but isn’t)
3. Delete all the SLA information for it in the database with a SQL query like this:

   delete
   from customfieldvalue
   where issue in (
       select id as issue_id
       from jiraissue
       where project = (
           select id as project_id
           from project
           where pkey = '{PROJECT_KEY}' -- project key
       )
         and issuenum = {ISSUE_NUMBER} -- issue number
   )
     and customfield in (
       select id as sla_custom_field_id
       from customfield
       where customfieldtypekey = 'com.atlassian.servicedesk:sd-sla-field' --sla field type key
   );

4. Run the following call to clear Jira’s cache (remember to change the authorisation strategy to something that makes sense for the instance):

   curl --location \
        --request DELETE 'http://localhost:2990/jira/rest/internal/1.0/cache/app' \
        --header 'Authorization: Basic {BASE64_AUTH_STRING}'

5. Enable the sd.sla.fix.timeline feature-flag, if it's not already enabled
6. Run the reconstruction for the affected issue via REST API, like so (remember to change the authorisation strategy to something that makes sense for the instance):

   curl --location --request POST 'http://localhost:2990/jira/rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct' \
        --header 'Authorization: Basic {BASE64_AUTH_STRING}' \
        --header 'Content-Type: application/json' \
        --data-raw '["{ISSUE_KEY}"]'

7. SLA is now fixed
8. After fixing the issues needed, we can remove the permission we added in step 1.

Workaround for a specific issue in 4.9.0

1. Add Browser projects permission to the Reporter role (accessing a URL like this: http://localhost:2990/jira/secure/admin/EditPermissions!default.jspa?schemeId=10000)
2. Find an issue in a broken state
3. Enable the sd.sla.fix.timeline feature-flag, if it's not already enabled
4. Run the reconstruction with force via REST API, like so (remember to change the authorisation strategy to something that makes sense for the instance):

   curl --location --request POST 'http://localhost:2990/jira/rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct/force' \
        --header 'Authorization: Basic {BASE64_AUTH_STRING}' \
        --header 'Content-Type: application/json' \
        --data-raw '["{ISSUE_KEY}"]'

5. SLA is now fixed
6. After fixing the issues needed, we can remove the permission we added in step 1