User-specific Value Lists

[LaRetta]

Hello there Forum!!!

A text field in Contacts. I need a popup menu which will display, depending upon the Staff viewing it. This popup will need to be user-specific and only contain THEIR possible choices. And they need to be able to add and change this popup freely but it would need to be restricted to 15 possibilities. A portal would not work in this scenario (no space). I'm considering many things and would appreciate knowing how you all would approach this situation. I have a Preference file, a Staff file and a Contacts file. I currently don't have a Value List file. Is this a good candidate? Or would you store this VL within the staff record itself? Ideas would be greatly appreciated.

LaRetta

[Fenton]

In 7, I think you could put this table wherever you needed it for data entry. In 6 I guess you'd want a ValueList file. I would use an unstored calculation field, Get( AccountName ) to identify the person, and relate to the VL table. (In 6 you'd have to use the PatternCount( Status(CurrentGroups)) function; not fun.) Or maybe you have a custom login field?

They create a record, auto-entering their account name, and then they make their choice. The value list created is filtered by the relationship on the _cAccountName to that account name field.

I'm not exactly sure what you mean by "restricted to 15 possibilities." Do you mean there are 15 possible choices in all? Or that, of a greater number of possible choices, each person can only pick 15 maximum for themself (with or without exclusion of others' choices?)?

In the latter case you could count the relationship and not allow more than 15 records per person; easiest done if a script creates the record.

[LaRetta]

Hi Fenton

Apologies for being unclear on 'restricting to 15.' I meant we want them to keep their 'personal' value list 'customer ratings' to a maximum of 15 possible entries. Why?

Because if we don't restrict them they will get lazy and just begin adding hundreds of entries into their value list. 1) The popup will become unGodly long and 2) their cross-tab reports (portals) by Contact by Rating will become unmanageable and I want to restrict to 15 (whew). If they decide they want to change one entry and begin calling it something else, I will script replacing those field values through their Contacts. In this way, staff can rate and categorize their Contacts according to what makes sense for them; a new sales rep taking over an existing client base can mass-replace the data with 'their' terminology; and their reports and views can be standardized.

I don't have a Custom login field as such. But login Account Name is set in a global in Preferences with each account login change. And part of this is used to relate to many things, ie, it exists in their Staff record also. So I think this would work well for establishing the relationship to their personal value lists. I have a sneaky suspicion that this may come up again and if I use a 'field' (as in a Staff Record), I'll be adding other fields down the road. I'm considering inserting the VL name into a field also and including that in the relationship filter which I'm hoping will allow multiple VLs down the road.

As I consider the possibilities, I am unclear on how to restrict the record (VL item) count; how to filter the VL (if they end up requesting additional fields with this same functionality) and including the VL name in a field, and so forth. And I would need to open the VL to new entries which would 1) change their VL list - replacing an existing item and 2) run a find (or GTRR) and replace the existing entry with a new one throughout their Contacts.

I appreciate your clear thinking. You've sure helped me many, many times, Fenton. Contacts table, Staff table and another table? And conditional popup displayed accordingly that can be adjusted? My tests are not providing answers for me; as everything I've tried seems convoluted. I have a clear vision of what we need but no clear vision of a good solution.

LaRetta

[Fenton]

I'm afraid I've been OTC (off the computer) for a while. I'm not sure about what version of FileMaker we're talking about here. If it's 7, I say give everyone their own Account, then use a calculation field with Get (AccountName); always available, no monkey business. A custom login, in a global, available from everywhere, would also be sufficient.

I'm seeing this as fairly simple. A ValueList table. A field in this table for their name; a field for each value list; named pretty much how you'll name the value list taken from it. A record for each item of the value list, has their name, has a text entry for the value.* They can create a record, but their name is auto-entered, and they put in, or choose the value from a value list with all items; I don't know where this would come from, probably another table with all the values (but no names); tables are cheap -]

If you can only create records with a button, then a self-relationship on the name (which you already know; it's in the calculation field; or put it into a local global) can count, and stop if it's going over the limit.

A defined value list, in the data entry table, is filtered by a relationship on their name (calculation field), targetting the field for the desired value list.

I don't see a problem with targeting the correct value list; you'd know the field name. If they want lots of these, you'd have to create a field for each; or something fancier to filter by Get(ActiveFieldName). But I'd be willing to have some empty fields. I mean how many entries could there be? And how many value lists? Also, these dedicated field value lists could be used in portals.

As far as letting them change a value, then going and replacing it with another in all their earlier entries...Yeah, it could be done, with a dedicated interface. But, is it worth it?