7 December 2014 to 12 December 2014
JIRA Service Desk 2.2-OD-06
Let customers participate in each other's requests
Prior to this version, customers cannot see other people's requests. Requests are between customers and agents.
Starting from this version, agents can bring other customers into a request and let multiple customers take part in the conversation.
Agents will see a new field called Request participants on the issue, and can add anyone who's a customer of the service desk to the request. Participants will receive an email notification after they are given access to a request.
All participants, including the reporter, will appear in the People involved section of the request on the Customer Portal.
Request participants in the agent view and the portal view:
Request participants can add comments and attachments to a request, and receive the same notifications as the reporter. Participants can easily see who else is involved in email notifications too. This makes it easier for them to work from their inbox and they do not have to check the portal.
The Request participants field is a new custom field that will automatically get added to the screens of all existing service desk projects in about 1 to 3 hours after this version is released to your Atlassian OnDemand site. We decided to go with this approach instead of updating the screens along with the OnDemand upgrade because it shortens the site downtime, especially for sites with a large amount of data.
Changes to two SLA conditions
Since a request can now be visible to multiple customers and all of them can add comment and receive notifications, the following two SLA conditions have been changed to take participants into consideration.
- The "Comment: By Reporter" condition has been renamed to "Comment: By Customer".
It now means a comment by any participant on the request, including the reporter.
- The "Comment: For Reporter" condition has been renamed to "Comment: For Customer".
It now means a customer-visible comment by someone who isn't a participant.
These two comment conditions are still exactly the same for all requests where there are no participants, so won't affect calculation of existing SLA data.
Collaborate in context with inline comments
Comments on pages and blog posts are great, but what happens when you need to reference a specific sentence or word on a page? Inline comments are the answer.
Inline comments allow you to highlight the section of the page you're commenting on, and with one clickyou can start adding your comment and notify the page's creator, letting them know exactly what your comment is about. The page's owner will get a notification and can reply to your comment, opening up a conversation to keep your project moving. Text that has been commented on appears with a yellow highlight; click the highlight to view the comment and any replies.
We're not just talking about plain-text comments either. You can use many of the features of page comments in inline comments, like rich text, @mentions, images, and links. You can even paste-in JIRA issues to embed the JIRA issues macro.
Once you and your team have finished the conversation, you can resolve the comment and the conversation is stored with the page if you ever need it again. Choose> Resolved comments to reopen any resolved comments if you need to.
This replaces the old 'quote in comment' feature, as your comment is now linked to the text you highlight rather than quoting it as a reference.
Site-wide password policy features
This deployment introduces a new user management feature that allows you to control how complex all users' passwords must be. You can also control how often users must change their passwords. You will also be able to define the number of unique new passwords that must be used before an old password can be reused.
The password complexity requirements we're introducing use entropy. Entropy is based on an algorithm that measures the security level of a password. It takes into consideration not only the standard password-related attributes that you could define manually (e.g. the number of letters, capitalization, numbers, etc) but much more, including things like common dictionary words, names, l33t speak, keyboard patterns, commonly used passwords, etc. For these reasons, it's a much stronger method of password security than password attributes that you can manually define.
An entropy-based system is also simpler to configure and allows those with less technical know-how to configure their instance to be more secure. We want to provide it as a security feature that should be easily configurable by all admins.
We recommend this resource which is useful in breaking down the measure of entropy for a certain password, and uses the same entropy algorithm that we have implemented.
To access and set the new password policy features:
- Go to > User management.
- Select Password Policy.