fix: set files_locked to .locked rather than permission

[carlinmack]

❤️ Thank you for your contribution!

Description

Please describe briefly your pull request.

• currently the permission is whether you can unlock the files
• but the files are only unlocked when you create the draft
• as such as an admin when you edit a published draft, if it was created by a user it will look like the files are unlocked but this is false

this PR correctly sets files_locked to whether the files are locked

Checklist

Ticks in all boxes and 🟢 on all GitHub actions status checks are required to merge:

• I'm aware of the code of conduct.
• I've created logical separate commits and followed the commit message format.
• I've added relevant test cases.
• I've added relevant documentation.
• I've marked translation strings.
• I've identified the copyright holder(s) and updated copyright headers for touched files (>15 lines contributions).
• I've NOT included third-party code (copy/pasted source code or new dependencies).
  • If you have added third-party code (copy/pasted or new dependencies), please reach out to an architect on Discord.

Frontend

• I've followed the CSS/JS and React guidelines.
• I've followed the web accessibility guidelines.
• I've followed the user interface guidelines.

Reminder

By using GitHub, you have already agreed to the GitHub’s Terms of Service including that:

1. You license your contribution under the same terms as the current repository’s license.
2. You agree that you have the right to license your contribution under the current repository’s license.

[ntarocco]

We cannot easily remove this feature, first because it is a breaking change, and also because we rely on it.

[carlinmack]

We also use it on Zenodo like that. We incorrectly pass the permission to the UI here. @slint can maybe elaborate or you two can talk :)

[slint]

After a discussion IRL, summarized here:

Right now when admins edit a published record, we "accidentally" also unlock the file bucket (based on our config). This gives record owners technically the ability to modify the draft files, but it's hidden by UI bugs so nobody notices. This PR fixes how the UI reflects the bucket state for the file modification feature, and this is going to become obvious and cause problems.

We decided that admins should instead have to explicitly unlock buckets using the same file modification request flow as regular users. This means clicking "Edit" won't automatically unlock files anymore. If an admin needs to unlock files, they use the request button, which:

A. is an explicit action.
B. creates an audit trail and makes it clear what happened and by who

This way, we avoid accidentally unlocking buckets when admins are just checking/fixing draft metadata, and we have a proper trace of who unlocked what and when. If an admin forgets to re-lock, that's on them - but at least there's a trace of it.

Before deploying this fix, it's worth checking in our instances if there are published records with a draft in progress that have unlocked files. This has to be an SQL query though, since we're not indexing the bucket lock state in OpenSearch:

-- Count of unlocked draft buckets
SELECT COUNT(*) as unlocked_draft_buckets
FROM rdm_records_metadata r
INNER JOIN rdm_drafts_metadata d ON r.id = d.id
INNER JOIN files_bucket b ON d.bucket_id = b.id
WHERE b.locked = false
  AND r.deletion_status != 'D';

-- Unlocked draft buckets details
SELECT 
  r.id as record_id,
  r.updated as record_last_updated,
  r.deletion_status,
  d.bucket_id as draft_bucket_id,
  d.updated as draft_last_updated,
  d.expires_at as draft_expires_at,
  b.locked as bucket_locked,
  b.size as bucket_size,
  b.updated as bucket_last_updated
FROM rdm_records_metadata r
INNER JOIN rdm_drafts_metadata d ON r.id = d.id
INNER JOIN files_bucket b ON d.bucket_id = b.id
WHERE b.locked = false
  AND r.deletion_status != 'D'
ORDER BY r.updated DESC;