Is this a known issue in skuid?  A response from skuid would be appreciated.

Here is how got it to work.  If use an old Skuid page and changes header to buttons.  The context on the buttons no longer work.  If I COMPLETELY rebuild the page the buttons work.  

Is this problem fixed with the new release?  * SKUID-2880] - Button Set loses context

Hi, Bill,
Sorry you’re experiencing this issue. I’m not positive if the new Skuid release would fix the particular problem you’re having. Have you tested the new Skuid upgrade to see if it fixes the problem?

Also, it looks like you’re using the button set inside a collapsible wrapper component? It’s possible there’s an issue with the button set working inside the collapsible wrapper. If you reproduce the scenario outside of the collapsible wrapper component, do you still see the issue?
Thanks,
Emily

I put it outside a response grid and it still does not work.  I have found if I add buttons to a page developed before brooklyn the context on the does not work. I am downloading 9.5 to my sandbox to see if that works.

UPDATE

I have the entire page in a response grid so the page adjusts to mobile.  If I move the button outside the response grid, the button does NOT work.

If I move both the button and the field being conditioned outside a response grid it DOES work.

If I built a NEW page from scratch, all is well.  Except, I have many, many, many pages to fix.

Will the update fix this?

I did upgrade in a sandbox with the button inside of a response grid and the buttons did NOT work. I can NOT move both field editor and the button outside of the response grid as I would have have a mobile problem. 

I assume we still need response grids for mobile?

SKUID-2880 responds to https://community.skuid.com/t/redirect-to-url-button-in-a-contact-popup and https://community.skuid.com/t/in-context-not-working-on-a-button-within-a…

You might want to check those to see if there is anything related to what you’re seeing.

I think I may have discovered why the buttons are not rendering.

I have taken out most of the code on this page except one field in the Collapsible wrapper and a button. If I have a wrapper header with “Yes – initially collapsed” the button does not render. If I change to “Yes – Initially Open” then the button renders.

Any thoughts?

Cheers,

Bill Fox

IF({{Connected_Phone__r.DNC_fax_reason_or_event__c}} == "",

"",

"DNC/F")

IF({{DNT__c}}== true,

"Text",

"")

IF({{Roll_Off_Reason__c}} == "",

"",

"RollOff")

LEFT( {{Connected_Member_DNA__r.Person__r.Name}}

,

{{UI_Only_Field__r.CSS__r.LEO_hdrMenuOptionSub__c}} )

IF({{Connected_Phone__r.DNC_fax_reason_or_event__c}} == "",

"",

"DNC/F")

IF({{DNT__c}}== true,

"Text",

"")

IF({{Roll_Off_Reason__c}} == "",

"",

"RollOff")

LEFT( {{Connected_Member_DNA__r.Location__r.Name}}

,

{{UI_Only_Field__r.CSS__r.LEO_hdrMenuOptionSub__c}} )

Hi Bill - Did this work previously and just recently stop working? Unfortunately, the page you posted was cut-off so can’t make out the entire situation. One thought on why the button shows when “Initially open” and not when “initially collapsed” is that possibly you are loading the model data in the wrapper open actions? You mentioned it works in some scenarios and not others but the scenarios seem to keep changing. I’d strongly encourage you to create a small isolated repro of the situation using stock objects. You can mimick the functionality you have in your page using stanard objects/fields and the same components. If you can do this and reproduce, identifying the source of the issue will likely be very easy.

Hi Bill -

It took me quite a while to piece together what you are trying to do but I think I’m understanding your intent.  From that understanding, I believe I have figured out what your issue is and it has nothing to do with Grids, Collapsible Wrappers, etc.

Unfortunately, you have stumbled upon a Skuid bug that appears to be specific to Button Sets.  

I have posted the issue at ““Remove All rows in Model” action breaks conditional rendering on Button Set Buttons” with an isolated repro.

If my understanding of what you are trying to do is accurate and based on my findings with the bug, I believe the only workaround for you (until Skuid releases a fix) is to use a Page Title Component instead of a Button Set.

As you’ll see with the isolated repro, boiling down complex use cases to simplified versions using standard objects makes identifying the root cause much simpler

This is a bug. We’ll notify when a fix is released.

Thanks for confirming Stephen!

Bill - I thought about this some more and you might have a workaround besides having to move to a Page Title button.  In your action sequence for “Before Open”, you are emptying the model then creating a new row.  The field editor only contains a single field.  Instead of emptying the model and creating a new row, if you just update the field to “blank” (or use cancel model changes which will effectively do the same thing), you should be able to avoid the bug with button sets.  This, of course, assumes you are never needing to save the row you are creating.  If you do, then things get more complicated but there might be some solutions.  Hopefully avoiding the “empty” model workaround will work for you.

I thought I saw this was fixed in  the newest release * �SKUID-2880] - Button Set loses context.  It still does not work.

Hi Bill - Your are correct.  The issue that I logged at ““Remove All rows in Model” action breaks conditional rendering on Button Set Buttons” occurs in 9.5 (latest release as of me writing this).  Hopefully one of the workarounds I proposed will work for you until Skuid fixes the current issue.

Hello Skuid Community ~

Thank you for your thoughtful suggestion! Skuid listened to your concern and has implemented your idea in the new Brooklyn Update 1 - Iteration 4 release which is now available on the Skuid Releases page.