feat: Implement Record Locking with Takeover Feature

[Infi-Knight]

• Linked issue added (e.g., Fixes #123)
• I have run bun run format to ensure code is properly formatted
• I have verified that bun run lint passes without errors
• If blog post was added:
  • Ensure images have been optimised
  • Update dates to reflect the actual publishing date when merged (file names, folder names, and frontmatter)

Summary
Implements concurrent editing protection for Strapi CMS by installing and configuring Record Locking plugin with takeover functionality. This prevents data loss when multiple users attempt to edit the same content simultaneously.

Features Added

• Record Locking: Only one user can edit a content entry at a time
• Takeover Feature: Allows users to forcefully take over editing from another user
• Real-time Updates: WebSocket-based live status updates across browser sessions
• Visual Indicators: Clear messaging showing who is currently editing content

How It Works

Normal Editing Flow

1. User A clicks "Edit" on any content entry
2. Record Locking plugin checks if content is locked
3. If unlocked, plugin creates lock for User A in database
4. WebSocket broadcasts lock event to all connected users
5. User A can now edit the content exclusively

Takeover Scenario

1. User B tries to edit content already locked by User A
2. Plugin displays warning: "This entry is being edited by [User A name]"

4. "Takeover" button appears next to warning
5. User B clicks takeover → lock transfers from User A to User B
6. User A receives notification that they lost edit access

8. Real-time WebSocket updates ensure both users see status change immediately

Changes Made
Core Implementation:

• Installed @notum-cz/strapi-plugin-record-locking v2.1.0
• Configured plugin with takeover button enabled (showTakeoverButton: true)
• Set WebSocket transport for real-time updates (transports: ['websocket'])
• Updated Content Security Policy to allow WebSocket connections (ws:, wss:)

Files Modified:

• cms/package.json - Added record-locking dependency
• cms/config/plugins.ts - Plugin configuration with takeover enabled
• cms/config/middlewares.ts - WebSocket support in CSP headers

Code Quality:

• Updated ESLint configuration
• Applied project-wide code formatting
• Regenerated TypeScript definitions

Testing Instructions

1. Setup: Create two admin accounts in Strapi admin panel
2. Session 1: Open browser with User 1, go to Content Manager
3. Session 2: Open incognito/private window with User 2, go to same page
4. Test Lock: User 1 edits any blog post → content becomes locked to them
5. Test Warning: User 2 tries to edit same post → sees lock warning with User 1's name
6. Test Takeover: User 2 clicks "Takeover" button → gains edit access, User 1 loses it
7. Verify Real-time: Both users see lock status change immediately without page refresh

[JonathanMatthey]

1. UX

Buttons are a little confusing, text, colors and position.

• firstly, what's the primary action ?
• what's a destructive action ?
• what is the button actually doing, does the text make sense ?
• Repetition of currently editing doesnt read well

here's some improvements, also clarifies exactly what take over means, and what will happen.

• Go back could be on the flush left of the modal, or left of primary, that's fine for now.

Also later, we could have a View read only version but for v1, lets always go for the simplest version, which is either take over, or go back.

also, remove the [ x ] top right, no point having 2 buttons that do the same thing...

2. second issue, on the current implementation, if i click OK, i go into the post, and everything seems normal, i can edit fields, and then the SAVE UPDATE button is active and i can click it, it even says post published even though it's not, so it didn't lock anything.

[JonathanMatthey]

issue 3:

Feature:
Visual Indicators: Clear messaging showing who is currently editing content

Where ?

we discussed having it clearly showing around the primary action of the page,

[Infi-Knight]

1. UX

Buttons are a little confusing, text, colors and position.

• firstly, what's the primary action ?
• what's a destructive action ?
• what is the button actually doing, does the text make sense ?
• Repetition of currently editing doesnt read well

here's some improvements, also clarifies exactly what take over means, and what will happen.

• Go back could be on the flush left of the modal, or left of primary, that's fine for now.

Also later, we could have a View read only version but for v1, lets always go for the simplest version, which is either take over, or go back.

also, remove the [ x ] top right, no point having 2 buttons that do the same thing...

2. second issue, on the current implementation, if i click OK, i go into the post, and everything seems normal, i can edit fields, and then the SAVE UPDATE button is active and i can click it, it even says post published even though it's not, so it didn't lock anything.

yeah UI/UX is the default from plugin, can be improved. I will look into the ok button behavior

[JonathanMatthey]

ok, great for demo - thank you !

here's demo doc https://docs.google.com/document/d/1_kWEgyEce8rxAiWCUeeMtq6PlJ06Lh7lItaF5trC_zw/edit?tab=t.0