Versions Compared

Old Version 11

changes.mady.by.user Seth Petry-Johnson

Saved on

compared with

New Version Current

changes.mady.by.user Seth Petry-Johnson

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

On this page, the term “Credential” is synonymous with the system term “Discipline”

Table of Contents

Executive Summary

The Application Pathways Page can display information about a Practitioner’s credentials, grouped by Credential (Discipline).

...

Category

Property

Purpose

Credential

{{ model.DisciplineId }}

Int: The ID of the Credential (Discipline)

{{ model.Title }}

String: Credential title

(question) TODO: Should we call this “CredentialTitle” or something, to scope it?

{{ model.Description }}

String: Credential description. (question) TODO: Should we call this “CredentialDescription” instead?

{{ model.LogoAsString }}

String: A Base64 encoding of the logo data.

To render the logo as an actual image:

{{ model.LogoAsString | GenerateImgSrc }}

Role

{{ model.RoleId }}

Int: The ID of the Role representing the Credential

{{ model.RoleName }}

String: The name of the Role associated with the Credential

{{ model.Abbreviation }}

String: The abbreviation associated with the Role. (question) Change to RoleAbbreviation?

{{ model.RolePriority }}

Int: The assigned Role Priority, or null if no explicit Priority has been assigned

Member Role

These values will all be null when the Practitioner does not yet have a Member Role related to this Credential.

{{ model.MemberRoleId }}

Int: The ID of the Member Role representing the Credential, or null if the user doesn’t have a relevant Member Role yet

{{ model.IsGranted }}

Bool: Whether or not the role is Granted

{{ model.MemberId }}

Int: The ID of the Member for the Practitioner

{{ model.MemberType }}

String: The type of Member. “Person” or “Organization”(question) If there is no Member Role, does this get pulled from the current user? Or is it left default?

{{ model.Email }}

String: Member’s email address

{{ model.UniqueId }}

String: Unique Id of the Member Role, or empty

{{ model.RoleLabel }}

String: Role Label assigned (in the case of a multi-instance Role)

{{ model.RoleStatus }}

String: Role Status assigned to the Member Role

{{ model.RoleStatusId }}

Int: ID of the assigned Role Status record

{{ model.WorkflowStatus }}

String: Workflow Status for the Grant/Edit Role Workflow

{{ model.BeginDate }}

Date: Role begin date (question) Name as “RoleBeginDate”?

{{ model.EndDate }}

Date: Role end date (question) Name as “RoleEndDate”?

Configuration / Other

{{ model.Header }}

String: The label associated with the current section of the Pathways page

{{ model.CardType }}

CardTypeEnum: (question)TODO: What is this? What are the possible values?

{{ model.PathwaysConfigurationSectionIds }}

String: (question)TODO: What is this? Is it a delimited list? Why would a Credential summary have access to multiple section IDs? Through configuration a credential can appear in multiple pathway sections. Its common to configure a tab to show in progress and another tab to show available for the same credential.

Helper functions

These functions are stored in GlobalScribanTemplateFunctions.cs

Function

Purpose

{{ DetailsLink }}

Renders the “Show Details” link that expands/collapses the Credential Description.

{{ model.LogoAsString | GenerateImgSrc }}

Renders the Credential Logo

Questions

  1. Should we name things with a prefix, to be more clear what data they are related to? e.g. CredentialTitle instead of Title, and RoleBeginDate instead of BeginDate?

  2. It feels confusing to include Member level data in this this payload, because we (presumably) get that data by joining to the Member Role, but the Member Role could be null. The template author might assume that they can reference things like Member Name regardless of the presence of the role data, but that isn’t the case. Maybe we should remove those things from the template?

  3. There are some properties in the model that I’m not sure are needed. For instance, what’s the need for StepExecuteOrder? Below is a list of all properties currently exposed that I’m not sure we need.

...

Customizing the default template

The default template is designed to support multiple different use cases, although you will need to make a copy of it before you can modify it.

Step

1

Create a copy of the default template

