5.92: Lookup with Show as radio neeeds view access

Please report bugs and any annoyances here. Kindly include all possible details: steps to reproduce, expected result, actual result, screenshots, ... etc.
Post Reply
User avatar
onoehring
AppGini Super Hero
AppGini Super Hero
Posts: 1156
Joined: 2019-05-21 22:42
Location: Germany
Contact:

5.92: Lookup with Show as radio neeeds view access

Post by onoehring » 2020-11-13 08:41

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.
yn.png
yn.png (6.76 KiB) Viewed 3166 times
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

User avatar
jsetzer
AppGini Super Hero
AppGini Super Hero
Posts: 1807
Joined: 2018-07-06 06:03
Location: Kiel, Germany
Contact:

Re: 5.92: Lookup with Show as radio neeeds view access

Post by jsetzer » 2020-11-13 08:52

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!
Kind regards,
<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 readability

AppGini 24.10 Revision 1579 + all AppGini Helper tools

User avatar
onoehring
AppGini Super Hero
AppGini Super Hero
Posts: 1156
Joined: 2019-05-21 22:42
Location: Germany
Contact:

Re: 5.92: Lookup with Show as radio neeeds view access

Post by onoehring » 2020-11-13 10:20

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:
d2.png
d2.png (1.18 KiB) Viewed 3148 times
(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.
d1.png
d1.png (2.42 KiB) Viewed 3148 times
(both images have been created under the same username)

Maybe someone else can test and confirm this.

Olaf

pbottcher
AppGini Super Hero
AppGini Super Hero
Posts: 1635
Joined: 2018-04-01 10:12

Re: 5.92: Lookup with Show as radio neeeds view access

Post by pbottcher » 2020-11-13 15:35

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.

User avatar
a.gneady
Site Admin
Posts: 1281
Joined: 2012-09-27 14:46
Contact:

Re: 5.92: Lookup with Show as radio neeeds view access

Post by a.gneady » 2020-11-14 18:41

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?
:idea: 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.

pbottcher
AppGini Super Hero
AppGini Super Hero
Posts: 1635
Joined: 2018-04-01 10:12

Re: 5.92: Lookup with Show as radio neeeds view access

Post by pbottcher » 2020-11-14 19:27

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.

User avatar
onoehring
AppGini Super Hero
AppGini Super Hero
Posts: 1156
Joined: 2019-05-21 22:42
Location: Germany
Contact:

Re: 5.92: Lookup with Show as radio neeeds view access

Post by onoehring » 2020-11-14 20:47

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

User avatar
a.gneady
Site Admin
Posts: 1281
Joined: 2012-09-27 14:46
Contact:

Re: 5.92: Lookup with Show as radio neeeds view access

Post by a.gneady » 2020-11-16 19:33

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.
:idea: 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.

User avatar
onoehring
AppGini Super Hero
AppGini Super Hero
Posts: 1156
Joined: 2019-05-21 22:42
Location: Germany
Contact:

Re: 5.92: Lookup with Show as radio neeeds view access

Post by onoehring » 2020-11-17 08:12

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

User avatar
jsetzer
AppGini Super Hero
AppGini Super Hero
Posts: 1807
Joined: 2018-07-06 06:03
Location: Kiel, Germany
Contact:

Re: 5.92: Lookup with Show as radio neeeds view access

Post by jsetzer » 2020-11-17 08:57

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:
  • 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
    chrome_TY9nZNC0SV.png
    chrome_TY9nZNC0SV.png (4.84 KiB) Viewed 3025 times
  • 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
    chrome_uxlzdxnv4R.png
    chrome_uxlzdxnv4R.png (3.51 KiB) Viewed 3025 times
    I like using Bootstrap's .label class for such things:

    Code: Select all

    <span class="label label-danger">TEXT</span>
Personally, I got used to adding separate tables for all kind of selections, sometimes even for such "simple" fields which look like booleans in the beginning. If i have the feeling that the customer hasn't thought it through to the end and might request more values than 0 and 1 later in the project, then I already have a lookup table for this and it only takes a minute to fulfill customer's request just by adding a new record.

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 [code]...[/code] blocks for better readability

AppGini 24.10 Revision 1579 + all AppGini Helper tools

Post Reply