[BUG]: Frontend Model requires editing permissions in getItem function #1295

Closed
opened 2026-03-11 12:07:24 +00:00 by SimonvanDoorne · 9 comments
Member

What Happened?

When Creating an admin view, and setting the edit/create site view to 'Add+Menu', the resulting model has some editing permission checks that stops non logged in users to access the items.
Screenshot from the model getItem function:
afbeelding.png
Now if i want to use the helper function from the componenthelper 'getModel' i get an 'not authorised' error for public users
afbeelding.png
In this case editing access should be required for visibility access

Steps to reproduce the Bug

  1. Create admin view
  2. Link admin view to component and select Edit/Create Site View => 'Add+Menu'
  3. Get the model for admin view
  4. Use ->getItem() function while being a non logged in user.
  5. Error shown 'Not authorised!'

Which Joomla version are you compiling in?

5.4.3

Which PHP version are you compiling in?

8.1

Which Joomla versions are you targeting?

5.4.3

Which PHP version are you targeting?

8.1

Which Web server is JCB running on?

Ubuntu

Which Relational Database is JCB running on?

MariaDB

Which OS is JCB running on?

Centos

Which JCB version are you using?

5.1.4 stable

Where in JCB did this issue occur?

Compilation of a component

On which browsers did you encounter the issue?

Firefox, Chrome

Additional Comments

No response

### What Happened? When Creating an admin view, and setting the edit/create site view to 'Add+Menu', the resulting model has some editing permission checks that stops non logged in users to access the items. Screenshot from the model getItem function: ![afbeelding.png](/attachments/86197a11-36ec-45af-9f29-dcbe1a913b33) Now if i want to use the helper function from the componenthelper 'getModel' i get an 'not authorised' error for public users ![afbeelding.png](/attachments/1631a9f8-de03-4d13-9c59-bfb9773c2ac0) In this case editing access should be required for visibility access ### Steps to reproduce the Bug 1) Create admin view 2) Link admin view to component and select Edit/Create Site View => 'Add+Menu' 3) Get the model for admin view 4) Use ->getItem() function while being a non logged in user. 5) Error shown 'Not authorised!' ### Which Joomla version are you compiling in? 5.4.3 ### Which PHP version are you compiling in? 8.1 ### Which Joomla versions are you targeting? 5.4.3 ### Which PHP version are you targeting? 8.1 ### Which Web server is JCB running on? Ubuntu ### Which Relational Database is JCB running on? MariaDB ### Which OS is JCB running on? Centos ### Which JCB version are you using? 5.1.4 stable ### Where in JCB did this issue occur? Compilation of a component ### On which browsers did you encounter the issue? Firefox, Chrome ### Additional Comments _No response_
SimonvanDoorne added the Bug label 2026-03-11 12:07:24 +00:00
Owner

What happen if you remove access from the linked view? I mean when you like the view, to not check the access checkbox.

image.png

This will remove the access control from the view and all places its linked.

