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:
Now if i want to use the helper function from the componenthelper 'getModel' i get an 'not authorised' error for public users
In this case editing access should be required for visibility access
Steps to reproduce the Bug
Create admin view
Link admin view to component and select Edit/Create Site View => 'Add+Menu'
Get the model for admin view
Use ->getItem() function while being a non logged in user.
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:

Now if i want to use the helper function from the componenthelper 'getModel' i get an 'not authorised' error for public users

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 happen if you remove access from the linked view? I mean when you like the view, to not check the access checkbox.
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.

This will remove the access control from the view and all places its linked.
With these settings the edit access check is still in the model
Model generated:
With these settings the edit access check is still in the model

Model generated:

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?
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...
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:
The Item service is requested from the container.
The database table is defined.
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.
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?
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?

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
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.
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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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:
Now if i want to use the helper function from the componenthelper 'getModel' i get an 'not authorised' error for public users
In this case editing access should be required for visibility access
Steps to reproduce the Bug
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 happen if you remove
accessfrom the linked view? I mean when you like the view, to not check the access checkbox.This will remove the access control from the view and all places its linked.
With these settings the edit access check is still in the model


Model generated:
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?
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...
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:
With this engine, you don't need to think about any of that.
The system uses the JCB-generated table metadata to determine:
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:
However, sometimes you need more freedom.
This new engine allows you to:
So instead of Joomla enforcing permission checks through the model layer, you decide when permissions apply.
For example:
This puts full control back into the developer's hands.
Automatic Data Handling
The engine automatically handles:
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:
You don't need to manually determine whether to run an
INSERTorUPDATE.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:
This approach makes it far easier to:
Architecture
The engine uses a factory-based container to provide access to services.
This means:
If you prefer, you can even:
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.
What happens here:
get()method retrieves the record whereid = $id.The returned value is already:
Example: Get Multiple Items
You can also retrieve multiple items in a single call.
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:
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.
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?

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
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.
So you in your IDE just add:
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.
Thank you for the info! I'll use the custom code replacements and go from there!