Custom table data is not showing in the list collector for end user.

[NeethuB]

I'm creating a catalog item form in ITSM. So I'm using a catalog item, maintain item. So I have created a custom table called u_month to save all 12 months so that in the form I can use a list collector so that the end user can select multiple months from the dropdown. So what I did was I just created a custom table u_month and added 12 months there and put the month field display as true and I refer that in the list collector. As an admin, I can see the applicable month, in the applicable month field, all the 12 months. But as an end user, when the user is trying to open the applicable month field, it is showing as no match found. When I created the table, I have unticked the roles creation, so no role has been created, and no ACLs are also there. So I'm not understanding why the end user is not able to see the values. And for the role, I can't give all the end user a role because if a new user come to the system, I can't give them the role. So can anyone help me to resolve this issue?

[Ehab Pilloor]

Hi @NeethuB,

You can create read ACL for u_month (table.none and table.*) to grant access to this table to snc_internal role, so that any other restriction that is hidden can be bypassed.

Please Accept this response as Solution if it assisted you with your question & Mark this response as Helpful.

Kind Regards,

Ehab Pilloor

[drbob]

Several things here...

I would have put this last given it's complexity but since doing it will change the rest of the answers I'm saying it up front. You _can_ do multi-select choices. It's not nice but using a custom table for 12 records is a waste. The way you do it is you set it up as a choice (where you can pick one) and define the 12 options, then you switch it to a reference and point it at the choice table, filtered for the variable you're working on. Like I said, not nice, probably not supported but it works and it saves you a table.

Thinking about it, in your context, you might even be able to get away with 12 (or maybe 24) system properties and reference those. ..or maybe you have another table that you can slide these into and filter carefully. I would certainly think hard before using up a custom table for 12 static records.

Now, if we go back to how you have things at the moment, this must surely be an ACL issue and the easiest way to find it is to use the Access Analyzer - you just enter the user and table and it will tell you what it blocking the access.

Also, if it _is_ ACLs then you _can_ add all future users in several ways. I would pick the role option and use the "recent" (maybe 3 versions old ?) "snc_internal" role (IIRC, every user is in that unless they are expicitly added to "snc_external" before they first login). If you're making use of these roles and want every user to access then add them both. There are alternatives - using a script that always answers "true" for example but the role approach is best.