Prepare to Upgrade Your K2 SmartForms Applications

My client has an older version of K2 blackpearl/K2 SmartForms, and is preparing to upgrade to the latest minor upgrade in version 4.

Here are my tips for upgrade prep.

I strongly recommend you go through each of your SmartForms applications to do the following:

  • delete disabled rules. These are named groups of event-driven conditions and actions that appear on a list of rules on a SmartForm or SmartForm View. Look for them as bound or unbound to the current form or view. (Bound rulesets have names like “When the View executed Initialize”, or “When btnCancel is Clicked”; unbound rules are usually assigned an arbitrary name when they’re created.)

    Pro tip: If you’re reviewing the rules on a form, only look at the form rules. Don’t bother looking at the view rules. The icons to the left of each rule will tell you which is which.

  • delete disabled conditions and actions. These are the commands that make up each rule. For example, inside of “When the View executed Initialize” could be comprised of a bunch of conditions and actions, like “If paramID contains 1” (condition) “then transfer data” (action). These conditions and actions can also be enabled and disabled individually.

    In this screenshot of this form rule, the view conditions and actions are being overridden by form conditions and actions. In this case, there is nothing to remove.

    So yes, I’m suggesting you click on every rule, open the Rule Designer, and inspect the contents of each one. Oh, and…

  • open transfer data actions. Opening the transfer data actions forces K2 SmartForms to inspect the mappings before displaying the Transfer Data form. If the system cannot resolve a mapping, you’ll see a warning message that tells you the mapping will be automatically updated to omit the bad one(s).

    Warning prompt, stating that the configuration has been adjusted automatically. Mappings were found that are no longer valid for the context. These mappings have been removed. Save these changes or they will be lost.

    Simply click OK on the modal, and click OK on the Transfer Data form to close it. Now you’ve updated the mapping so that won’t potentially cause a problem during the upgrade.

Since you’re going through every rule anyway, here are some actions you might consider to make life easier for all of your K2 developers: using rule comments. I’m all about using the comments feature in the Rule Designer. Used properly, they’ll allow a developer to get a gist of everything going on inside a rule just by hovering over the comment bubbles at right. So help them by:

  • Add comments to all advanced conditions: Open each of the advanced conditions and copy the text that appears at the bottom of each one. This text is a summary of the attributes, conditions and values that appear in the conditions above it. Close the advanced conditions form and, on the line where the condition is, paste that text into the comment. Now a developer can just hover over that comment bubble to get a sense of what the advanced condition is.

  • Add comments to all message actions: Open up each message, copy the first line or two and paste that into a comment on the line where the Show a Message to the User action is. It offers the same advantage to the developer as is mentioned above — giving the dev a quick peek at what’s going on inside the rule.

    If it wasn’t for these comment bubbles (at right), a developer would have to open up every advanced condition and every transfer data action to learn what is actually happening.

Doing these additional tasks will not impact your upgrade. They’re just recommended as an option since you’re already combing through every rule in your application. I would reserve these activities for active objects in your solution, and wouldn’t waste my time on old prototype objects that aren’t used — those should be backed up and deleted anyway.

If you choose to do these tasks, I’d recommend you include them as requirements in your standard procedures for all future SmartForms work. There’s no sense in doing all of this only to have the practice abandoned after your upgrade.

Having to do this before an upgrade sucks. Not gonna lie. Fortunately, it’s not an activity that requires a ton of skill, but it’s obviously extremely monotonous and repetitive. But when you’re done, you’ll potentially have shrunk the size of your K2 database by weeding out the dead rules, conditions and actions, and you’ll have a clean copy of your application ready for upgrade testing. Plus, upgrade aside, the exercise may give you an opportunity to correct problems you didn’t know about before. Finally, if you opted for the comment updates, you’ll have made life much much easier for the developers who join your team later on.

These are all good things. Just do yourself a favor and give yourself a lot of time to do these reviews in advance of the upgrade so if you bump into some unexpected “opportunities,” you can resolve or mitigate them in advance of your upgrade testing.