Release Objectives

The primary objectives for the Cobalt 3.7 Release were to:

  1. Fix priority bugs and close gaps in functionality identified by support, implementation teams, and customers as well as items uncovered by our automated testing sprints.
  2. Produce a stable, cross-version compatible release of the Cobalt product.
  3. Incorporate automated testing into the Cobalt product release process.
  4. Achieve AppSource certification for our entire product (Core, Membership, and Certification solutions).
  5. Improve the portal user experience in an impactful way.

Expected Benefits

The Cobalt 3.7 will be considered a success if the following criteria are met.

  1. All Priority 1 bugs selected for inclusion in the release are implemented or fixed during this project.
  2. Cobalt 3.7 passes regression testing in Cobalt’s Dynamics 365 8.2 on-premises, 9.1 on-premises, and 9.1 online UAT environments.
  3. We can test at least 40% of testing and regression scenarios in this release using automated tests that are incorporated into the regression testing process.
  4. We can successfully list our product(s) on AppSource.
  5. Resolve bugs and gaps in functionality related to single sign-on and web elements to provide a more seamless experience for portal visitors. This will be achieved when all SAML SSO-related cases approved for inclusion in sprints have been resolved and all related feedback addressed.
  6. Implement an updated portal home page with a design that more closely matches the rest of the portal as well as a more complete set of tiles and link logic so that it is easier to navigate. This will be accomplished when the portal homepage redesign cases in each sprint have been resolved, all customer feedback for them has been addressed, and no existing functionality is lost.

Policy Updates

Hosting Implications: ​​​​​​Cross-Domain Hosting​

In 2019, IETF (Internet Engineering Task Force) revised their standard when it comes to protecting against CSRF (cross-site request forgery) request. After this adjustment in the standard was made, Google announced their effort to make adjustments to their Google​​​ Chrome browser to accommodate this update. The deployment of this standard to Chrome, with other browsers shortly following suit, introduced a breaking change for all our client’s Portal and ISV web application, regardless of the Cobalt version that they were on. To remedy this, we needed to adjust the Web.config files for all of our UI based web applications (portal and ISV) to ensure that our web applications leveraged a secure samesite cookie. Going forward, we are instituting a new policy when it comes to hosting our portal web application, in particular when it comes to leveraging our Web Elements functionality. We are now only supporting web element portals that are hosted within the same domain as the parent site (i.e. CMS). We are instituting this policy primarily because we are anticipating ​that the IETF (or any major vendor in the web browser space such as Google or Microsoft) will be continuing down this path of increasing security. By having the web elements portal be within the same domain as the parent site, we are hoping to prevent further break changes to our web applications. ​In order to successfully ​host our web elements portal in the same domain as the parent ​CMS site, the client needs to coordinate with Cobalt in the following ways:

  • ​​​​Client provisions a new DNS entry for the current web element site (clientwebelements.cobaltsaas.com) so that it is within the CMS’s domain (client.org). Popular choices by current clients who already have this sub-domain in place for this new DNS name relative to client domain have been members.client.org and portal.client.org.​
  • Client provides Cobalt an SSL certification for that domain prior to go-live date. Client will be responsible for ensure that this certificate stays up to date on a rolling basis by coordinating with Cobalt through support tickets.
  • On the day of go-live, Client will be responsible for updating the CMS in question and coordinating with other third-party vendors in regard to the DNS update (i.e. Higher Logic, WordPress, etc).
  • On the day of go-live, Client and Cobalt will be responsible for updating configuration values inside of CRM to point to this new DNS name. This includes things such as web element configurations, cache configuration, email templates, IIS rewrite rules, and other various configuration values (see implementation/upgrade notes for more details).
  • Cobalt will need to ensure that the same site secure cookie configuration is in place for the web element website via the web.config (see implementation/upgrade notes for more details​).​

Autonumbering Adjustments

​​​With the requirements bestowed upon us by Microsoft to meet their code quality standards for the ISV Embed license, we needed to rework and remove some code around our autonumbering functionality. This required that instead of relying on locks to ensure that autonumbering values are unique on a sandbox processing worker by sandbox processing worker​ basis, that we instead leverage our autonumbering API for all our clients. This would normally only be setup for our clients who have larger sets of volume or are load balanced with multiple CRM virtual machines. In the future, we anticipate using the out-of-the-box autonumbering functionality introduced in the 9.X version of Dynamics once we have deemed ​that it can sustain comparable amounts of load that our API currently handles today. See implementation/upgrade notes for more details​.

Supported CRM Versions

