Upgrade to 2.8
Recommendations
To upgrade a Casewhere deployment to 2.8, you must be, at least, running a 2.6-series release.
Before upgrading Casewhere, always test your application in a staging environment before deploying the upgrade to your production environment. It would be best if you also backup your production database before upgrading.
If you are deploying Azure App Service using Kudu Zip Push Deploy, you don't have to modify the web.config files manually, only need to update the keys in the Configuration / Application Settings.
Information! If you are replacing the old web.config with the new one, then you can ignore all update it steps in the section below.
Upgrade versions
The following changes must be applied in the described order.
2.8.0.0 - 12/04/2023
Support to run fine on the new version of MongoDB.
- Open the web.config in
Casewhere.Configuration.Weband update the settings below:
<runtime>
<assemblyBinding>
<dependentAssembly>
<assemblyIdentity name="System.Text.Encoding.CodePages" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Extensions.Logging.Abstractions" publicKeyToken="adb9793829ddae60" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.2.0.0" newVersion="2.2.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Win32.Registry" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Security.Principal.Windows" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Bcl.AsyncInterfaces" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
- Open the web.config in
Casewhere.Worker.Apiand update the settings below:
<runtime>
<assemblyBinding>
<dependentAssembly>
<assemblyIdentity name="System.Text.Encoding.CodePages" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Bcl.AsyncInterfaces" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Win32.Registry" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Security.Principal.Windows" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Extensions.Logging.Abstractions" publicKeyToken="adb9793829ddae60" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.2.0.0" newVersion="2.2.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
Support to collaborate nicely without overriding each other's work
Casewhere Application Developer can open an entity such as a workflow, a rule, etc, and they can know who is editing the same thing as me to collaborate nicely without overriding each other's work. To enable that feature you need to add the following settings to the web.config file in the Casewhere.Configuration.Web project.
<add key="signalr:UserEditingDocumentExpiredTime" value="00:03:00" />
<add key="signalr:RefreshUserEditingDocumentIntervalTime" value="00:01:00" />
Enable hard delete for specified Data Objects
A typical scenario is that the business only wants to hard delete some specific data objects in a case (or different cases). Hard deleting is the process of completely removing the information from the database. So Casewhere will support a method via IDataApi to remove all information on Events, Read Database. To use that feature you need to add the following settings to the web.config file in the Casewhere.Worker.Api project.
<add key="db:EnableHardDelete" value="false" />
It is "false" by default if key missing.
Enrich Audit Log with Searchable Information
To enrich log data with searchable information, i.e., fields that can be used for different data query strategies. To do that add the setting below into web.config of Casewhere.Worker.Api project.
<add key="auditlog:DeprecateUserClaims" value="false" />
Default is "false". Key missing also means "false". If the setting is "true", UserClaims is null when Casewhere writes Audit log.
2.8.1.0 - 19/05/2023
There is no change in configuration.
2.8.2.0 - 30/09/2023
Time to live for System Log
To configure the time to live for the system log, you can add the following setting to the web.config file in the Casewhere.Configuration.Web project.
<add key="systemlogs:ExpiredTime" value="7776000" />
Default is 90 days if key missing.
Default is 90 days if key is missing.
2.8.3.0 - 10/01/2024
Enable compress Workflow Events
To reduce the number of workflow events at runtime, you can consider adding the following setting to the web.config file in the Casewhere.Worker.Api project.
This feature will help reduce storage size and increase performance.
<add key="events:EnableCompressEvents" value="false" />
<add key="events:CompressionEventThreshold" value="10" />
This feature is disabled by default if the keys are missing.
Enable invalidate workflow definition cache
This feature should be disabled in the PROD environment to reduce load and build workflow definition. For the DEV environment, you can enable it to run tests with the newest workflow definition.
Adding the following setting to the web.config file in the Casewhere.Worker.Api project.
<add key="test:EnableInvalidateWorkflowDefinitionCache" value="true" />
This feature is enabled by default if the key is missing.
2.8.3.1 - 26/01/2024
There is no change in configuration.
2.8.3.2 - 29/02/2024
Default collation configuration
To increase performance of data query and support sorting data on specified language, you can consider adding the following settings to the web.config file in the Casewhere.Worker.Api and Casewhere.Configuration.Web projects.
<!--Default collation-->
<add key="db:Collation:Locale" value="simple" />
<add key="db:Collation:Strength" value="" />
The default collation from this version to the previous version is Locale: "en" and Strength: "2" if the keys are missing.
Important! If you are installing the new environment from this version, then you can ignore the maintenance step below.
If you change the default collation in the existing environment, you need to access the maintenance URL below to rebuild indexes of all data classes in the Casewhere system to the new collation.
[Admin domain]/Maintenance/RebuildIndexes
2.8.5.0 - 15/07/2024
Configuration the data trigger, event trigger, and rule worker in real-time
In some cases, we can have multiple Casewhere instance point to the same database but each instance can perform the different business. For example, the instance A serves for the front-end business with a few of background workers and the instance B serves for the backend-end business with a lot of the background workers. As result, the current logic cannot solve this case. So, we need to allow to manage the data trigger settings per instance.
To control that settings on each instance, you can add the following setting to the web.config file in the Casewhere.Worker.Api.
<!--Instance Name-->
<add key="runtime:InstanceName" value="Instance A" />
Default is empty if key missing.
Configuration the number of the worker thread in Job Site
To control this number, you can add the following setting to the web.config file in the Casewhere.Hangfire.
<!--Number of the worker thread in Job Site-->
<add key="hangefire:WorkerCount" value="4" />
Default is 4 workers if key missing.