The
XMPP issues often relate to client behavior. View the latest documentation for Vocera Vina iOS, Vocera Vina Android, and Vocera Platform 6.5 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 maximum number of patients that a user can be assigned now has a default value of
40 patients in the "My Patients" area of the
This section provides information about fixes and improvements made to the
The following issues are fixed in
Restoring a patient linked conversation where the user who first made the association of the patient is inactive was causing inconsistent notifications. (XMPP-1036)
The following issues are fixed in
If a conversation was purged from the Conversations dataset, but still had messages attached to it, then the adapter misidentified the messages as undelivered and sent them to the user after they logged in. This issue affected messages, specifically old alerts, that did not have read receipts. (XMPP-1104)
This issue has been fixed. If active messages are attached to a purged conversation, the messages are not sent to the user upon login.
The following issues are fixed in
The adapter incorrectly logged out the V5000 badge after a user logged into
When a user within a group sent a coverage request to another user in the group, the adapter was expiring coverage automatically after coverage was activated in Android or iOS. (XMPP-768)
After a user logged out, the adapter was sending push notifications to the next user logged into the device. (XMPP-956)
This section provides information about known product defects and limitations in the current release.
When a covering user is not part of a conversation, the coverage system message (for example "User A is being covered by User B") is not sent to the other users in the conversation. (XMPP-769)
By design, the adapter handles this functionality based on presence updates.
A collaborator is added to a multiuser chat automatically after a multiuser chat is created. (XMPP-771)
By design, when one on one messages are included in the coverage policy, the expected behavior is to convert the conversation to a multi-user chat with the collaborator automatically added.
A user can accept or decline a coverage request or templated event that they created. Users should not be able to accept or decline their own coverage requests or templated events. (XMPP-972)
When a message recipient's Android device has the
This issue occurs under the following conditions:
This issue occurs under the specific conditions outlined above. If you are using Android devices, we recommend that you remove the 'urgent-alarm-playtime' custom parameter.