Explicitly rendering a queue results in queue header additional queue header section displayed

  • 1
  • Problem
  • Updated 2 years ago
  • Acknowledged
  • (Edited)
I thought I had logged this before but was unable to find it - possibly it was the same issue for a different component.  Apologize if this is a duplicate.

When explicitly calling "render" on a queue, an additional header section is displayed instead of fully "re-displaying" the entire queue.  For example, if you call render 5 times on a queue, you will see 6 header sections.

Note - This stems from https://community.skuid.com/skuid/topics/queue-component-title-search-labels-template-string-not-cha....

Steps to reproduce:
1) Create page using XML below
2) Preview page
3) Click "Force Queue Render" button

Expected Result
Queue displays completely re-rendered with 1 header section

Actual Result
Queue displays with a 2nd header section

Sample Page XML
<skuidpage unsavedchangeswarning="yes" personalizationmode="server" showsidebar="true" useviewportmeta="true" showheader="true">    <models>
        <model id="Opportunity" limit="20" query="true" createrowifnonefound="false" datasource="salesforce" type="" sobject="Opportunity">
            <fields>
                <field id="Name"/>
            </fields>
            <conditions/>
            <actions/>
        </model>
    </models>
    <components>
        <buttonset model="Opportunity" uniqueid="sk-25Keii-196">
            <buttons>
                <button type="multi" label="Force Queue Render">
                    <actions>
                        <action type="custom" snippet="renderQueue"/>
                    </actions>
                </button>
            </buttons>
        </buttonset>
        <queue model="Opportunity" tagrendertype="template" searchbox="true" tokenizesearch="true" showsearchbydefault="true" uniqueid="oppQueue" searchmethod="server" searchplaceholdertext="Search Opportunities" emptysearchbehavior="query" title="Opportunity Queue">
            <rendertemplate>{{Name}}</rendertemplate>
            <interactions>
                <interaction type="tap">
                    <action type="abandonRows" querystring="id={{Id}}" model="Opportunity" affectedrows="context"/>
                    <action type="custom" snippet="updateOpportunityTracker"/>
                </interaction>
            </interactions>
            <searchfields/>
        </queue>
    </components>
    <resources>
        <labels/>
        <javascript>
            <jsitem location="inlinesnippet" name="renderQueue" cachelocation="false">var params = arguments[0],
$ = skuid.$;
skuid.$C('oppQueue').render();</jsitem>
        </javascript>
        <css/>
    </resources>
    <styles>
        <styleitem type="background" bgtype="none"/>
    </styles>
</skuidpage>
Photo of Barry Schnell

Barry Schnell, Champion

  • 18,076 Points 10k badge 2x thumb

Posted 2 years ago

  • 1
Photo of Gregory Smith

Gregory Smith, Employee

  • 304 Points 250 badge 2x thumb
I'm not getting that result.  When I hit 'Force Queue Render' my opportunities disappear, but no extra queue header appears.  What version are you using?
Photo of Barry Schnell

Barry Schnell, Champion

  • 18,076 Points 10k badge 2x thumb
Thanks for looking in to this Gregory.  I'm running 9.5.4 and just tested again and am able to reproduce in Chrome & IE on Windows 10.  What version are you running?  I don't think browser or OS should matter in this case but what browser & OS are you using?
Photo of Gregory Smith

Gregory Smith, Employee

  • 304 Points 250 badge 2x thumb
9.5, Let me update and look again
Photo of Gregory Smith

Gregory Smith, Employee

  • 304 Points 250 badge 2x thumb
I see it.
Photo of Gregory Smith

Gregory Smith, Employee

  • 304 Points 250 badge 2x thumb
I will fill out a bug report, Thanks Barry.
Photo of Barry Schnell

Barry Schnell, Champion

  • 18,076 Points 10k badge 2x thumb
Thanks Greg.  Interesting that it didn't happen in 9.5.  In my OP, I mentioned that I thought I had seen this problem before but that i had logged it and it had been fixed (I couldn't find the community thread, possibly it was closed).  In any case, your findings indicate that this is likely a regression introduced in a version after 9.5.