Calendar Display Component

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

  • Display an array of events in Daily, Weekly, or Monthly format. Toggle days and weeks using an input parameter.
  • Automatic timezone shifting. By default, all provided events display in the timezone of your browser, but this can be overridden by providing TZ names ("America/Los_Angeles") OR a timezone code (EDT,CST,etc).
  • Multiple language support. Currently supports US English (en-US), UK English (en-GB), Spanish (es), Italian (it), Polish (pl), and Portuguese (pt).
  • Supports different date formats via a parameter.
  • Supports a detailed event pop-up of time, title, attendees, location, and event description.
  • Supports custom colors, font sizes, borders, and other attributes via applying custom themes.
  • Support for visible weeks, weekend display, and start of week for specific locale needs.
  • Allows event selection, should you want to edit an event or display details in addition to, or in lieu of, the detailed pop-up view.
  • Allows events to be "rescheduled" via drag and drop or through a modal
  • Allows events to be created and deleted directly from the calendar
  • More details and examples available in attached resources and sample application.
Anonymous
  • Hi,
    I've tested the new version (7.5.3) but unfortunately, the edit form still not display these 2 fields.

  • 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

  • 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 calendarDisplayFieldcalendarDisplayField_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.

  • v7.5.3 Release Notes
    • Bug fixes:
    • Updated Edit form to respect edits besides start/end date
    • Fix missing i18n references
    • Enhancements:
    • Added support for editing the Attendees and Description of an event in the popup
    • Added support for overriding the default calendar with multiple calendars (new "calendars" parameter, see updated sample app and docs for more info)

  • 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.