What is the secret to getting table drawers to work with aggregate models? I saw some posts but never a definitive answer just the end results. In my case we have a client object related to a house (each client is assigned to a house). Each client has a contract (a contract object) that lists how many hours we are contracted to work with them. So John has 300 hours per month, Peter has 250 Hours per month and Jimmy has 200 hours per month on the "Contract Object). If John, Peter, and Jimmy all live in the same House (House Object) I am summing their hours so I know how many hours a month, and a week so we can schedule appropriately. I am using an aggregate model based on the “Contract” that groups by Contract__r.Client__r.House__r.Name. If I wanted to show a table drawer where it listed Peter, James and Jimmy’s individual hours can I do that? I have created table drawers before, but are there different steps if the parent model is an aggregate model? Thank you!
I’m assuming that you have followed this tutorial:
The secret is using the Field Alias from your aggregate model in all the places where you pass values from one model to another in order to filter the detail appropriately. Here are some details.
A pro tip is to look at your grouping fields in the Aggreage model and make the Alias Name value the same as your field name. This helps with some of the items you need to set up going forward.
Then look at all the places where the field is used.
In Before Drawer Actions - you will activate condition and pass value to the detail model. The Value here will be the alias name from the grouping field.
In the Context Condition on the detail table, the Merge Value will be Alias Name. Here is where having the Alias name be the same as the field name is important. Otherwize you need to go to the XML to put the correct alias name value.
That should work for you.
Its one of those things you always need to remember about aggregate models. The name used throughout skuid will almost always be the alias name rather than the field name.
That was the secret! Thank you for taking the time to post, it works awesome!!
Glad to hear it worked for you. You can do some really slick things with this…
I am trying the same thing in a page called transactions. I have granted skuid support access as well. In mine I am trying to create a project based P&L. I have all the transactions in an aggregate model grouped by Type so it display income and revenue, the drawers should show the transaction aggregated by account and then another drawer in that table that show the individual transactions filter down the whole way. I am missing something about the condition like Rich was doing but cant get it. If you can look at the first level I think I can replicate to the next.
This may or may not apply, but the trick for me was I was working with custom fields. In Rob’s example he is using standard fields. So for me I had to make sure I added the __c to the alias name. So for you it might be Credit__c or Debit__c. It should be the exact name of the field . That is the thing that hung me up for a minute. Good luck!
Rich, thanks I believe we are on the right track now.
Is there anyway around the 25 character limit for aggregate model alias names? Unfortunately with our namespace prefix, it makes some of the field names just over the 25 character limit.
No way around the alias name character limit. But you should be able to get things to work with shortened Alias names. You will just have to apply the alias name in the XML for step 2 (setting context condition).
I didn’t even think about editing the context in XML. Worked perfectly. Thanks so much!
View our Community Site Map
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.