Usability - Productivity - Business - The web - Singapore & Twins

By Date: November 2018

Supercharge SFDX with Ui-licious

You drank the Coolaid and you are all in and really love your Scratch Orgs. Just a few things drive you crazy.

When the API doesn't expose a setting

Your application is querying the OutOfOffice objects. Unfortunately they only exist when the Chatter settings have enabled them. To my best knowledge there is no API or config setting to achieve that from the command line. So automated testing in a scratch org won't work.

Ui-licious to the rescue

Ui-licious is a UI testing service that uses JavaScript as its scripting language. This makes an easy read and edit. A script that can set the missing OOO setting is short and simple (if you agree iFrames are easy to handle). You can (almost) read it out aloud:

// URL Provided by data object from the command line
I.must.see("Chatter Settings");
// To ensure we work on the iFrame we get the id
let iframeId = UI.execute("return document.getElementsByTagName('iframe')[0].getAttribute('id')");
// The iFrame loads slowly
UI.context("#" + iframeId, () => {
	I.see("Chatter is a corporate network that lets your users work together, talk to each other, and share information, all in real time.");
    I.select("Users can set Out of Office messages");

The interesting piece in the above is DATA.result.url which is an JSON object that needs to be handed over to the Ui-licious. A small command script in tandem with SFDX does the trick. The beauty here: we directly can reuse the output of an sfdx command as input for the uilicious-cli.

sfdx force:org:open -r -p lightning/setup/CollaborationSettings/home --json > local.json
uilicious-cli  run "ProjectName" "ScriptName" --dataFile local.json -u uiliciousUser -p uiliciousPassword

It probably would be part of a larger CI script, but you get the idea! You might not store the output in a file, but use bash to capture it in memory and use --dataObject instead. Full details are in the documentation.

As usual YMMV

Posted by on 27 November 2018 | Comments (1) | categories: Lightning Salesforce

Cleaning up an APEX codebase with PMD

You inherit a large code base, it is perfect, a work of beauty. Then you wake up to the ping of your PMD run completion and find multiple thousands of rule violation (and you haven't even started to assert test assertions). Here is how to fix that.

Divide and conquer

Boiling the ocean and fix all issues in one go is hardly an option. So you need to strategize. PMD gives you a hint: every rule has a priority property, where you can specify how important this rule is. The higher the number, the less important the rule. You can run PMD using the min -[somenumber] parameter which will ignore rules with a higher value.

Next step is to decide what rules constitute your priority 1 and 2 buckets. I strongly recommend to make them mandatory fixes before the next deployment, so pick the rules carefully. The candidates I suggest are around performance and security:

Priority 1

  • ApexXSSFromURLParam
  • ApexSOQLInjection
  • ApexOpenRedirect
  • ApexInsecureEndpoint
  • AvoidDmlStatementsInLoops
  • AvoidSoqlInLoops

Priority 2

  • ApexCRUDViolation
  • ApexSharingViolations

Thereafter you decide on priority 3 onwards. Strong candidates for level 3 are all the rules that ensure code is maintainable and avoid errors, like deep nesting or cyclomatic complexity (a fancy word for "messy code")

Read more

Posted by on 23 November 2018 | Comments (1) | categories: Apex PMD Salesforce

Lightning Mini Forms

One of my favorite lightning features is the Lightning App Builder. It allows to tailor Salesforce for a given set of users, to show what they need, how they need it.

In the page editor the endless scrolling page, record details followed by related lists, we got to love, can be broken down into multiple tabs. For related lists, the OOTB controls already allow to just pick one. Placed multiple times on a page, the layout can fit a specific audience's precise need, avoiding information overload.

However there's no control to break down the record details. The OOTB record details control will faithfully reproduce the assigned page layout with all sections. Custom controls to the rescue!

Design options

There are two options to consider: where to pull design information from and how to render it. For the later you can consider lightning:recordEdit|ViewForm or lightning:recordForm. Both can be argued for.

The lightning:recordForm only needs the fields / layout options supplied and will take care of all rendering. However you are limited to one or two columns - just like page layouts.

The lightning:record[Edit|View]Form requires coding the fields, probably using an aura:iteration, but leaves you with the freedom of layout. Typically you would use a lightning:layoutItem and its size property to determine the number of columns (with 12 / size = number of columns).

To keep it simple I'll stick to the lightning:recordForm for now.

Next question: where to provision the list of fields from? When you want an universally usable mini form, you can't hardcode them, but provide them using a design property, so they can be provided in the page editor after you dragged the component onto the page.

Still you need to decide what attributes you provide:

  • List of field names
  • Name of a field set
  • Name of a section in a page layout

I'll start with the first one and relegate the other two approaches to future posts.

To make this work you will need a custom lightning component. Let's call it MiniForm. We will only need MiniForm.cmp, MiniFormController.js and MiniForm.design. No helper or Apex will be harmed.

Read more

Posted by on 06 November 2018 | Comments (0) | categories: Lightning Salesforce