Ionic ion-accordion with Custom ion-icon

I recently had to re-visit some code for our Caddify no-code Mobile Companion App builder and had the opportunity to incorporate Ionic’s ion-accordion component. My use case required customisation of the icon used against the header of each accordion though, and I could not find an example for this. So here one is.

See the Pen
Ionic ion-accordion with Custom ion-icon
by Todd Halfpenny (@toddhalfpenny)
on CodePen.0

This CodePen example shows an ion-accordion-group with three accordions in. The first uses the OOTB icon, the second shows a working custom icon (still an ionicon) with styling, and the third shows what I was initially doing and getting it wrong.

The key to success is to define an ion-icon but to also give it a class of ion-accordion-toggle-icon, without which the out-of-the-box icon is also shown.

A working ion-accordion with a custom icon would look like this;

<ion-accordion value="second">
 <ion-item slot="header" color="light"> 
   <ion-icon
 class="ion-accordion-toggle-icon custom-icon"
 name="logo-ionic"
 slot="end" >
   </ion-icon>
   <ion-label>Second Accordion with custom icon</ion-label>
 </ion-item>
 <div class="ion-padding" slot="content">
 Second Content
 </div>
</ion-accordion>

In this example the custom-icon class is just used to set the color of the icon.

First Contribution to the SFDX CLI

I’ve been pushing some of the non-technical folk within Caddify to adopt the Salesforce CLI for some time. I find the ability to manage logins to different orgs a huge win and know that others benefit from this greatly also. And it was during one of these conversations with our CEO that he said “now if it could open orgs in different browsers that would be amazing”… and that got me thinking.

See the plugin’s changes in action in this video.

I have created several SFDX CLI plugins that we use internally (mostly managing scratch org creation and setup) and am very familiar with node and TypeScript so saw this as a great opportunity to see if I could implement a change that meant the DX org:open commands could target specific browsers on the user’s computer.

I had read – fairly recently – about the new modularisation of the SFDX CLI project, and was excited by this as I remember hearing from the Salesforce folk years ago when SFDX was initially released, and I asked about whether or not they’d planned to open source it all, and was told that it would be indeed be one of the end goals. Anyway, off I went to find the repository that supported the org namespace. After forking the project and pulling it down to my local development environment I was able to see that made use of the open node package, so in turn I made my way to their npm page to see if anything existed already to support “browser targeting”… and there it was, the project supported optional parameters to achieve just what I was after.

Within less than half an hour I had a working proof of concept on my local machine. I then turned to the Contributing section on the DX repo to see how I could get involved, and from there I created a new issue against the repo, mentioning that I’d love to create a PR to implement the new functionality. Only a short while later I had a response from the team, welcoming my input.

I proceeded to more properly implement the change (you know, with tests and that) and submitted my PR. I was honestly bowled-over by the welcoming, supportive, and helpful responses to my PR from the whole team. I was given guidance on naming, implementation, help messages, and all sorts… and I guarantee that the end code that was merged into the plugin’s repo was many times better than my first iteration. Huge thanks to Shane McLaughlin and the whole team for their support and patience.

This new feature is available in the v1.9.0 release of the plugin-org plugin.

In short, the new functionality is really useful, and I’d love to hear your thoughts on it, and also, if you think that the DX CLI could do with new features or improvements then dive on in and get involved.

Salesforce Vidyard Video Playback

I personally like to watch a lot of informational videos, I find this a good way to learn. One thing I do like though is being able to change the playback speed.

Sadly a lot of the Salesforce videos I watch are published through Vidyard, and for some reason Salesforce decide to not offer the option to change the playback speed via the video settings menu. There is good news though, and this comes in the form of hacking the video URL through the browser devtools.

Here’s a quick video demoing how to do it, but in short you want to add an extra query parameter to the video URL used. In the demo I add &speed=1.5 to the end video URL to enable me to watch the video at 1.5x speed.

I hope this helps you too.

Understanding the Salesforce Security Review with Amnon Kruvi

London Salesforce Dev’s Meet – April 2021

The latest installment of the London Salesforce Developers’ Trailblazer community meet (I’m sure the title gets longer every month) was another ripper, and this time it was a musical one.

We were once again honoured to have our co-organiser – and Salesforce MVP – Amnon Kruvi presenting for us, and this time on Understanding the Salesforce Security Review.