It is recommended that clients use, at the very least, one of the below versions of CRM for implementations when upgrading to 3.7.0. Going beyond these versions is up to the project team’s discretion​. For implementations or projects that are targeting an online go-live, it is best to patch CRM to the latest 9.x version, as to have the smallest version gap between what is on-premises and what is online. This is because development and stage environments are always on-premise. ​Client implementations on 9.X must upgrade to at least the 9.X May version.

​​​​​​​​​​9.X Version: May 2020 9.0.16.7

​8.X Version: March 2020 8.2.16.16​

Cases and Background

Portal

In this release, most of the work done around the portal was related to the portal redesign. As of this release, the portal homepage has been restyled so that it looks more modern and is consistent with the styling on other pages of our portal, while also improving on our data usage that is used to render this page. Additionally, the individual controls, as well as what controls are on the homepage (and their location on the homepage), are configurable via the Web Element Designer. Clients have the option to upgrade to this new home page framework or stay with their current home page if they have a customized variation already, but from a product standpoint, we will not be investing in the deprecated home page logic anymore and will only be investing in this new framework in subsequent releases. 

Features

Case Title​Description
19495 Custom Theme of Custom Web Element does not persist in Stand Alone Portal via Sitemap EmbeddingThis case allows users to specify generic custom CSS and JavaScript URLs on the Settings record. Any file specified in either relevant field will be applied portal-wide.
24900 Elegantly Handle Bad Data + Merge TextPrior to this case, if an Order Source had invalid merge text within its Order Source Link Text field, the My Orders page would load over and over for an indefinite period. This rendered the My Order page inaccessible. After this case, the My Orders page will load even if the merge text is incorrect. That said, the Status of Orders with Order Sources where the merge text is incorrect will be marked ‘Not Payable’.
25313 Handle Custom Styling and JavaScript for Generic Web Elements PageThis case allows custom JavaScript and CSS URLs to be specified within widget Service Configurations such that all relevant Web Elements affected by the Service Configuration have those custom .js and .css files applied.
25432Add spacing to comma-delimited list of accepted file types in document upload control validationThis case added spacing to the file types displayed in the accepted file types validation present on all our document upload controls by default.
27302Web Elements – Add More Filters to List ViewsBefore this case, the number of filters which could be specified on a custom grid or list Web Element was limited to two. Now, new Filter dropdowns are dynamically added as needed.
27470Update jQuery Version used to be ConfigurableThis case provisioned a field, JQuery Version URL, on the Settings record where a jQuery version can be specified using a URL. If the field is null, our product now defaults to version 3.4.1. NOTE: ​Any client specific jQuery scripts will need to be updated to work with the 3.X version (see implementation notes).
27937Home Page ReworkThis is the parent case under which the sub-cases which provisioned the new portal homepage framework were filed. The result of these changes is that the portal homepage is now configurable via the web element designer. Individual homepage elements can be modified on an ad hoc basis and can be added or removed from the homepage without issue.  Additionally, there were UX improvements around the membership control.
28231Web Application Configurations via Service ConfigurationThis case provisioned the Service Configuration used to store portal homepage layout data.
​​27489​​Session Expiration Popup Warning​This case provisioned a session expiration pop-up warning which can be configured to appear in the portal and/or ISV when a user’s session is about to expire.

Bug Fixes

CaseTitleDescription
22805URL Typo in Social Share LinkThe email social sharing icons for classes had an incorrect query string parameter in the URLs generated for the Class details page. This case corrected that issue.
23373Form: Conditionally Require on Question Logic EntityThis case fixed a bug wherein Conditionally Require Question Logic was broken when the parent Question was hidden. Example: Country is a hidden field on a Form; if Country = China, a specific field should be required. This example would have failed to operate as expected prior to this case.
24470Form Option Sets – No NULL Option for End UsersThis case resolved an issue with our option set controls where those controls did not have a null value option.
27116Cobalt 3.6 Queries/ViewSummary.ascx references functions that DNEThis case addressed a bug introduced in Cobalt 3.6 where the Custom List and My List pages within the Web Element Designer would throw an error.
27397Conditionally Enabled Field Not LockedPrior to this case, using Question Logic to conditionally logic a field would not lock the field if the Expected Value field is null. This was changed so that end users could lock fields as they pleased without having to specify some impossible Expected Value to ensure the field was not improperly unlocked.

SSO, Authorization, and Authentication Updates

3.7 brings our product up to industry standards regarding SAML SSO. Highlights include the fact that IdP-initiated flows are now supported and that our product now allows custom attributes to be passed easily via non-dev configuration. Additionally, the authentication cache was reworked such that the CMS User Role entity is no longer responsible for both authorization and authentication. Now, the CMS User Role entity only handles authorization (roles and groups) while the CMS User Identity Definition entity handles authorization (specifying login information, email, friendly name).

