Adding a working hours configuration in the K2 Workspace is trickier than you’d think.
I have a client who wants to track all outgoing messaging from all of their K2 applications to assist in troubleshooting if someone says they didn’t receive a notification.
Normally, no big deal; create a database table or two, a database view and an insert and a list proc, turn those procs into methods in a SmO and call it from a SmartObject event after each of the email events in the workflow. Good to go, right?
But all outgoing messaging includes escalation e-mails… trickier, but I’ve got a slick little trick up my sleeve.
I’m working on re-creating a SmartForms application for a client — which was already in progress when I took over for another engineer — when I bumped into the exception described in the the title. This application was deployed from another environment.
Where’s the problem?
You wouldn’t think this would be a thing.
I’ve a new client running K2 4.7 who has changed the URL for the K2 Workspace. The person I took the client over from could only guess at the correct URL.
How did I find it?
K2 SmartForms controls are validated in two ways: One is immediate, and the other is rule-based. But the rule-based validation applies to an entire form, not to a specific control.
But does it have to be that way?
Given source and target systems within a company’s intranet. The source system is a SharePoint server, though which K2 is surfaced. The target system is also a SharePoint server, through which Microsoft Project Online is surfaced. The challenge: to access the data on the target system through the use of REST services only — without a JSON descriptor.
The upgrade evolution across four environments and two months is finally complete. And I learned something about the process I want to share: Thanos doesn’t come to visit.