Enum Reference question

[sorin_mihai]

Hello all

I’m not really understanding something here, about Enum Type, when used with a Reference Slice for values.

So I make a column Enum Type, I say it’s a Base Type Reference and I give it the Slice from where to take it’s values (it takes the Label Column referenced by the Key column).
Perfect.

But if I also try to turn off the ability to Add Other Values, Appsheet automatically corrects that and imposes to have that option turned ON. But I don’t wont users to be able to add to that list of values from the Slice I referenced.
If I put those values in the Enum Values, than it allows me to turn OFF that option, but then, if I add a row to that Slice, I have to remember to come back to this Enum to add it to the list as well.

Am I missing something here?

Thank you,
Sorin

[WillowMobileSys]

I wonder if has to do with the capability of the Slice - whether you can add values to the Slice or not?

[sorin_mihai]

Could be, but even then, I still want to be able to add values to my slice which then automatically appear in the Enum, but not give that ability to the users directly form the Enum Menu.

[Steve]

Essentially, if you don’t configure an Enum or EnumList column with at least one fixed value, Allow other values must be ON. In your case, you haven’t configured any values explicitly, so all of the column’s possible values must come from elsewhere, from a list of “other values”.

[sorin_mihai]

But if the EnumList is BaseType Reference, are not the Values Referenced … The Values? Why would you want to allow Other Values, since you are Referencing Values, which are in that sence, fixed, to which you do not want your Users to be able to add from that Dropdown …

So if I Reference Values, why would Appsheet display them, but interpret that there are NO Values and thus automatically turn ON the option to add new values?

[sorin_mihai]

Steve:

so all of the column’s possible values must come from elsewhere, from a list of “other values”

• I wish it could be the Referenced Values

[Steve]

With Allow other values set to OFF, you’ve effectively told AppSheet to only allow the user to choose from the explicit Enum values configured for the column, but you have no explicit values configured for the column. You’ve told AppSheet to force the user to choose from an empty set of options, which makes no sense; hence Allow other values is enabled automatically.

With Allow other values set to ON, use the column’s Valid If expression to define the set of values you want the user to choose from.

[sorin_mihai]

I definitely understand that, as long as I would not have made the Base Type Reference and thus given the Users the Option to choose from a list of Values from the Referenced Column. So since I have given a Referenced list of Values to choose from, I am not forcing the Users to choose from an empty list, even though, I have not entered any Fixed Values in the EnumList … This is also confirmed by the EnumList itself, since in the app, it displays the Referenced List, so it is not Empty.

So basically, what I’m thinking is that, I get that if you create an Enum or EnumList Column and not assign it any values, you MUST give the User the Option to Add Values … couse otherwise, what was the point of making it.
But, if you make the Base Type a Reference and you Reference a list that contains Values, Appsheet shouldn’t impose the option to Allow Users to add New Values … it should remain as an option for the AppAdmin.

I might be getting this wrong … but I don’t think so. However, I won’t insist if I didn’t explain myself clear this time, I don’t know I can do any better :))

In my mind this is a slip in Appsheet …

[Steve]

sorin_mihai:

But, if you make the Base Type a Reference and you Reference a list that contains Values, Appsheet shouldn’t impose the option to Allow Users to add New Values … it should remain as an option for the AppAdmin.

If you don’t provide explicit, configured allowed values in the column configuration, then prevent the other values from occurring in the column, the column cannot contain a valid value, rendering the column useless. This is a nonsensical configuration.

Setting the base type to Ref does not imply all existing references are acceptable.

sorin_mihai:

And obviously, I don’t want to have that Add New action display on top of that List of Employees, because I’m not going to add Employees from there. Also, the Employees also make Tasks and Assign the to other Employees and I don’t want to give the option of pushing the Add New Employee Action Button by mistake and mess up the Tables…

I can’t think of another way to do this … this is what EnumLists are made for.

This is what slices are made for.

[WillowMobileSys]

So I have to ask, why use the list in this way - as an Enum referencing a slice? Why not just use a straight Ref type column?

Admittedly, I have not used an Enum in this manner so I don’t know what advantage it might give you.

[sorin_mihai]

With EnumList from a Slice I can choose one or more options from that list. So in my case, I have a Task which I want to assign to employees. So I have a Team column EnumList referencing the list of Employees. When I select the Team, the list of Employees appears and I can choose one or more Employees to have that Task assigned to.

And obviously, I don’t want to have that Add New action display on top of that List of Employees, because I’m not going to add Employees from there. Also, the Employees also make Tasks and Assign the to other Employees and I don’t want to give the option of pushing the Add New Employee Action Button by mistake and mess up the Tables…

