Picklist still not working

Bill,

Have you cleared out your cache since upgrading? Many times when people have problems with modifying pre-existing pages, this is at the heart of it. This could be why it isn’t working for you but is working for us. 

Are you able to create a plain page with a reproduction of this problem? I will happily show our developers any problems with basic features breaking. 

I have tried clearing the browser and in browsers I no use. No luck. Here is the code. Its not just here, its lots of places.































































































































































































































































































&

It looks like the entire XML was too large to be posted. I wasn’t able to get the last bit of it. Furthermore, do you have any examples of this happening in places that don’t have custom components in them? Unfortunately, if this issue takes place on your custom objects, then I won’t be able to use the XML.

In order to look at this page, you would need to grant us access into your org so that we could take a look at what you’re doing under the hood. If that is an option you’d be interested in, let me know.

Yes.  I have been using the object but I will stay off while you look at it.  

The picklist if “Temp_Engagement_Type__c” is  not null the following response grid should open

The grid a has a template that should show “THIS AREA SHOULD SHOW”

Go to:
https://dorothy–skuid.na16.visual.force.com/apex/skuid__ui?page=RM1_Engagement&member_id=a0gj00…

Click on “Add Engagement/Opportunity”
Select “Engagement” as the Opportunity or Engagement
Select any “Type” and “THIS AREA SHOULD SHOW” in thew following response grid.







I have responded via email.

I emailed you.

I received your email

Bill,

On this page, RM1_Engagement__Tab_Set_Test, you’ll see that this is where the error is located.

When all of the rows on the model are removed and then new blank rows are put in their place immediately like the picture shows, this creates a problem.

This is a bug that somehow breaks rendering conditions in the normal sense. This removes the event our backend is looking for to trigger the rendering condition. To make it work with this removal and immediate creation, the user will need to press a save button in order to have the event triggered. When they save, the render condition will run properly. Fortunately, this is an immediately implementable work around.

We’ll update this thread when this bug is fixed.

Thank you for bringing this to our attention.

This appears to be very similar or likely the same as https://community.skuid.com/t/remove-all-rows-in-model-action-breaks-conditional-renderi….  Possibly the “Remove All Rows” issue is more wide-spread than just Button Sets and is an issue farther down in the skuid framework.

Yes, these are confirmed by our dev teams as being remarkably similar. Most likely, the fix will be released at the same time for both of them.

Time frame?

We have Enabling issues on a button set (Brooklyn Update 1 - Iteration 1.)  Had a page title button built the exact same way that behaved fine, but the Button Set Button would not enable when the conditions were met.  I built a new page on a standard object to repro it, and the button set behaved perfectly.  So we saw the same issue… existing pages it broke, new pages working just fine.  We scrapped the button set and went with the page title button because we needed to move on.  Our situation had NO Remove All Rows actions, no wrappers, etc.  Just a button set sitting in a responsive grid that would not enable on a simple condition - when a reference field on the same model was not Null (user made a selection, so ok to click the button now.)

That would be great if I have not used over 100 buttons already.  I also saw the page button set works fine.  Need a fix from Skuid as the effort to change back to page tile buttons is will take to much effort.  I assume this will fix ASAP as Skuid made a bid deal about buttons with the new release.  

Still waiting for a time frame on fix.

We cannot give a specific timeline for this issue at this time.

I can not believe this is NOT on a timeline.  

http://help.skuid.com/m/components/l/657818-the-button-set-component

This should be removed from your feature list if id does not work, which it does not. I have spent days converting over to buttons.

Please reconsider putting this on your timeline.

It’s on our timeline. However, we don’t make these timelines public.

So, I do not know if I should spend the time going back and changing all the buttons?

We might be talking about two separate issues.

Currently, we have nothing on the books for broken buttons. We haven’t seen the issue yet. There has been no reproduction of the issue or a live case where we have seen it broken. The fix the devs are working on relates to the fix I provided March 1st and relates to RM1_Engagement__Tab_Set_Test because it is the topic on this post.

We would need to have XML of a broken button to begin working on a fix for button sets. Feel free to paste as many broken button XML as you can below or create a new conversation of it in the community with the broken XML included. It would also be helpful to know what version of skuid you were on prior to upgrading where the button stopped working.

Based on what we know right now, you should go back and change the buttons because our developers have no information to even go on for that.
If we receive XML of a broken button, then we can begin to see how long it would take. Realistically, it would be 2-3+ weeks, but we make no promises. It would all depend on what is happening with the XML.

Depending on what we see in the XML, it could also be a crazy quick fix. It would all depend.

I wish I could give more specifics, but I don’t want to make a claim I cannot back up or keep.

Depending on which issue we’re referring to here, I think the fix has been implemented in the new Brooklyn Update 1 - Iteration 4 release which is now available on the Skuid Releases page.

As a reminder, Salesforce does NOT allow reverting back to prior versions of managed packages. Skuid always recommends installing new versions in a non-business critical sandbox environment to test all mission critical functionality before installing  into a production environment. We also recommend that you update out of date themes when you upgrade.

If you wouldn’t mind confirming first, that would be great! Thank you!