AppGini Community Forums

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

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!

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

I can confirm that this seems a bug as described by Olaf

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?

correct

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

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.

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

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 (4.84 KiB) Viewed 4643 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 (3.51 KiB) Viewed 4643 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.