Idea | push command | option for populating Page Revision description

[pfkong]

Hi there!

Idea:

When using skuid-sfdx's push command to send Skuid Pages to an environment, I'd like to have an option to write to the skuid__Page_Version__c record's skuid__Description__c field for all pages that were pushed.

Use Case / Pain Points:

Whenever I push Skuid Pages to an environment, I need to ensure that each Page Revision is associated to a story/request ticket our org has. Therefore, in addition to the auto-revision record created by skuid-sfdx:push, I must manually create a Skuid Revision record to populate the skuid__Description__c field with the ticket's name.

With larger deployments this means I must navigate to each Skuid Page I deployed, wait for the Builder to load, write in the ticket name in the Revision section, and then save. Since throughout development I'm asked deploy to multiple environments (testing, staging, production), this process can quickly become tedious and would be better automated for my case, especially if I deployed a Module's worth of Skuid Pages.

Other Comments

I'm happy to contribute for this feature (to the best of my ability)! Please let me know what y'all think of this idea and how feasible it is with the current way skuid-sfdx is structured! If the concept seems clean, I might try my hand with a branch.

Regards,
Peter K.

[zachelrath]

Hey @pfkong ! The feature request makes sense to me, would definitely accept a PR for this.

As far as implementation approach -- there are 2 main ways this could be done:

1. API change + Skuid-SFDX change
   • Skuid adds support (in a future release of Skuid managed package) for passing a description to the Skuid Page Push REST API endpoint, called here, via a header.
   • Update Skuid SFDX to pass this new header when calling the REST API
2. Just update Skuid-SFDX to make additional API calls to regular Salesforce REST API endpoints.

(1) is the most ideal in terms of efficiency. Basically the Skuid page push API endpoint needs to be updated to accept a Header to receive this information, e.g. "x-skuid-page-revision-description": "JIRA-1234" or something like that, and then server-side within Skuid's REST controller it would just apply this to all of the most recent page revisions created by the Skuid Page updates. However... this would require waiting for the next major release cycle of Skuid's SFX package, and then would require the Skuid SFDX CLI being able to detect whether the backend supports that header yet, so...

(2) Is an alternative that could be done independently of Skuid's managed package release cadence. Skuid SFDX could be updated to make another 2 REST API calls to the regular Salesforce REST API after the page push API call completes, to do the following:

1. Query for the most recent Page Revision for each of the Pages updated in the page push API call (use the SOQL query API to do this, possibly using a child relationship query)
2. Use the SObject collections API to update the skuid__Description__c field on all of these Page Revisions (you'd need to batch it to do this 200 records at a time)

Maybe @Rnhatch could speak to the possibility of adding support for handling this server side in Skuid's Apex code.

[pfkong]

Thanks so much for your response @zachelrath ! :)

Approach (2) would definitely allow me to use this feature sooner, since our org is still a few quarters away from having the capacity to do a version update (which would require a manual regression test of all live Skuid Pages).

That said, is there a way to have a stopgap option (3) where we do the following?

1. Send the initial push API call, receive a response that can confirm if the destination org's Skuid managed package is at a version that's able to accept the new header param (to which if it is accepted, send a response).
2. If so solution (1) would've been run already from the initial skuid-sfdx call.
3. If no confirmation is received from server response, proceed for solution (2) with continuing the other REST calls.

[zachelrath]

Yeah solution 3 is possible, if Skuid's API were to add the feature it could return some response header indicating the managed package version, or some other flag indicating that it accepted the header and made the updates, and if so then Skuid SFDX could skip the subsequent API calls.

[Rnhatch]

@pfkong @zachelrath Sorry for the radio silence. It made me really happy to see your conversation last week. We had the day off on Friday - and it had all slipped under the radar by the time I got back at it. But now I'm coming back to this.

Your ideas about improving the SFDX plugin make sense, and I'm going to pass along the conversation to others who are looking at the bigger story of improving the CI/CD features of skuid (on both platforms).

But I'm also thinking it might be possible for you to deploy automation without needing to use the Skuid plugin. The Core SF CLI has data commands that could be integrated into your scripting. Seems you could query the Page Record ID's of the pushed pages, and the create a new revision record for each of those pushed pages.

[pfkong]

Hi @Rnhatch! Also really happy to see your response; appreciate you passing the mention to the greater discussion :)

Thanks for suggesting scripting the SF CLI data commands; I'll look into that for the time being then!