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
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
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.
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.
There are not errors, it seems to ignore the parameter "visibleEventCount: 3" infact it doesn't show anything but only the "2 more" label.
We can't replicate this in Safari. We used Example 1 from the sample test. If there are any console errors or additional details that can be provided, we can investigate further.
Hi, i'm using the plugin in Edge, Chrome, Explorer and it works properly. When I try to use the plugin into Safari I cannot see the events into calendar but only the "N more" label into the top-right of each day. I added the property to set the number of events to show but it works everywhere except for Safari. An other problem is that this "2 more" label is not clickable in Safari, it appears as disabled, but Chrome, Edge and Explorer allow to click it. Do you know why? Can you fix these bugs? I'm using v.7.3.0
Looking into this, we should be able to support both in the next update to this component. Current in progress version below". No official ETA on releasing this but I'd like to get it out early this month.
The library appears to not support that field either yet
Thanks a lot for your reply,and what about the "body" field ?