The default template is controlled at the system level and cannot be directly modified. If you need to customize it, start by creating a copy.

Image Added
2

Modify the “configuration variables” section of the template

You can leave the Styles field blank, unless you need to create custom CSS styles as part of your customizations.

The Scriban Template field contains a template with two separate sections. The first section contains a number of “configurable variables” that control how the template behaves. See below for detailed instructions.

Image Added
3

Link your new template to the Credential(s) that should use it

Edit the appropriate Credentials and choose your new template.

Image Added

Default template configuration variables

Note

Customizing the template requires that you modify a code-based HTML template. If you do not feel comfortable doing that, please contact support.

You might want to review the official Scriban language documentation as well.

The default template starts with a code section like this:

Code Block
{{
    # =====================================================================
	# What field to use as the due date? Supported values are "ROLE-END-DATE" and "_NONE"
	DUE_DATE_FIELD = "ROLE-END-DATE"
	
	... [truncated]
}}

The things in UPPER_CASE, such as SHOW_DESC_WHEN_USER_DOES_NOT_HAVE_ROLE, are variables that you can modify to affect how the template behaves. The specific use cases that are supported are:

Template variable

Use case / instructions

DUE_DATE_FIELD = "ROLE-END-DATE"

Controls which Attribute is used to calculate the “due date”.

  • “ROLE-END-DATE” - use the Member Role’s EndDate value

  • “_NONE” - do not calculate a due date

Code Block
STATUS_TO_DUE_DATE_LABELS = {
    "Active" : "Expiration",
    "Deceased" : "_NONE"
}
DEFAULT_DUE_DATE_LABEL = "Deadline"

Can be used to change the terminology used to refer to the “due date”, based upon Role Status.

For instance, you might want to call the due date the “Submission Deadline” for applicants, and the “Expiration Date” for active practitioners.

To suppress the due date for one or more statuses, map them to “_NONE”.

The DEFAULT_DUE_DATE_LABEL is used for all Status values without an explicit mapping.

Code Block
NOT_ACTIONABLE = { "cssClass": "deadline-not-actionable", "color": "#444444", "icon": null, "iconTooltip": null }
DUE_DATE_CATEGORIES = [
    { "daysUntilGTE": 30, "cssClass": "deadline-ok", "color": "#fb952c", "icon": null, "iconTooltip": null },
    { "daysUntilGTE": 0, "cssClass": "deadline-looming", "color": "#b61e3a", "icon": "fas fa-stopwatch", "iconTooltip": "This date is coming soon" },
    { "daysUntilGTE": -30, "cssClass": "deadline-pastdue", "color": "#b61e3a", "icon": "fas fa-exclamation-triangle", "iconTooltip": "This date is in the past" },
    { "daysUntilGTE": -999999999, "cssClass": "deadline-oldnews", "color": "#444444", "icon": null, "iconTooltip": null }
]

Can be used to change the color used to display the due date, based on how far away the date is.

For instance, you might want to display dates in red when past due, orange when due within 30 days, and green otherwise.

This setting accepts one or more elements in an array. The array is examined sequentially, so these should be entered in descending value (e.g. the furthest future value listed first, the furthest past value listed last)

For each date range you can control the CSS class that is applied (in case you have custom styles defined), the hex color code to display the date in, a FontAwesome icon to display, and the icon tooltip.

Code Block
STATUS_TO_CERT_PRINT_LINK = {
    "Active": 123
}

Can be used to display a “Print Certificate” link for specific Role Status values.

Each Role Status (that should display the print link) should be mapped to the ID of a Template Attribute that should be rendered.

Info

This is implemented via an API call that renders a specific Template attribute as a PDF.

To use this feature:

  • The EnableWorkflowObjectAttributeRenderer App Config setting must be enabled

  • The specified ID value must point to a Template attribute on a Grant Role Workflow

  • That same Template attribute must be added to the AttributeRenderer Entity View for the relevant Grant Role Workflow

  • The system user (ID=1) must have an API Key that grants the GET_WORKFLOW_OBJECT permission