fix: Apply correct DAOP after changing them (remove its caching) (DEV-1965)

[seakayone]

Pull Request Checklist

Task Description/Number

Issue Number: DEV-1965

Fix caching problem by removing the caching for all permissions including DAOP (default access object permissions).

When a resource is created, the permissions are added based on the default object access permissions. This information is read from cache.

When updating a default object access permission's knora-base:hasPermission through the API (https://docs.dasch.swiss/2023.03.01/DSP-API/03-endpoints/api-admin/permissions/#updating-a-permissions-scope), this updates the DB but doesn't invalidate the cache.

As a result, after updating the default object access permission, the stack has to be restarted, otherwise the old permissions will be used.

Basic Requirements

Please check if your PR fulfills the following requirements:

• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• fix: represents bug fixes
• refactor: represents production code refactoring
• feat: represents a new feature
• docs: documentation changes (no production code change)
• chore: maintenance tasks (no production code change)
• test: all about tests: adding, refactoring tests (no production code change)
• other... Please describe:

Does this PR introduce a breaking change?

• Yes
• No
• Maybe (not 100% sure => check with FE)

Does this PR change client-test-data?

• Yes (don't forget to update the JS-LIB team about the change)
• No

[linear]

DEV-1965 Updating Default Object Access Permissions doesn't invalidate cache.

When a resource is created, the permissions are added based on the default object access permissions. This information is read from cache.

When updating a default object access permission's knora-base:hasPermission through the API (https://docs.dasch.swiss/2023.03.01/DSP-API/03-endpoints/api-admin/permissions/#updating-a-permissions-scope), this updates the DB but doesn't invalidate the cache.

As a result, after updating the default object access permission, the stack has to be restarted, otherwise the old permissions will be used.

[codecov]

Codecov Report

Patch coverage: 88.46% and project coverage change: -68.78 ⚠️

Comparison is base (00b7070) 86.53% compared to head (ff56abd) 17.75%.

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #2551       +/-   ##
===========================================
- Coverage   86.53%   17.75%   -68.78%     
===========================================
  Files         262      262               
  Lines       28889    28871       -18     
===========================================
- Hits        25000     5127    -19873     
- Misses       3889    23744    +19855     

Impacted Files	Coverage Δ
...r/permissionsmessages/PermissionsMessagesADM.scala	26.36% <ø> (-60.35%)	⬇️
...rmissionsmessages/PermissionsMessagesUtilADM.scala	73.80% <ø> (-20.31%)	⬇️
...api/responders/admin/PermissionsResponderADM.scala	30.86% <88.00%> (-60.75%)	⬇️
...api/store/triplestore/api/TriplestoreService.scala	80.00% <100.00%> (-20.00%)	⬇️

... and 185 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[BalduinLandolt]

One cache down... Huzza!

[irinaschubert]

LGTM, I would change the title to something like "remove caching for default object access permissions", but I leave this up to you.

[irinaschubert]

It just came to my mind that the permissions cache could now maybe be removed from the API alltogether - or are there more usages of it? I refer to this location in the application.conf:

dsp-api/webapi/src/main/resources/application.conf

Line 376 in e730ba4

cache-name = "permissionsCache"

[seakayone]

It just came to my mind that the permissions cache could now maybe be removed from the API alltogether - or are there more usages of it? I refer to this location in the application.conf:

dsp-api/webapi/src/main/resources/application.conf

Line 376 in e730ba4

cache-name = "permissionsCache"

Thanks for the hint, I have removed it also from the conf file.

After that there are no more occurences of the String permissionsCache in the code.