Overview
The Groundswell Calendar Display, powered by ToastUI, gives designers the ability to quickly have a modern calendar display in their sites and dashboards with the simplicity of a single component. The dense, versatile display supports different calendar views with styling matching your site’s accent color. Example interfaces and utility rules are attached, which demonstrate usage and features of the component.
Key Features & Functionality
Hi Justin/GS Team, when I try to save an object with the component the "_v7" is removed. So if my SAIL/Expression has "calendaryDisplayField_v7(...)" it changes to "calendarDisplayField(..)" and the new options and inputs are shown as invalid as if it reverts to a v1 version. Appian support has stated this to me: " was able to reproduce the issue you are experiencing in Appian environments on multiple versions (24.1, 23.4, and 23.3)...."
If there's a development backlog for this item, can you add this as a bug? Is anyone else seeing this behavior? If so, have you found a workaround?
Thanks, I generally love the component otherwise.
Thanks for the feedback. I'll respond in two parts:
1) The "revert" from _v7 to just calendarDisplayField is expected (https://docs.appian.com/suite/help/24.1/component-versioning.html#backward-compatibility - specifically, "Going forward, developers will use the new version of the component by default"). A designer should consider that calendarDisplayField = calendarDisplayField_7. This is how SAIL components work now. a!buttonWidget is always the newest version, older versions are something like a!buttonWidget_23r2. I'll note that this issue is not specific to just this component, but any custom component with versions.
2) The parameter issue is something we've reported to Appian previously, but received no guidance on either resolving on our end or on Appian's. As such, I'm not aware of any way to alter the component to avoid this issue, and my stance is that this is a bug in how Appian processes versions of custom components. Even though there is a warning message, the parameters work as expected, so the issue seems to an issue with their design helper tool not understanding custom component versions correctly.
I too would like this issue to go away, so given this update, I can re-open the issue with Appian to see if we get better responses from Support/Engineering.
Great and quick response! TY so much! I have been using this for several versions so the change to accepted versioning along with the input warnings threw me. I can confirm it's working. Again, I really appreciate the support and the component!
Leaving the original comment for posterity but I believe my assessment is incorrect. I did some additional testing, in found this was actually working as expected in several of my 24.1+ environments.
In one environment the issue was still appearing, and I noticed that it had a slightly older version of the plugin. I then took the following steps:
1) I upgraded to the latest (7.5.3) - issue still present
2) Restarted the app server - issue went away
So I think the issue is at least partially a caching issue Appian-side, and also possibly an issue with how major versions are configured in the plugin package (there are two unique values in the config files). Some versions of the plugin have a package major version lower than the highest individual major component.
For next steps: I would make sure your plugin as v7.5.3 and request an app server restart from Appian and that should hopefully fix the issue