What are Locks:

Locks on entries could be implementend in many different ways. Usualy locking rows or tables on Database Managment Systems like SQL is not the best way for frontend applications. In the web world we have one database user that is connected to the database, but different users in the application. Like wordpress we created a locking system that locks entries when a user opens it – further we lock it per session, so you cant overwrite your a row with one modal in each other. You also get the information which user has locked the entry.

You can set the locktime in the global settings. Administrators could release locks in the WonderfulRelations dashboard.

User Initiated Entry Unlocking

User-Initiated Entry Unlocking

Overview: This documentation covers the implementation of a feature allowing users to unlock entries on their own. This is particularly relevant in environments where user roles require distinct levels of access and control over entries.

Implementation:

• User Group Assignment:

  • To enable user-initiated unlocking, the user must be assigned to a specific group.
  • This group should have a particular option enabled: allowed_to_force_unlock_entries.
  • This option should be set to true to activate the unlocking ability for members of the group.

• WordPress Admin Consideration:

  • For WordPress administrators to utilize this feature, they must also be assigned to a group with the allowed_to_force_unlock_entries option enabled.
  • This ensures uniform functionality across different user roles, including administrative ones.

Handling Wrapped Actions in EditAction

Context: In certain cases, the EditAction is nested within another action. For example, an action may first verify the existence of an invoice, create it if not present, and then proceed to EditAction.

Challenge:

• The nonce generated in the button payload is associated with the outer wrapped action, not the EditAction.
• However, the button is intended to trigger an EditAction, leading to a mismatch in nonce validation.

Solution:

• To address this, the nonce in the $_POST variable needs to be updated to reflect the EditAction.
• Implementation:
  • Modify the $_POST variable by replacing the existing nonce with one generated for the form_edit_entry action.
  • Use $_POST['data']['nonce'] = wp_create_nonce("form_edit_entry") to update the nonce.
  • This replacement ensures the nonce corresponds to the EditAction, allowing it to process securely and correctly.