What happen if you remove `access` from the linked view? I mean when you like the view, to not check the access checkbox. ![image.png](https://git.vdm.dev/attachments/7e2624a9-30d3-4bcc-8298-2e4bae4c9a14) This will remove the access control from the view and all places its linked.
Author
Member

With these settings the edit access check is still in the model
afbeelding.png
Model generated:
afbeelding.png

With these settings the edit access check is still in the model ![afbeelding.png](/attachments/9574f5bd-9ace-437d-a594-802a4d1956da) Model generated: ![afbeelding.png](/attachments/6b024c94-5a33-4b20-908e-7477bc0359eb)
Owner

That is not access check but basic edit check, and that will always need to be there... and if you want the public to access that form, then give them edit access.

That is how even articles work, or am I missing something here?

That is not access check but basic edit check, and that will always need to be there... and if you want the public to access that form, then give them edit access. That is how even articles work, or am I missing something here?
Owner

Hmm I see you just want to get the data... that is why we build the dynamicGet area, and we also now have the Data factory... I would rather use those, as it avoids opening the model to attack...

Hmm I see you just want to get the data... that is why we build the dynamicGet area, and we also now have the Data factory... I would rather use those, as it avoids opening the model to attack...
Owner

A New Data Access Engine in JCB

Recently we introduced a new data access engine in Joomla Component Builder (JCB) that makes working with database data much simpler and more flexible.

This engine allows you to retrieve and store data without worrying about how it is stored internally.

Normally when working with Joomla models or database queries you must remember details such as:

  • Whether the data is stored as JSON
  • Whether it is Base64 encoded
  • Whether fields require special decoding
  • Whether the structure needs additional processing

With this engine, you don't need to think about any of that.

The system uses the JCB-generated table metadata to determine:

  • the field datatype
  • how the data is stored
  • how it should be decoded
  • how it should be validated when saving

It then automatically prepares the data so that what you receive is ready to use in PHP.


Why This Exists

The Joomla model layer is powerful and still plays an important role in JCB. It provides:

  • structured MVC behavior
  • permission integration
  • Joomla-standard workflows

However, sometimes you need more freedom.

This new engine allows you to:

  • retrieve data anywhere in your code
  • bypass unnecessary model overhead
  • work with data quickly and safely
  • control permissions yourself instead of relying on the model

So instead of Joomla enforcing permission checks through the model layer, you decide when permissions apply.

For example:

if ($user->authorise('core.edit', 'com_example'))
{
    // fetch data
}

This puts full control back into the developer's hands.


Automatic Data Handling

The engine automatically handles:

  • JSON decoding
  • Base64 decoding
  • datatype validation
  • correct value formatting when saving

If you attempt to save an incorrect datatype (for example a string where an integer is required), the engine will throw an error immediately.

This helps prevent corrupt data from ever reaching the database.


Automatic Insert or Update

The engine also provides a simple set() workflow.

When saving data:

  • If the record exists → it updates
  • If the record does not exist → it creates a new record

You don't need to manually determine whether to run an INSERT or UPDATE.


Cross-Table Flexibility

For more advanced cases, the engine can also operate across multiple tables.

This is the same mechanism used in the demo component example where:

  • Subform data is stored in a separate relational table
  • Instead of being stored as a JSON blob

This approach makes it far easier to:

  • search
  • filter
  • join tables
  • scale large datasets

Architecture

The engine uses a factory-based container to provide access to services.

This means:

  • objects are reused instead of repeatedly instantiated
  • dependency injection remains clean
  • the system remains easy to extend

If you prefer, you can even:

  • create your own factory
  • implement your own classes
  • extend the interfaces provided

This keeps the system both stable and customizable.


Automatic Code Import in JCB

When you use these examples in your project:

JCB will automatically detect the Power classes being used and import all required code into your project.

Once imported, you can edit or extend them inside the JCB Powers area.


Example: Get a Single Item

This example retrieves a single record from a table.

// check the class details here:
// https://git.vdm.dev/joomla/super-powers/src/branch/master/src/9206082e-a3f7-472e-98b2-de90d06cbdcd

$item = Super___9d76b8dc_3883_4755_b11c_131d19ca8a53___Power::('Item')
	->table('#__other_component_table_name')
	->get($id, 'id'); // in other component

What happens here:

  1. The Item service is requested from the container.
  2. The database table is defined.
  3. The get() method retrieves the record where id = $id.

The returned value is already:

  • decoded
  • validated
  • properly structured

Example: Get Multiple Items

You can also retrieve multiple items in a single call.

// check the class details here:
// https://git.vdm.dev/joomla/super-powers/src/branch/master/src/21bca8a4-5b28-41c4-843e-8097f0ba7cca

$items = Super___9d76b8dc_3883_4755_b11c_131d19ca8a53___Power::('Items')
	->table('table_name')
	->get([$id], 'id'); // in current component

This retrieves a collection of records matching the provided IDs.

Again, the data returned is already normalized according to the JCB table definitions.


When Should You Use This?

This engine is ideal when you want:

  • fast and flexible data access
  • minimal boilerplate code
  • automatic datatype handling
  • complete control over permissions
  • simple insert/update behavior

For standard Joomla workflows the model layer still remains excellent, but when you need something lighter and more direct, this engine provides a powerful alternative.

# A New Data Access Engine in JCB Recently we introduced a new data access engine in **Joomla Component Builder (JCB)** that makes working with database data much simpler and more flexible. This engine allows you to **retrieve and store data without worrying about how it is stored internally**. Normally when working with Joomla models or database queries you must remember details such as: * Whether the data is stored as **JSON** * Whether it is **Base64 encoded** * Whether fields require **special decoding** * Whether the structure needs additional processing With this engine, you don't need to think about any of that. The system uses the **JCB-generated table metadata** to determine: * the field datatype * how the data is stored * how it should be decoded * how it should be validated when saving It then automatically prepares the data so that what you receive is **ready to use in PHP**. --- # Why This Exists The Joomla model layer is powerful and still plays an important role in JCB. It provides: * structured MVC behavior * permission integration * Joomla-standard workflows However, sometimes you need **more freedom**. This new engine allows you to: * retrieve data anywhere in your code * bypass unnecessary model overhead * work with data quickly and safely * control permissions yourself instead of relying on the model So instead of Joomla enforcing permission checks through the model layer, **you decide when permissions apply**. For example: ```php if ($user->authorise('core.edit', 'com_example')) { // fetch data } ``` This puts **full control back into the developer's hands**. --- # Automatic Data Handling The engine automatically handles: * JSON decoding * Base64 decoding * datatype validation * correct value formatting when saving If you attempt to save an incorrect datatype (for example a string where an integer is required), the engine will **throw an error immediately**. This helps prevent corrupt data from ever reaching the database. --- # Automatic Insert or Update The engine also provides a **simple `set()` workflow**. When saving data: * If the record exists → it **updates** * If the record does not exist → it **creates a new record** You don't need to manually determine whether to run an `INSERT` or `UPDATE`. --- # Cross-Table Flexibility For more advanced cases, the engine can also operate across multiple tables. This is the same mechanism used in the **demo component example** where: * Subform data is stored in a **separate relational table** * Instead of being stored as a JSON blob This approach makes it far easier to: * search * filter * join tables * scale large datasets --- # Architecture The engine uses a **factory-based container** to provide access to services. This means: * objects are reused instead of repeatedly instantiated * dependency injection remains clean * the system remains easy to extend If you prefer, you can even: * create your own factory * implement your own classes * extend the interfaces provided This keeps the system both **stable and customizable**. --- # Automatic Code Import in JCB When you use these examples in your project: JCB will automatically detect the **Power classes** being used and import all required code into your project. Once imported, you can edit or extend them inside the **JCB Powers area**. --- # Example: Get a Single Item This example retrieves a single record from a table. ```php // check the class details here: // https://git.vdm.dev/joomla/super-powers/src/branch/master/src/9206082e-a3f7-472e-98b2-de90d06cbdcd $item = Super___9d76b8dc_3883_4755_b11c_131d19ca8a53___Power::('Item') ->table('#__other_component_table_name') ->get($id, 'id'); // in other component ``` What happens here: 1. The **Item service** is requested from the container. 2. The database **table is defined**. 3. The `get()` method retrieves the record where `id = $id`. The returned value is already: * decoded * validated * properly structured --- # Example: Get Multiple Items You can also retrieve multiple items in a single call. ```php // check the class details here: // https://git.vdm.dev/joomla/super-powers/src/branch/master/src/21bca8a4-5b28-41c4-843e-8097f0ba7cca $items = Super___9d76b8dc_3883_4755_b11c_131d19ca8a53___Power::('Items') ->table('table_name') ->get([$id], 'id'); // in current component ``` This retrieves a **collection of records** matching the provided IDs. Again, the data returned is already normalized according to the **JCB table definitions**. --- # When Should You Use This? This engine is ideal when you want: * fast and flexible data access * minimal boilerplate code * automatic datatype handling * complete control over permissions * simple insert/update behavior For standard Joomla workflows the **model layer still remains excellent**, but when you need something lighter and more direct, this engine provides a powerful alternative.
Author
Member

Thank you for the explanation, however, i don't read anything about the php you can insert in the getItem method through the admin view tab 'php', do we have to reimplement that code using the Data factory, or does the Data Factory include this natively?
afbeelding.png

As a note, the Joomla core does not check for editing permissions in their getItem models. A couple of examples:
com_category -> CategoryModel
com_fields -> FieldModel
com_content -> ArticleModel
None of these check for editing permissions

Thank you for the explanation, however, i don't read anything about the php you can insert in the getItem method through the admin view tab 'php', do we have to reimplement that code using the Data factory, or does the Data Factory include this natively? ![afbeelding.png](/attachments/59a5615b-38b2-4d96-b9e3-2377b0c7cc99) As a note, the Joomla core does **not** check for editing permissions in their getItem models. A couple of examples: com_category -> CategoryModel com_fields -> FieldModel com_content -> ArticleModel None of these check for editing permissions
Owner

Okay, I see you have custom code in your model, and moving that is a pain.

The validation of access in the model, and not only in the controller is due to a security issue.

I get the point that this is annoying. Maybe use the replace custom code convention and remove it… that will be the easiest workaround for now.

We can’t at this time remove it. I will continue to keep an eye on this, and as soon as we can ensure no direct model access is possible via url we can look at removing this check.

Okay, I see you have custom code in your model, and moving that is a pain. The validation of access in the model, and not only in the controller is due to a security issue. I get the point that this is annoying. Maybe use the replace custom code convention and remove it… that will be the easiest workaround for now. We can’t at this time remove it. I will continue to keep an eye on this, and as soon as we can ensure no direct model access is possible via url we can look at removing this check.
Owner

So you in your IDE just add:

/***[REPLACE<>$$$$]***/
// code removed
/***[/REPLACE<>$$$$]***/

Around the code you want to remove, then compile once, and install and from there JCB will keep removing that part, until it changes (meaning we change JCB core in that area enough that it will impact your model in that area) and then you will get a notice, to have a look and either remove the code again or now use the changes we made... so it remains a final resort, but still useful and quick way, for when JCB is not doing things the way you would like it.

So you in your IDE just add: ``` /***[REPLACE<>$$$$]***/ // code removed /***[/REPLACE<>$$$$]***/ ``` Around the code you want to remove, then compile once, and install and from there JCB will keep removing that part, until it changes (meaning we change JCB core in that area enough that it will impact your model in that area) and then you will get a notice, to have a look and either remove the code again or now use the changes we made... so it remains a final resort, but still useful and quick way, for when JCB is not doing things the way you would like it.
Author
Member

Thank you for the info! I'll use the custom code replacements and go from there!

Thank you for the info! I'll use the custom code replacements and go from there!
Sign in to join this conversation.
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: joomla/Component-Builder#1295