Is the query set to "Get More’ vs “Standard”? You want “Get More”.
The query is set to “Get More”.
Oh yeah. The Id field context portion is tricky with agg models. You need to make sure the alias for the Id is “Id” and not the default alias name it gives you of “id” which has a lower case i.
Same goes for any agg field. Rename the alias to the field name.
You can’t always do that. If you can’t rename the alias, you have to go to the XML to state that the context should be set to the alias name for the field rather than to the field name.
How would I state the context in the XML. I searched to community to see if there was a guide but I couldn’t find any.
Pat, Rob was right just setting the alias name was not enough. I am not sure where I need to edit the XML to set the context.
Er … uh … I was able to get it to work just by changing the alias of the agg model field used for context. Just tested it again.
The alias name is how it stores and references the value in the model. If all the aliases were renamed this way, you couldn’t tell there were an alias or field.
One question though. Is the field you want to use in context on the object the model is based on, or something in related object through a lookup or master-detail?
Hey Pat,
This aggregated table is aggravating!
I tried your suggestion and Rob’s on hacking the XML. Neither worked.
I am back to square one right now as renaming all the aliases with the field names for some reason wiped out the data. I pulled the new fields into my table with no success. New issue I will figure out.
Back to the original issue…
The field I want in context is on a related object through the lookup master. When I renamed the alias it is only the field name.
On the Inventory Position object there is a lookup to the Item Master object. The Id of the Item Master is what I need in context.
Thanks for working this through with me. Let me know if anything is not clear.
Well Pat is right. Many times, if you make the alias exactly the same as the field name your context will work correctly. But you can’t have the same alias name twice in your model, and sometimes that gets you in trouble. (It has for me). So in that case you do have to jump into the XML to get the context definition right. Here is how.
- Define your alias in your aggregate model.
Remember to use this alias in the “before drawer open” action sequences where you pass a value into the conditions set up on your related models.
Then set up context on the table in the drawer. Just choose a field, any field from the ojbect that is running the aggregate model.
- Save your page and jump over to the XML and find that Skootable and look for its context.
Change the mergefield value in your condition to the alias value you chose in step 1. In this case I changed line 72 to:
<condition type="contextrow" field="ParentId" mergefield="accountIdentifierAlias" operator="="></condition>
That should set you up for Success!
Thanks for the step by step instructions Rob.
I think this is where I am getting confused. It feels like your example is if the originating table is the aggregate table. For me the aggregate table is in the drawer. So the conditions that I pass are not coming from the aggregate table.
When the aggregate really comes into play is when I have to set the context. I renamed the alias’s and set them in the context XML. That did not work, no records loaded.
Maybe if I don’t rename the alias and set the XML with the system generated Alias name?
I am just throwing out ideas at this point since it seems like everything I am doing isn’t working.
Thanks!
I am. Was to going to suggest that we meet to look at it. Are you using an aggregate field that is on a related object via lookup/master-detail as the field to set context against?
That would have been fantastic! Maybe next year.
I am using an aggregate field that is on a related object via lookup/master-detail.
The images at the top seem to show detail records in your drawer, not aggregations (unless you are using somthing like Max record Id in the aggregatation)
But I’ve been able to put aggregate models in a drawer. There are a few cues that may trip you up.
The field controlling the context condition applied in the component of the drawer has to be in the aggregate model (and in the primary model). Here is my case: Under a list of accounts I have a drawer where contacts are aggregated by department. Because the account will be used for the context condition it needs to be in the grouping fields as well.
If you cannot make the alias match the field name (for whatever reason) the xml code replacement looks like this.
<condition type="contextrow" field="FieldAliasName" mergefield="Id" operator="="/>
I now have this working properly! Thank you for all of your help.
Lesson of the week: Don’t try to figure something new out when you are juggling 10 other things. The task will feel much more complicated than it actually is.
Rob - what you describe above worked perfectly.
Pat - I can see why you change the alias name to the exact name of the field. It is much easier than having to change the XML.
I think why everything kept failing for me was I kept making changes to the same grouping fields. I would imagine information was being cached so everything I did didn’t work. Once I removed all the grouping fields and started over everything worked with out issue.
Thank you as always!
Aaah Yes!! We’re all doing a happy dance!
This has been helpful. I have a similar use case. I have an aggregate table with master classes that have drawers that should show the aggregate of its corresponding sub items. I’m trying to pass the master class, but it’s giving me duplicate sub classes within the drawers.
I used Rob’s suggestion within the XML. The master class (SPS Class) is grouped with the alias “sPSClassc”. The sub class aggregate model has an aggregation MAX(SPS_Class__c) with the same alias “sPSClassc” so I could use this to pass in the context.
I used before load to activate and set the sub class aggregate model to the “sPSClassc”, queried, and added context within the XML where Field = “sPSClassc” and Merge Field = “sPSClassc”.
When the query is on Standard, it returns the correct sub classes, but obviously you can only click on one at a time. It’s only when I switch the query to Get More that it doubles the sub classes…
Any ideas would be much appreciated. Thanks.
Doubling the sub classes is symptom of problems in your context conditions. They are not being applied which means all rows in the model will show in the open drawer, not just the ones you want to be connected to the parent.
Context conditions are annoyingly very hard to debug.
I’d reccomend actually changing the name of one of yoru context alias values. Sometimes there is confusion when ID’s are named the same thing. I’m not sure that is the case here, but its worth a shot.
Hi Rob,
The weird part is that not all rows in the model are appearing. It’s correctly showing the sub classes of the master class, it just happens to show the correct sub classes twice… That’s why it seems like the context is actually working to an extent.
Why would it show the correct sub classes when I query with Standard, but double when I query with Get More?
Hi Rob,
Any ideas on this? We still have doubling, but for the correct sub classes. Any advice is much appreciated.
Thanks.
Hi,
I’m having the same issue, but I think the difference may be the fact that I’m using a date field or formula field…
I’ve created a formula field that determines the close year (off opportunity close date) so I can pass in the aggregate year value into the condition for the drawer model. This works fine with no context and with one drawer, but when I open a second, it of course then updates to show the new (and old) rows in both drawers. I can’t get any context setting to return any rows.
Any thoughts on what the context should be? I try putting the grouping alias (cyCloseDate) like this:
as well as many other combinations, but the drawers are always empty.
Thanks!
Paul
worked like a champ for me too!