The
XMPP issues often relate to client behavior; see Vocera Vina iOS 6.0.0, Vocera Vina Android 6.0.0, and Vocera Platform 6.4.0 for additional information.
This section summarizes the new features in this release.
This is a maintenance release and has no new features.
This is a maintenance release and has no new features.
The
The adapter added a new Disable nested results in group directory search policy that revokes the display of nested users and groups. (XMPP-1236)
The
We have updated some internal testing scripts in order to reflect bug corrections and a more efficient test run. (PFM-15986)
The badge counter in both Engage Mobile and the Vina has been redesigned to reflect a more realistic and accurate count of missed calls, messages, conversations, etc. (XMPP-487)
This section provides information about fixes and improvements to the
The following issue is fixed in
The following issue is fixed in
When the user logs in to
The following issue is fixed in
The adapter no longer fails to start if there are devices registered to inactive or removed users. (XMPP-1020)
The adapter no longer fails to load patient-linked conversations where the creator has been deleted. (XMPP-1036)
The adapter now correctly tracks iOS device registration after a restart. Previously, the adapter might fail to clear registration and keep the user logged in to multiple devices. The adapter would log the user out of one device automatically. (XMPP-1244)
The following issues are fixed in
This section provides information about known product defects and limitations in the current release.
The user's presence is not updated to "Available" after the defined duration expires. (PFM-9544)
Workaround: When XMPP is restarted, all clients that were in DND presence will be reset to Available when they reconnect.
Presence information is inconsistently reported if you create a user with the same login as a deleted user. (PFM-11097)
If you create a user with the same login as a previously deleted user, the new user can log into the iOS version of the Unified Client but is automatically logged out after approximately 10 seconds. (PFM-11102)
If you create a new user with the same login as a previously deleted user, neither the recreated user's device nor the recreated user's XMPP identity are registered with the system correctly. (PFM-11109)
When you successfully delete a user, the audit log incorrectly reports a "Failed to process event" statement for every message the deleted user has previously sent. Performance may be adversely impacted if the deleted user has many messages. (PFM-11108)
Deleting a user with many (approximately 4,000) combined messages, conversations, and assignments may delay the delivery of a critical alarm or alert by approximately 40 seconds. (PFM-11115)
Failing over to a different node causes data that the XMPP adapter has acknowledged, but not processed, to be lost. (XMPP-474, PFM-14822)
Workaround: Restart the XMPP adapter to rebuild the XMPP cache and create the missing identities.
Sending a request to cancel a "coverage request" may result in one or more participants not receiving the cancellation. (XMPP-472, PFM-15376)
Double notification of template creation will be sent to a user if they are logged into both Vina iOS/Android and Vina Web. (XMPP-471, PFM-16172)
If a person drops a connection during a 1/1 conversation, they will receive all of their presence notifications when they reconnect to the conversation. (XMPP-109, PFM-11823)
Updating the pillow_number of a bed in an alert may cause XMPP to deadlock. (XMPP-39, PFM-14310)
Workaround: Pre-populate the pillow_number for every bed to the value that will be reported by alerts. This will prevent the alert creation from generating a Bed subscription message, making it extremely unlikely this particular deadlock will occur.
The Facility and Unit names are not updated in the Vina application after being updated in Vina Web. (XMPP-38, PFM-14873)
Workaround: Restart the XMPP adapter after updating the Facility or Unit name in Vina Web,
If two incoming calls come in at the same moment, the second call will be reported as declined instead of missed. (XMPP-32, PFM-15890)
If Postgres is interrupted while starting the XMPP adapter, the XMPP cache connection pool will be in a prolonged bad state. (XMPP-24, PFM-15945)
Workaround: Contact the Support Desk to run a corrective script.