I can’t think of another way to do this … this is what EnumLists are made for.

[WillowMobileSys]

Got it! I haven’t had that need yet.

I understand your concern about how the Enum is working for you. Remember, the AppSheet platform is fluid as its constantly changing. The developers don’t always think of all the ways the app creators might use the features and at times try to keep the features purposely minimal until there is a need or ask. No need to introduce risk with extra flexibility that no one uses.

Sooo, it sounds like you have a need for an added feature within the platform. Don’t be shy about submitting a request for the need as an enhanced feature!

[sorin_mihai]

Yes I will, I just wanted to check first if I am missing something or if things are different for other users. I’m curious what @Steve thinks in case I managed to explain myself clearly…I might be mistaking as well …

[Bahbus]

It’s just the way Enums work. If you don’t specify the list, you must allow other values. However, if you use a Valid_If then the allow other values doesn’t matter at all, because if its not valid its not allowed.

[Bahbus]

I even use EnumList with base type Ref and a Valid_If, and no issues.

[sorin_mihai]

And what Valid_If do you use, in case you would like it to be valid_if no_matter_what? :))

[Bahbus · Accepted solution]

Well, in your case, your EnumList is for a set of possible team members to be assigned to a specific task. So, if you have a column somewhere in a table or slice of just those names, you can have the Valid_If just be [TeamMemberColumn] or TableName[TeamMemberColumn] if the column is a different table.

And your data is not valid no matter what, because you only want a specific type of data in that column. Names of people. So basically your Valid_If is the same set of Refs that make up the data to begin with. This gives you an EmunList to choose multiple people from and disables adding any new people to the list. As you add new team members, you only need to add them to the reference list which will then populate them as an option in the EnumList.

So in my example, Subcategories[SubCategory] is the reference column for this column. It autopulls the information just for being base type Ref. I sort them to be alphabetical instead of how they were originally entered using the Valid_If which disables the “Add” option in the EnumList, however, the Allow Other Values still must be on. If I ever add anything to [SubCategory] it automatically becomes available. Just like if you were to set yours up similarly whenever you add employees normally, they will become options to select.

[sorin_mihai]

@Bahbus

That’s exactly p e r f e c t !
Thank you

@Steve

Steve:

Setting the base type to Ref does not imply all existing references are acceptable.

That’t true. If there are no values in the EnumList column and I just put a Reference Column, it won’t display the Values in the Reference Column, so I was wrong and you are both right.
And in the end I still got exactly the functionality I was looking for
Thanks for bearing with me

[sorin_mihai]

That doesn’t actually solve this. I’v put in a Valid_If and it still imposes the Allow Other Values Option …

The EnumList itself works fine, no issues there. It’s the imposing of Allow Other Values that doesn’t fit in the picture, since there are Values given by the Referenced Column (if it’s not empty, and it’s not)

[Bahbus]

It will never allow you to turn the option OFF without hard setting values. The Valid_If just disables the ability to add anything for the user, which is ultimately what you were going for.

[sorin_mihai]

Oh, I see, so the Add New Button would still appear but I would just make it useless … that’s an option but it’s not so elegant … 'couse why would you display something useless in the app.

[Bahbus]

The add button won’t even show up to the user.

[sorin_mihai]

But you don’t have the Add New Option there … hmmmm

[Bahbus]

That’s what the Valid_If does. Since poop is not already in the Subcategory list its not Valid and cannot be added here, but if I add poop to the list (as you would add a new employee to the company) then they show up in the list.

[sorin_mihai]

Getting closer
So how does the Valid_If Formula look like in your case?

[pravse]

I may be confused, but as @WillowMobileSystems mentioned earlier, it sounds like you just should be using a Ref column type — not an Enum with a BaseType which is a Ref.

In general, you can think of the type system as giving you the options below, ranging from most constrained to the least constrained:

1. Enums: specific list of values fixed at definition time
2. Refs: dynamic list of values, identified by keys in another table
3. any type with a Valid_If list: dynamic list of values, identified by a list expression
4. any type with a Valid_If Yes/No expression: potentially infinite set of possible values with a constraint
5. any type: potentially infinite set of possible values limited only by the type definition

The type system is meant to be a way for the app creator to control behaviors — the more specific the behavior, the greater the control. The option to ‘Allow other values’ for an Enum is an escape hatch which permits dynamic modification of the type system. It should be used only for situations where the Enum values are very occasionally changed.

Hope this framing is useful.

[Bahbus]

@praveen We’re going with EnumList in this instance because he needs to be able to select multiple.