Update acl-access.md

[betweenbrain]

User description

Adds note about core.edit.own not inherently checking who created the item in question.

---

PR Type

Documentation

---

Description

• Clarifies that core.edit.own permission doesn't automatically verify item creator

• Provides example code combining permission check with created_by comparison

• Fixes trailing newline formatting in markdown file

---

Diagram Walkthrough

flowchart LR
  A["core.edit.own permission"] --> B["Does not check creator"]
  B --> C["Combine with created_by check"]
  C --> D["Example code provided"]

Loading

File Walkthrough

Relevant files

Documentation

acl-access.md Document core.edit.own permission verification requirements versioned_docs/version-6.0/general-concepts/acl/acl-access.md Adds explanatory note about core.edit.own permission limitations Includes practical code example showing how to verify user created the item Demonstrates combining permission authorization with created_by value comparison Fixes file formatting by adding proper newline at end of file +3/-1

---

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
⚪	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Documentation Only: The PR adds or modifies documentation without implementing or changing any runtime logging of critical actions, so audit trail compliance cannot be assessed from this diff alone. Referred Code It's important to note that the `core.edit.own` permission does not inherently check if the user created the item. This can be accomplished by combining checking this permission with the item's created_by value, such as with `$user->authorise('core.edit.own', 'com_example.item.' . $this->item->id) && $this->item->created_by == $user->id` However, note that Super Users should be able to see all items, regardless of the Access Level, so generally there's another check: ```php if ($user->authorise('core.admin')) { // this is a Super user – allow the user to view the item If the user doesn't have access to view an item, then you should consider how best to report the error. If the user is logged in you may wish to return an HTTP status 403 (Forbidden). If the user isn't logged in then you may wish to return a status 403, or you may wish to redirect the user to the login screen with a message to login in order to be able to view the item. You can find if a user is logged in or not by checking the guest property of the User object. For example, to return a 403 with a "not authorised" message if the user isn't logged in: if ($user->guest) { throw new \Exception(Text::_('JERROR_ALERTNOAUTHOR'), 403); } </details> > Learn more about managing compliance <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#configuration-options'>generic rules</a> or creating your own <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#custom-compliance'>custom rules</a> </details></td></tr> <tr><td><details> <summary><strong>Generic: Meaningful Naming and Self-Documenting Code</strong></summary><br> **Objective:** Ensure all identifiers clearly express their purpose and intent, making code <br>self-documenting<br> **Status:** <br><a href='https://github.com/joomla/Manual/pull/559/files#diff-047adcd684e0959ad81075a5b479560940de0427d63341b0c7186bf2237f536dR54-R71'><strong>Not Applicable</strong></a>: The PR only updates markdown text and inline example snippets; no production identifiers <br>are added or renamed, so naming compliance is not assessable from this diff.<br> <details open><summary>Referred Code</summary> ```markdown It's important to note that the `core.edit.own` permission does not inherently check if the user created the item. This can be accomplished by combining checking this permission with the item's created_by value, such as with `$user->authorise('core.edit.own', 'com_example.item.' . $this->item->id) && $this->item->created_by == $user->id` However, note that Super Users should be able to see all items, regardless of the Access Level, so generally there's another check: ```php if ($user->authorise('core.admin')) { // this is a Super user – allow the user to view the item If the user doesn't have access to view an item, then you should consider how best to report the error. If the user is logged in you may wish to return an HTTP status 403 (Forbidden). If the user isn't logged in then you may wish to return a status 403, or you may wish to redirect the user to the login screen with a message to login in order to be able to view the item. You can find if a user is logged in or not by checking the guest property of the User object. For example, to return a 403 with a "not authorised" message if the user isn't logged in: if ($user->guest) { throw new \Exception(Text::_('JERROR_ALERTNOAUTHOR'), 403); } </details> > Learn more about managing compliance <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#configuration-options'>generic rules</a> or creating your own <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#custom-compliance'>custom rules</a> </details></td></tr> <tr><td><details> <summary><strong>Generic: Robust Error Handling and Edge Case Management</strong></summary><br> **Objective:** Ensure comprehensive error handling that provides meaningful context and graceful <br>degradation<br> **Status:** <br><a href='https://github.com/joomla/Manual/pull/559/files#diff-047adcd684e0959ad81075a5b479560940de0427d63341b0c7186bf2237f536dR68-R71'><strong>Example Context</strong></a>: Changes are limited to documentation and a fenced code example; no application error <br>handling logic is introduced or modified in the codebase to evaluate robustness.<br> <details open><summary>Referred Code</summary> ```markdown if ($user->guest) { throw new \Exception(Text::_('JERROR_ALERTNOAUTHOR'), 403); } </details> > Learn more about managing compliance <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#configuration-options'>generic rules</a> or creating your own <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#custom-compliance'>custom rules</a> </details></td></tr> <tr><td><details> <summary><strong>Generic: Secure Logging Practices</strong></summary><br> **Objective:** To ensure logs are useful for debugging and auditing without exposing sensitive <br>information like PII, PHI, or cardholder data.<br> **Status:** <br><a href='https://github.com/joomla/Manual/pull/559/files#diff-047adcd684e0959ad81075a5b479560940de0427d63341b0c7186bf2237f536dR54-R71'><strong>Documentation Only</strong></a>: No logging code is added or modified; the documentation change does not provide evidence <br>regarding structured logging or sensitive data handling in logs.<br> <details open><summary>Referred Code</summary> ```markdown It's important to note that the `core.edit.own` permission does not inherently check if the user created the item. This can be accomplished by combining checking this permission with the item's created_by value, such as with `$user->authorise('core.edit.own', 'com_example.item.' . $this->item->id) && $this->item->created_by == $user->id` However, note that Super Users should be able to see all items, regardless of the Access Level, so generally there's another check: ```php if ($user->authorise('core.admin')) { // this is a Super user – allow the user to view the item If the user doesn't have access to view an item, then you should consider how best to report the error. If the user is logged in you may wish to return an HTTP status 403 (Forbidden). If the user isn't logged in then you may wish to return a status 403, or you may wish to redirect the user to the login screen with a message to login in order to be able to view the item. You can find if a user is logged in or not by checking the guest property of the User object. For example, to return a 403 with a "not authorised" message if the user isn't logged in: if ($user->guest) { throw new \Exception(Text::_('JERROR_ALERTNOAUTHOR'), 403); } </details> > Learn more about managing compliance <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#configuration-options'>generic rules</a> or creating your own <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#custom-compliance'>custom rules</a> </details></td></tr> <tr><td align="center" colspan="2"> <!-- placeholder --> <!-- /compliance --update_compliance=true --> </td></tr></tbody></table> <details><summary>Compliance status legend</summary> 🟢 - Fully Compliant<br> 🟡 - Partial Compliant<br> 🔴 - Not Compliant<br> ⚪ - Requires Further Human Verification<br> 🏷️ - Compliance label<br> </details>

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Correct misleading documentation about ownership checks Correct the documentation for core.edit.own as it is misleading. Joomla's ACL inherently checks for item ownership, making the suggested manual check against created_by redundant. versioned_docs/version-6.0/general-concepts/acl/acl-access.md [54] -It's important to note that the `core.edit.own` permission does not inherently check if the user created the item. This can be accomplished by combining checking this permission with the item's created_by value, such as with `$user->authorise('core.edit.own', 'com_example.item.' . $this->item->id) && $this->item->created_by == $user->id` +When checking for the `core.edit.own` permission, Joomla's access control system automatically verifies that the current user is the creator of the item. Therefore, an explicit check against the item's `created_by` field is not necessary. The check can be performed simply with: `$user->authorise('core.edit.own', 'com_example.item.' . $this->item->id)` Apply / Chat Suggestion importance[1-10]: 10 __ Why: The suggestion correctly identifies that the documentation being added in the PR is factually incorrect regarding how Joomla's core.edit.own permission works, preventing misleading information on a core security feature.	High
More