Features

CaseTitleDescription
11631Read / Write Custom SAML AttributesThis is the parent case which set up the framework by which custom attributes can be specified for use in SAML SSO-configurations. In other words, this case is what allows end users to, for instance, specify an alternate primary key in a situation where Cobalt is a service provider (SP) or pass additional, custom Attributes to an SP when Cobalt is the identity provider (IdP).
26596Workaround for Handling SAML Login Assertion when user triggers SSO flow from within Web Element (Non-SSO Flow)This case added a Service Configuration Property to the widget site Service Configuration, ‘HideLoginButtons’, which, when set equal to True, hides all of Cobalt’s base login buttons within the portal and any associated Web Elements. The goal here was to prevent end users from using our base login control instead of an SSO-enabled login control in certain scenarios.
27532Framework Update – Authentication CacheThis case provisioned a feature in our Authentication Cache framework wherein users can now specify their desired Evaluation and Cache behaviors on a per CMS User and User Identity Definition basis.
27653CMS User Identity (Non-SSO Flow)This was the parent case under which the sub-cases which provisioned the new CMS User Identity Definition entity were filed. This new entity helps segment authentication and authorization functionalities by making this new entity responsible for the former and CMS User Roles responsible for the latter.
27661SSO Request Handling – Logging UpdateThis feature allows users to specify that trace logs should only be generated for SSO events by using the web.config page.
27669SAML Role/Group Formatting (Non-SSO Flow)This case brought the syntax our product uses to display role and group information on the ~/Metadata.ashx page in line with the industry standard.
27671SAML Metadata Update for Filtering Roles and GroupsThis case added two Service Configuration Properties, ‘RelevantRoles’ and ‘RelevantGroups’, to the Identity Provider Service Configuration. Using these two Properties, end users can now filter what Role and Group information are sent to individual service providers (SP).
28278IDP Initiated SAML SSO flow w/ Cobalt As Sessions ParticipantAfter this feature’s implantation, Cobalt’s product now supports IdP-initiated flows where cobalt is an SP.

Bug Fixes

CaseTitleDescription
26695Incorrect SSOState Evaluation on Subsequent SAML2IDP Login RequestThis case corrected an issue wherein an end user attempting to log on via SSO would not be properly logged on via SSO if they were routed into the password reset process.
26854Improper Relay State Handling with SAML SSOPrior to this bug-fix, if a user logged on via SSO on a given page of Cobalt’s portal, they would not be redirected to that page on completion of the SSO flow.

AppSource

Locks are when data is made read-only by a process to ensure other processes cannot interfere with the running process. Though such locks are typically only a few milliseconds in duration (if not less), Microsoft highlighted the locks in our product as a blocker for certification on AppSource. As such, the cases addressed in 3.7 dealt primarily with removing these locks.

Features

CaseTitleDescription
26787Product Locking Issues PersistingThis was the parent case under which all lock removal cases were filed. The locks in our product were one of the primary reasons Microsoft said we could not be listed on AppSource and so removing those locks was critical to the project’s success.
​27851​​Remove SDK All Column References​​Most likely for performance reasons, Microsoft discourages the use of retrieving all columns of an entity. 
​28186​Client-Side Updates for AppSource – High Priority Only​The CrmUiUtility file leveraged inside of our product solution was using JavaScript methods or deprecated endpoints that needed to be removed or updated.

Core

​These are items that were introduced into our Engagement Dynamics product offering.

Features

CaseTitleDescription
19075Allow for Cron Jobs to execute a workflow against a Collection of Entities (Queried Crons)This case provisioned queried cron functionality within Cobalt’s base product. Queried crons are Cron Jobs which execute a specified Workflow on the records returned by a specified Query at regular intervals.
27662Cobalt Upgrade Workflow for Custom Roll out stepsThis case provisioned a Workflow, executed from the Settings record, which completes all necessary CRM-side configuration to facilitate an upgrade from lower versions of Cobalt to 3.7. The goal is to update this Workflow with each release.
27013SQL Configuration Exception ThrowingBefore this case was implemented, SQL connection configuration issues would often go undetected because exceptions were not thrown in certain scenarios. After this case’s implementation, SQL connection configuration issues will result in exceptions being thrown within the portal and ISV.

Bug Fixes