The Salesforce Security Review is a process that all apps need to go through if they’re to be listed on Salesforce’s AppExchange (this applies to paid-for as well as free apps), and it’s notorious for tripping folk up. At MobileCaddy we have recently just been through this process with our latest product Caddify – a no-code Companion App builder – and I’m all too aware of the pitfalls of the process (my scars are still raw). This is not to say that I’m not a fan of the SR (security review) process as a whole, as our application certainly improved in some areas having gone through the process (and I personally learnt lots of useful things about security too). The SR is, however, an undertaking that shouldn’t be breached without being prepared for what lies ahead… and this is what Amnon most tunefully delivered in his talk.

Thanks to MobileCaddy for their continued support in processing the videos. And be sure to subscribe to the London Salesforce Devs YouTube channel to be notified of future releases.

If you enjoyed this video you might want to also check out Amnon’s debut on Invocable Methods which is incredible (though it’ll be your earworm for at least a week).

After watching the session you’ll be sure to have picked up lots of points including to Think about Security at Every Stage of your application, and I have a couple of extra tips;

  1. Join the Security Review Partner Chatter Group – The partners and Salesforce personnel in this group are an invaluable and supportive bunch, and their guidance and advice is gold. In fact join the group before your first submission and ask about anything that you have queries on.
  2. Document ALL THE THINGS – If you’re app needs without sharing or does anything at all that sways from the absolute best-practice then make a note of it in your False Positives document.
  3. Take screenshots and copy the text of your Security Review wizard forms answers. If you fail your first submission (which very well may happen) you’ll need to re-enter all these details again.

The London Salesforce Developer’s Trailblazer community group is run by myself, Keir Bowden, Amnon Kruvi, and Erika McEvilly, and we meet every month. You can join our group here, and also follow us on Twitter and see much of our past content on our YouTube channel. We’re always looking for new speakers who are willing to share their knowledge with our community, so if you feel like contributing please get in touch.

As usual big thanks must go to not only my fellow organizers but also our incredible speaker Amnon, our sponsors MobileCaddy and BrightGen, and Salesforce for providing us with some certification vouchers to give away as prizes to our attendees.

sf-package-version-checker – SFDX Plugin to notify on completion of Salesforce Package Builds

If you’ve ever built Salesforce packages with the SFDX commands (in fact long before this) you’ll know that the creation of a package can take some time, especially if your package has dependencies.

At MobileCaddy we’ve been adopting the SFDX CLI as much as we can – and in fact embracing the SFDX ethos as a whole – and recently we’ve been working with the Salesforce second-generation packaging (2GP). During this I’ve found that the standard SFDX command to create a package version would continue to give me status updates every 30 seconds for 10 minutes by default, and even though I could set the overall timeout to a longer value (using the –wait flag, and specifying a number of minutes) I often forgot that the task was running and found myself forgetting to watch the terminal window. What I really wanted was something that would notify once the build had completed successfully (or erroneously).

So, during one of the package builds (~25 minutes in this case, if I remember correctly) I put together the basis for a new SFDX plugin that I could run to monitor the latest package build request, and then ping up a desktop notification when it had completed.

I was actually on the line-up for the (now postponed) CzechDreamin’ 2020, with a talk titled “Take your SFDX Plugins to the Next Level”. The talk covers many ways to interact with SFDX plugins other than via the CLI, and one of the topics included was the use of the node-notifier npm module to create native desktop notifications, and so I put this to good use.

You can very easily support basic (and more advanced) notifications with node-notifier for Mac, Linux and Windows environments; here’s some sample code (similar to that used in my plugin);

First import node-notifier (after installing it with npm/yarn)

import * as notifier from 'node-notifier'

Then to use it have code similar to this;

notifier.notify({
 'title': 'Latest Packaging Version Creation Complete',
 'subtitle': ‘Success’,
 'message': SubscriberPackageVersionId: ' + res.SubscriberPackageVersionId
 'icon': iconPath,
 'sound': true,
 'timeout': 30
 });

This results in this type of experience;

The source code (with little over 100 lines of actual logic) can be found in the github repo, and the plugin can be installed as an SFDX CLI plugin and run with the following commands;

$ sfdx plugins:install sf-package-version-checker
$ 
$ sfdx pkgvsn:monitor