Release Notes

21 Jan 2021– TM 3.4.04 Bugfix Release

26 Nov 2020– TM 3.4.04 Bugfix Release

11 Nov 2020– TM 3.4.04 Bugfix and Feature Release

Type	External Issue ID (OTRS)	Issue Description	Fix Description / Impact	Fixed in DB / Setup Version	Affected Components
BUGFIX	-	77605 B: [ICH] Supervising functionality doesn't work	All participants of supervising session hear each other according to business requirements.	3.4.0420.30711	TM-ICH
BUGFIX	2413170	77202 B: [FE][CI] Issue with recurring event scheduled to recur on a different day than it is created	"Yearly", "Monthly" events are created in correct dates	3.4.0420.30711	TM-CI
FEATURE	-	76842 U: [TM-FE,] Adjust SameSite cookies implementation	System behavior and changes to cookies to support SameSite settings and flags introduced by google.  More info on this:  What is Google Chrome SameSite How to handle SameSite (Microsoft) Requires a HTTPS connection to work properly.	3.4.0420.30205	TM-FE

25 Sep 2020 – TM 3.4 Release

We are proud to announce our newest V3.4 TM release, featuring quality-of-life and reporting improvements.

Impersonate Incoming Service (Team) on Transfer

It is now possible to configure Incoming Service Impersonation for internal (virtual) transfers initiated by your agents. This allows to see the transfer target to which service the call initially (before the call was transferred in the Workflows) was made to. 

How to use

 Precondition: Requires at least 2 internal services A and B. Afterwards, enable the checkbox in the "Service Details > Phone Settings" Tab of your Activated Teams.

When enabled on the source (service A), the following scenario applies: 

• Service A takes the call and a blind / virtual transfer to Service B is performed.
• Agent 1 from Service B will see Service B impersonated in both SfB / MS Teams and take the call, then transfers to Agent 2.
• Agent 2 will see Service A impersonation and take the call.

Configure Transfer behavior per Service / Team 

Added a new radio button to steer per Service and Team:

• Calls transferred by the agent to external targets will
• Leave the system (Stop Tracking)
• Stay in the system (Continue Tracking) (default)

 Where to find it? Look in the "Service Details > Phone Settings" Tab of your Activated Teams.

Default System Setting

• A DB Updater system setting stores the default. The DB updater app.config will apply this value for all NEW created services and teams.  Name of the parameter: "Calls transferred by the agent to external targets defaults"
• A new Setting called was added in DB updater to define the behavior for all existing services / teams during an upgrade.
  Default: "stay in the system"

Reporting Changes

Create Empty DB Script  

Our old baseline DB script was based on 2.9, requiring cumulative updates of all versions that followed. Starting for Versions ≥ 3.3 we've implemented a "Create empty DB" script which assists in a first-time installation of TM.

 Where to find it?  Look in the "05_EmptyDB" sub-folders of your source installation file directory. If not provided, ask your Luware Support representative for the latest BI reports for your version.

General Improvements

• Improved Functionality - If a user becomes "Active" for a team, he/she will also be considered for distribution of already queued tasks. If AM get's notified about the the fact, that a team member is being set to active, the distribution recalculation is performed.
  
  
• TM components now use .NET Framework 4.7.2 to access newest MS Graph API functionality. Please update your .NET Framework to 4.7.2 or newer prior to installation of the new components.
   Head to https://dotnet.microsoft.com/download/dotnet-framework to retrieve the installers. 
   General Prerequisites have been updated accordingly.

Known Issues / Limitations

• The "Standby Duty" function,  which allows agents to be reached on their mobile- or PSTN phone and be notified by e-mail or SMS when certain events occur can only be used with a dedicated Exchange mailbox.

Opening Hours Configuration

The following issues affect Opening Hours.

Recurring Events on a DST-Shift-Day	Known Issue (Kendo Scheduler) There is a reported bug in the scheduling component used in Opening Hours Calendar. When you create a recurring event on a DST (Daylight Savings Time) shift day, all related recurring events are shown at shifted time. → A bugfix is outside of Luware scope. Until this is resolved we recommend to create the start of recurring events starting outside of a DST-shift-day.
Events ending during DST-Shift	Shifted Meeting Duration in UI during Daylight Saving time change (Wontfix) There is a known bug in the Scheduling UI affects timezones that use DST (Daylight Savings Time). Calendar entries that end within 2-3 AM on a Daylight Saving Time shift will be automatically changed upon saving, moving the event according to offset of DST (-1h or +1h). This happens without the user actively being informed upon confirming the date. → We recommend not to let meetings end in a DST timeshift. This issue will most-likely not be fixed as the scenario is rather uncommon.
Exchange Calendar on DST	Known Limitation (wontfix) When using Exchange as your opening hours calendar: when the timezone on your calendar account changes, existing all-day events will not be updated to this new timezone. We recommend not change time-zones if you use "all-day" events.
O365 Calendars All-Day Events time shift	Known Issue When using O365 Calendars for opening hours: currently in TeamManager 3.3 "all-day" events appear time-shifted via the UTC offset.  BUGFIX Fixed in LUCS-CI component Fix Version: 3.3.20156.9 3.3.20160.1  (for net4.7) LUCS-CI For versions <3.3: We do not recommend to use "all-day" events for O365 calendars until you're ready to perform an Upgrade.

Extend TM to support multi tenancy

Tenant Management by adding a three level OU Structure is currently only available if manual provisioning is active (Active Directory synchronization is disabled). Please read more on this in the CIC - Customer Infrastructure Connector page.
 There is currently no visible UI warning about this limitation. With AD sync enabled, new Tenant layers added to the Organization Unit with not be reflected. We recommend completely opting for one variant (with AD sync or Tenant Layer support).