Choose a lookup field value from 'new' records that exist in another model
I have a requirement where the user needs to be able to create records in Model 'A' and records in Model 'B' where one of the fields in Model 'B' is a lookup to Model 'A'.
This is a relatively straightforward scenario when the records in Model 'A' already exist in the database and/or can be saved prior to creating the records in Model 'B'. Unfortunately, my scenario is not that simple. The requirement is that records in Model 'A' and Model 'B' are created by the user and then everything saved to the database. Additionally, using drawers to provide context on 'A' when creating 'B' is also not possible due to UI/UX reasons for this use case.
The page layout is:
1) Table of records in Model B
2) Global Action on table that displays a popup for creating a record in Model 'A'
3) Field in table on Model B that is a lookup to Model A where the user can choose any record that they've created in Model A
All "searches" on lookup filters expect the data to exist in the database. Is there a way to have a lookup field use records from a client side model that has new records?
The reason the page must behave this way is a couple-fold:
1) In the real solution, there is actually two fields on Model B, one that looks up to Model A and one that looks up to Model Z and both A & Z will be "new" records created via a popup
2) Model A & Model Z can't be saved as they are 'created' because everything must be saved or cancelled - all or nothing type of behavior
3) the page is incredibly complex and drawers introduce too much additional "clicking" and the need to take up additional real-estate that would otherwise be unnecessary.
4) Since there are two models (A & Z) and any combination of these two records is valid to assign to Model B records, drawers wouldn't provide that level of context anyway.
Any assistance on how to approach this is greatly appreciated!
This is a relatively straightforward scenario when the records in Model 'A' already exist in the database and/or can be saved prior to creating the records in Model 'B'. Unfortunately, my scenario is not that simple. The requirement is that records in Model 'A' and Model 'B' are created by the user and then everything saved to the database. Additionally, using drawers to provide context on 'A' when creating 'B' is also not possible due to UI/UX reasons for this use case.
The page layout is:
1) Table of records in Model B
2) Global Action on table that displays a popup for creating a record in Model 'A'
3) Field in table on Model B that is a lookup to Model A where the user can choose any record that they've created in Model A
All "searches" on lookup filters expect the data to exist in the database. Is there a way to have a lookup field use records from a client side model that has new records?
The reason the page must behave this way is a couple-fold:
1) In the real solution, there is actually two fields on Model B, one that looks up to Model A and one that looks up to Model Z and both A & Z will be "new" records created via a popup
2) Model A & Model Z can't be saved as they are 'created' because everything must be saved or cancelled - all or nothing type of behavior
3) the page is incredibly complex and drawers introduce too much additional "clicking" and the need to take up additional real-estate that would otherwise be unnecessary.
4) Since there are two models (A & Z) and any combination of these two records is valid to assign to Model B records, drawers wouldn't provide that level of context anyway.
Any assistance on how to approach this is greatly appreciated!
Tagged:
1
Categories
- 7.9K Questions
- 926 Ideas
- 220 Discussion Categories
- 178 General
- 9 Community Feedback
- 3 Community Info
- 18 Knowledge Base
Comments
You have a table of object B and a global action that opens popup.
In that popup you create records for object A and Z.
When user is done an action sequence does the following:
1. Creates new row in Object B
2. Prepopulates the row with the ID's from the new records in object A and Z. This will require global merge syntax, and will require that the new rows in A and Z are the first ones in your model for those objects.
3. You'll also want to prepopulate the Name of the reference fields from new object A and Z so you don't just get "1" or whatever temporary Id skuid creates in the lookup column on object B
3. Closes the popup without saving any of the objects.
Then a global save on all the objects completes the deal and allows for global rollback.
Does this not work?
- Why is the popup a global action? Is that just to save a click from creating the row in model B and then using a row action? Or is there a case where multiple rows in model B are being created, and need to look up to the same new row that is subsequently created in Models A or Z?
- Can the user create multiple rows in A or Z with the popup (in other words, are they tables)? If so, just have row actions on the tables which populate the context row in B.
If the primary problem is setting the right context in model B (meaning, multiple model B rows for each model A/Z row), then you could create a dialog asking the user to select which rows in model B to point the Ids from A and/or Z to after popup close.Raymond - Unfortunately, one requirement of this entire system is that no "temporary" data be inserted in to the database. This requirement makes things incredibly complex on multiple fronts unfortunately. Your approach would work well if this requirement didn't exist. The one thing that would be required though is to have a background job that goes and deletes temporary records because a user could "save" a temporary record and then close their browser essentially orphaning the temporary record. That is solvable of course though
Rob - One key detail that I didn't explain very well in my OP unfortunately makes it such that your approach won't work
Matt - If I'm understanding your #1, you've pretty much nailed it. The user will create multiple Model B records, and then choose a value for 'A' and 'Z' from records that are in that model and those values can be the same for multiple 'B' records. For your #2, I've thought about doing something with a row action to have a "chooser" like your suggestion and even thought about a custom renderer that triggers a popup. Those are my "fallback" options but the users want to avoid clicks or unnecessary popups (they are data entry tasks and therefore keyboard focused).
At the end of the day, there are some solutions (Matt mentioned a few), but in trying to achieve the best UI/UX for the users, the ideal scenario is a standard lookup field that just includes the 'new' rows in 'A' and 'Z'.
Below is a sample page that demonstrates what I'm after. In it, you can create one or more parent accounts using the global action on the "accounts" table or via in-line on the "parent" accounts table itself. Then, you can create multiple accounts, some of which might have the same parent. What I'd like is to have the "parent" field in the account table include the accounts in the parents model (and ideally in the database as well - a union of "new" and "existing").
Appreciate any further thoughts/insight!
Sample Page
Have you considered a custom field renderer for your reference fields on Model B, where you set the source for your options to a Model instead of the database? It might require you to load a LOT of records into your models for A and Z, but I think it would work to capture both new and existing.
From http://help.skuid.com/m/11720/l/214147-skuid-ui-field-renderers :
There's got to be a way to trick skuid into searching for both new and existing records.
Create your own massively long picklist?
You and I think a like! I've considered the massively long picklist as well but it would truly be massive (over time). There are a few solutions, but none of them are really "good" solutions as they either require introducing complexity in to the UI/UX or require a lot of code to create a custom renderer that essentially mimicks what the Skuid default lookup field renderer does but also includes new records in the client. It's a road I'm hoping to avoid.
I'm still holding out hope that there's a "trick" in there somewhere!
I thought about this a little bit. The ideal solution to your problem would be to allow your reference field to have a custom option source snippet that we just hooked into the standard reference field renderer. We have something like that for filter option sources, the custom option source. We have plans on improving that filter option source to have the ability to be asynchronous instead of synchronous as it currently is. If we made it asynchronous, eand extended that functionality to reference fields as well, you could construct an "on-the-fly" model, do your search, then combine with new records that also matched your search and present that list to the user to pick from.
Unfortunately, that's not part of the product yet.
I have 2 ideas though that may or may not work for you.
1. We use the jQueryUI Autocomplete Widget to do our reference renderer, so you may be able to use the _renderMenu extension point described here.
Something like this in your custom render after calling the standard reference renderer...
var input = element.find('input');
input.data('ui-autocomplete')._renderMenu = function(ui,items){};
2. You could add a draggable area to your Model A using jQueryUI's draggable interface and a custom renderer and a droppable area on Model B using the droppable interface and a custom renderer. That way users could drag records from Model A into Model B and associate the records.
Thank you so much for looking at this, especially over the weekend, greatly appreciated!
I think there might be some legs to the _renderMenu idea, I'll take dig further on that. The draggable area idea is pretty slick but unfortunately, I don't think my users will sign off on having two different approaches to setting a value in the field (draggable for new, searchable for existing). Also, Model 'A' and Model 'Z' could have hundreds of records so finding the one they need to then drag could become challenging.
I'll also submit a new post asking for the enhancement of custom option source for reference fields.
Thanks again!