CaseTitleDescription
5615Add Attendee to Meeting Reg: Exclude Currently Registered Contacts & Contacts Being Registered in the Current WizardPrior to this fix, Contacts who were trying to add an Attendee to a Meeting could search for and find themselves, even if they had already registered. This case corrected that issue.
22622Publish to portal on election not respected on portalIn older versions of Cobalt, the Publish to Portal flag on the Election entity was not respected. This case corrected that issue.

Membership

​These are items that were introduced into our Engagement Dynamics product offering.

Bug Fixes

CaseTitleDescription
24598Display on Portal flag on Member Type records not respectedOriginally, Fees associated with Member Types where the Display on Portal flag was set to No were displayed on the portal during the membership application process. This case resolved that issue.
16114Order for dues getting paid can update Date Paid on Dues Item twiceThe Date Paid field on Dues Items used to get hit by two update events when a user paid their Dues Order. This caused problems in cases where an organization wanted to send a confirmation email to a member when their Dues Item was marked Paid as two emails would be sent. Now it is only hit once as one would expect.

Certification

​These are items that were introduced into our Certification Dynamics product offering.

Features

CaseTitleDescription
14997UX – Add Primary Naming Strategy to Exam EntityThis case added a naming strategy to Cobalt’s Exam entity.

Ecommerce

​These are items that were introduced into our Engagement Dynamics product offering, specifically when it involves Sales or Accounting.

Features

CaseTitleDescription
12373Update code to handle Product BundlesThe Cobalt Product now supports Product Bundles. This case is what built out that functionality. Shipping and Tax accounting data will be derived from the Product Bundle’s pricing data while other GL Entries will be derived from the child Products’ data.
16334Amounts on the Sales Order Payments Need To Be Set for all Sales Order PaymentsPreviously, Sales Order Payment Amount fields were only set when a Payment was being used to pay down multiple Orders. This was an issue for RAMCO as some of their reports relied on this Amount field. This case ensures that the Amount field is now set in all scenarios.
27114Set Invoice Balance = $0.00 when Invoice Status Reason = CanceledThis case brought the Invoice entity’s functionality in line with Cobalt’s Accounting module. Since, based on Cobalt accounting data, a Canceled Invoice has a Balance of $0.00, this case ensures that the Balance field on Invoices are set to $0.00 when their Status Reason is Canceled.

Bug Fixes

CaseTitleDescription
11465Orders with freight amount and product-specific receivables Product GL Accounts set create GL entry errorsIn scenarios where an Order had a Freight amount and an associated Order Detail had an Existing Product with a Product GL Account of Type = Receivables, the subsequent GL Entries were incorrect. This case corrected that problem.
22731Inactive Product GL accounts direct GL entries to the wrong accountOur accounting module was not filtering Inactive Product GL Accounts. The result was the Inactive Product GLs were still used as if they were Active. This case corrected that issue.
27606Accounting Export Wizard Throws an Exception on Form.aspx PageThe Accounting Export wizard was throwing an error. This case fixed that.

Miscellaneous

Bug Fixes

CaseTitleDescription
18740 Remove CrmEntityTypeCode from Generated Classes or Enforce Dynamic RetrievalThis case ensures that any references to ObjectTypeCode in our product is generated dynamically. This avoids the issue where, if Cobalt’s Solutions were imported in an ‘incorrect’ order, the ObjectTypeCodes for our custom entities would not match the hardcoded values in various wizards.
26407Abort “In-Progress” Crons on Application StartThis case ensures that, if a server-side issue disrupts the execution of a given Cron, the relevant Cron Schedule in CRM will be marked as Aborted.
​28456​Cache Reader not Firing Correctly​​Issue with the cache data reader when retrieving multiple records resulted in the system falling back onto SQL or CRM web services.
​27098​Plugin Registration – Recommended Event Dispatcher appears to not be used currently​​Auto-naming strategies for records were not always getting executed when there was no corresponding server event handler. 
​28048​Client Event Handlers not Preventing Save Actions from Occurring for Violated Validations for 9.X​​For clients on 9.X on-premise or online, we were not properly preventing saves from executing when we identified that the inputted data was violating a rule that we maintain in code. 
​28323​Multi-Select Option set Update not Persisting​​Depending on the update done to a particular multi-select option set, the new value was never posted to CRM. 
​28356​URL Encoding Issues w/ Encrypting and Decrypting Logic​​In various edge case situations, if an encrypted value was used as a query string parameter, the system may not be able to decrypt the value as it was not properly URL encoded first. 
​​26398​​​Update Cron Scheduler to Dispatch non-Workflow triggered Crons Asyncronously​​This case allows for multiple long running Cron schedules to be executed within the context of the ISV concurrently.