FIXED Field permission: Edit YES but disabled doesn't work in V 12

E

Edwin

New member

Your current DaDaBIK version​

You are using DaDaBIK version 12.0-Aveto enterprise, installed on 08-05-2024 (installation code: 1828963427ddf2b161), the latest version of DaDaBIK is 12.0-Aveto released on 08-05-2024

You are running the latest release of DaDaBIK

In case you want to upgrade to a more powerful edition (from Pro to Enterprise/Platinum, from Enterprise to Platinum) please contact us.

System info​

PHP Version: 8.1.28

mysql version: 8.0.36-cll-lve

Web server: LiteSpeed

Client: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36

-----

If I set a field permission to YES but disabled I expect the field to be visible in the edit form but it cannot be edited.
But I do not get that result. The field becomes invisible if I set the checkbox to yes.

1716484022714.png

Field is not there:

1716484111348.png

If I set the checkbox to no, the field becomes visible but it can be edited (which is not wanted of course):

1716484256646.png

Maybe other people also have noticed this?
 
E

Edwin

New member
Additional information:

If you upgrade from an older version to V12.0-Aveto and you had already fields were the Edit Yes but disabled was set, it will behave correctly until you change the setting. After a change of this setting you are not able anymore to achieve the intended result.

If you create a new field you will encounter the problem directly.
 
eugenio

eugenio

Administrator
Staff member
I am working on the fix.

Here is a more detailed description of the bug:

- Fields set as "edit: yes but disabled" using a dadabik version < 12 appear in the new permissions manager as "edit: no", however, if you don't save the permissions, permissions still work as expected. If you save the permissions, "edit: yes but disabled" for the current table/group will permanently become "edit: no"
- For new applications or new permissions you set using V 12, even if you see in the permissions page "edit: yes but disabled", the DaDaBIK engine, in the application forms, will treat these fields as "edit: no"

Suggestions to fix the wrong permissions set by the new permissions manager:

Run this query (I assume $prefix_internal_table is dadabik_, as it is by default)

SELECT * FROM dadabik_permissions WHERE id_permission_type = 8 and value_permission = 2;

All the records (each one representing a group/field pair) you will see (if any) have a wrong value_permission, it should be 3. Fix them.

In addition to that, some fields that used to be "edit: yes but disabled" may be "edit: no" now so I suggest to check your permissions. If you have a backup, you can easily see all the permissions that were "edit: yes but disabled" running this query

SELECT * FROM dadabik_permissions WHERE id_permission_type = 8 and value_permission = 3;

For tables having "edit: yes but disabled", you shouldn't use the permissions manager and wait for the fix.

I plan to release a V 12.1 fixing this, the menu bug and some minor issues, in about a week.

Sorry for the inconvenience!
 
eugenio

eugenio

Administrator
Staff member
eugenio said:
- For new applications or new permissions you set using V 12, even if you see in the permissions page "edit: yes but disabled", the DaDaBIK engine, in the application forms, will treat these fields as "edit: no"
Click to expand...

"For new applications or new permissions you set using V 12": it doesn't actually matter if the application is new or old, this should be rephrased as:
For new "edit: yes but disabled" permissions you set using V 12....
 
You must log in or register to reply here.
Top