Hi,
I have a lookup field (which in another table is used as lookup only) - no problem.
Now I have a new table where I have defined it to show as radiobuttons - it has only two options: yes and no.
No users had any permissions on the table tbl_yes_no - as they do not need them.
This make the generated application show an error as the user needs to set a yes/no field - but, as he does not have permissions on the tbl_yes_no, he can not set the radio buttons (they are not even shown). Again: This problem did not occur, if I have a lookup to that table only.
Olaf
5.92: Lookup with Show as radio neeeds view access
5.92: Lookup with Show as radio neeeds view access
Some postings I was involved, you might find useful:
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
Re: 5.92: Lookup with Show as radio neeeds view access
Hi Olaf,
maybe I did not understand completely and I'm wondering if I have to check my applications:
My question is:
Does that error even occur if you grant "view" permissions on the lookup table for the user's group?
Or does it only occur if they do NOT have view-permissions?
Did I get it right that the same lookup works if you use (normal) "Drop down" instead of "Radio Buttons"?
Sorry for bothering you and thanks in advance for clarification!
maybe I did not understand completely and I'm wondering if I have to check my applications:
My question is:
Does that error even occur if you grant "view" permissions on the lookup table for the user's group?
Or does it only occur if they do NOT have view-permissions?
Did I get it right that the same lookup works if you use (normal) "Drop down" instead of "Radio Buttons"?
Sorry for bothering you and thanks in advance for clarification!
Kind regards,
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
AppGini 24.10 Revision 1579 + all AppGini Helper tools
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
[code]...[/code]
blocks for better readabilityAppGini 24.10 Revision 1579 + all AppGini Helper tools
Re: 5.92: Lookup with Show as radio neeeds view access
Hi Jan,
thanks for letting me know that I was not clear enough.
The error seems to occur ONLY when a user DOES NOT have ANY permissions on the lookup table tbl_yes_no.
Otherwise only the label is shown: (There should be the options Ja and Nein.
The error does NOT occur, when the user has VIEW (and only VIEW) permissions on table tbl_yes_no.
As this permission makes the table show up to the user, I would prefer not to give that permission (and let the user only choose from the field in another table).
Yes, it seems, that the dropdown lookup works even when the user does not have any permissions on the lookup_table. (both images have been created under the same username)
Maybe someone else can test and confirm this.
Olaf
thanks for letting me know that I was not clear enough.
The error seems to occur ONLY when a user DOES NOT have ANY permissions on the lookup table tbl_yes_no.
Otherwise only the label is shown: (There should be the options Ja and Nein.
The error does NOT occur, when the user has VIEW (and only VIEW) permissions on table tbl_yes_no.
As this permission makes the table show up to the user, I would prefer not to give that permission (and let the user only choose from the field in another table).
Yes, it seems, that the dropdown lookup works even when the user does not have any permissions on the lookup_table. (both images have been created under the same username)
Maybe someone else can test and confirm this.
Olaf
Some postings I was involved, you might find useful:
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
Re: 5.92: Lookup with Show as radio neeeds view access
I can confirm that this seems a bug as described by Olaf
Any help offered comes with the best of intentions. Use it at your own risk. In any case, please make a backup of your existing environment before applying any changes.
Re: 5.92: Lookup with Show as radio neeeds view access
Hmm ... to make sure I understand correctly: If the option 'Show as radio buttons' is checked for the lookup field, users aren't able to view the lookup options if they don't have access permissions to the parent table (expected behavior: they should be able to view the options as radio buttons) -- but if the lookup is a normal drop-down menu, options are listed in the menu as expected regardless of the parent table permissions. Did I get this right?
AppGini plugins to add more power to your apps:
- DataTalk is an innovative AppGini plugin based on ChatGPT that allows you to interact with your AppGini database using natural language questions, without writing any SQL. Check the demo video
- Mass Update plugin: Update multiple records at once and improve your workflow efficiency.
- Check our other plugins and get a generous discount of up to 30% when buying 2 or more plugins.
Re: 5.92: Lookup with Show as radio neeeds view access
correct
Any help offered comes with the best of intentions. Use it at your own risk. In any case, please make a backup of your existing environment before applying any changes.
Re: 5.92: Lookup with Show as radio neeeds view access
Hi,
yes, that's correct.
I do understand, that in my "special" case the the user can actually view the records in the lookup table (in lookup list or radio buttons). Thus it's somehow a view permission ... still unexpected. And: My table tbl_yes_no contains only two entries (yes and no) and I do not want the regular user who can choose from those two to see the table in any menu - but I as admin do want to have "easy access" to the table using the normal links in homepage and navbar.
Olaf
yes, that's correct.
I do understand, that in my "special" case the the user can actually view the records in the lookup table (in lookup list or radio buttons). Thus it's somehow a view permission ... still unexpected. And: My table tbl_yes_no contains only two entries (yes and no) and I do not want the regular user who can choose from those two to see the table in any menu - but I as admin do want to have "easy access" to the table using the normal links in homepage and navbar.
Olaf
Some postings I was involved, you might find useful:
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
Re: 5.92: Lookup with Show as radio neeeds view access
OK, thanks for reporting this Olaf. I'll check it and make a fix in the next release.
BTW, and this is not related to the above bug of course, having a separate table to store 'yes' and 'no' slows things down compared to using an options list. I know this might be just an example to clarify the bug, but just wanted to point to this as a possible performance improvement in this app.
BTW, and this is not related to the above bug of course, having a separate table to store 'yes' and 'no' slows things down compared to using an options list. I know this might be just an example to clarify the bug, but just wanted to point to this as a possible performance improvement in this app.
AppGini plugins to add more power to your apps:
- DataTalk is an innovative AppGini plugin based on ChatGPT that allows you to interact with your AppGini database using natural language questions, without writing any SQL. Check the demo video
- Mass Update plugin: Update multiple records at once and improve your workflow efficiency.
- Check our other plugins and get a generous discount of up to 30% when buying 2 or more plugins.
Re: 5.92: Lookup with Show as radio neeeds view access
Hi Ahmed,
thanks for pointing this out - but probably that's my database fetish
I did leave the path of normalization for general setting though ...
If would be nice, to have an options list but save different values to the database. Afaik this does not work at this time does it? Like: Show yes to the user, but save 1 to the database.
Olaf
thanks for pointing this out - but probably that's my database fetish
I did leave the path of normalization for general setting though ...
If would be nice, to have an options list but save different values to the database. Afaik this does not work at this time does it? Like: Show yes to the user, but save 1 to the database.
Olaf
Some postings I was involved, you might find useful:
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
Re: 5.92: Lookup with Show as radio neeeds view access
Just my 5 cents:
From my point of view you both have good reasons. Personally, I have also gotten into the habit of creating separate tables, sometimes even for yes/no.
For me this has several advantages:
My standard-lookup-table looks like this (just an example)
Table "document_types"
I am not using Radio Buttons at all but dropdowns for the reasons given above, especially because of usability- and memorability-reasons.
I avoid using option lists. I have often experienced that later rebuilding, for example because of options in a different language or additional options, is more complicated: you have to change it in AppGini, regenerate it, upload everything to the server, maybe adjust files. For me it is much easier to have a separate table for the values right from the start. So changing the values can be done in almost no time. And you can rely on primary keys (ID's) instead of string-comparison of option values especially when dealing with different languages.
From my point of view you both have good reasons. Personally, I have also gotten into the habit of creating separate tables, sometimes even for yes/no.
For me this has several advantages:
- Localization
You can simple replace "Ja" by "Yes" or "True" or whatever you like in any language you need - Additional Icons
You can add a column for an image or icon or html entity character (like these: ☑) which can be part of the dropdown text - Additional entries
It has happened to me that customers at first only needed a boolean ("yes/no"), but later on additional values. They then wanted for example "Active", "Inactive", "Discontinued", "Expired" or something else. In these cases it was always good if I had planned this as a dropdown from the beginning. - Sorting
Having an additional column like "position" you can even sort the dropdown entries by using the "Advanced" lookup options - Enabling
Having an additional column like "is_active" (or "enabled") you can even hide options later on using the "Advanced" lookup options
My standard-lookup-table looks like this (just an example)
Table "document_types"
- id (primary key)
- name (varchar[100], required, unique)
- description (text, textarea)
- is_active (integer, checkbox, default=1)
- position(integer, unique)
(optional) - image or icon (depends)
- background_color + text-color
for example for highlighting rows in table view - label
for example for showing as an indicator in table view like this I like using Bootstrap's .label class for such things:Code: Select all
<span class="label label-danger">TEXT</span>
I am not using Radio Buttons at all but dropdowns for the reasons given above, especially because of usability- and memorability-reasons.
I avoid using option lists. I have often experienced that later rebuilding, for example because of options in a different language or additional options, is more complicated: you have to change it in AppGini, regenerate it, upload everything to the server, maybe adjust files. For me it is much easier to have a separate table for the values right from the start. So changing the values can be done in almost no time. And you can rely on primary keys (ID's) instead of string-comparison of option values especially when dealing with different languages.
Kind regards,
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
AppGini 24.10 Revision 1579 + all AppGini Helper tools
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
[code]...[/code]
blocks for better readabilityAppGini 24.10 Revision 1579 + all AppGini Helper tools