I'll join the chorus of "looks great ... estimated delivery date??" This has been a long time coming and many of us (customers) are blocked from making much-needed improvements. My IT department is currently re-evaluating whether to remove JSD and build our own portal since our (all internal) customers are howling about how limited their experience is with the "IT Helpdesk" project versus their own (non-JSD) JIRA projects. (The only current alternative is to make all 500 of them "service desk agents" and that's cost-prohibitive.)

Ah is it just the comment that will be available in the transition screen? Or any field that we add on the transition screen from the workflow designer?

Good news !
What about adding some custom fields to the transition screen other than comments ?

Great news! With this design, can we "rename" the transition that we show on the Customer Portal? (this is not a major need for us right now but it could be interesting)

Excellent - looking forward to it.

Will approve issues also be available?

Edit: according to the survey approve is included

great, when please?

Vincent that is lovely that is a super cool update. Love it!

This is brilliant! I took the survey already!

Looks good! When?

So simple and elegant!

Hi all!

Just thought we will give you guys a sneak peak into what is coming. Since the last time we updated our design team have came up with some design for this feature! We want to hear your thoughts on them and here's a survey for you to give feedback: a short survey.

I have attached some screenshots on this ticket with our designs.

1. The first screen shows how the feature will be configured. You can select any transition on the workflow editor and make it transition-able by customers

2. The second screen show that the user can select the “close request” transition which was set up previously

3. The third screen shows what happens after the user selected “close request”, a dialog appears which allow the customer to leave an optional comment

4. The forth screen shows what happens after the user close the request, the request is transitioned and the comment is added

We love your feedback, so please fill out the survey!
Cheers,
Vincent

C'mon Atlassian, give us some answers pleeease
I open everyday this ticket to see if there is any mouvement...

This will be very useful to have. This is the (only) thing we feel is missing in your (totally good) OnDemand version of ServiceDesk!

this feature is currently on our roadmap

What does that exactly mean??
Can we, your customers, see this wonderful "roadmap"??

This will be great and will enable us to incorporate approval process in the service desk.

Anyone is facing the issue JSD-3189, or it's just me?

Been hearing this for 2 years already.

Hi everyone,

Thank you for all the responses so far!
We understand the importance of this feature. We just want to let you guys know that this feature is currently on our roadmap and we are working on it.

Cheers,
Vincent

This would be a wonderful feature to add, in fact I'm surprised it's not already available. Let's git 'r done Atlassian!

I am appalled that Atlassian is selling, for quite bit of money, a customer service portal without these described features.
If the customer cannot interact with issues in any meaningful way besides commenting, then what we actually get is a message board.
Arguably, this is not completely worthless, but certainly doesn't justify $20 / agent.

We will be ditching this product until it's ready for prime time.

This is a very critical and a must have feature in any service desk system. The customer should have the option of re-opening a case when he want. Moreover, it's part of ITIL, which is a framework used worldwide now by a huge number of companies. It's not acceptable by all means to leave such important functionalities in the IT world anymore. When we can have this ready?

In our case we are not willing to delete neither issues nor user comments at the customer portal.

If only We could have buttons for the users in order be able to move the issues from one state to another ...
(considering permissions of course). That would really make the difference for the customer portal, making it really usable.

We certainly do not want our customers to delete issues or comments. When customers collaborate and/or participate in issues all information should be contained. Deleting issues has implications on reports, SLAs and makes auditing less effective. If needed (e.g. a customer posted privacy sensitive information) an agent should edit the comment.

We want our Service Desk Customer to do following things:
Create issue
Comment issue
Add attachment
Edit issue
Close issue
Delete his/her issue
Delete his/her comment
...

According to JIRA Project Permission (see attached screen), Service Desk Customer - Portal Access should have permission to do lots of things. But right now, our Service Desk Customer can only do

Add a comment
Add attachment

I think the problem related to this issue, right? Please let me know if not.
Thanks!

We need also this feature, for us this is a blocking issue to use JSD for our clients.

C'mon give us an estimate pleeeaaaassssseeee, it will be like a xmas gift if you'll do it this month

Dear Huynh,

I also voted for this issue, because it is essential for our department. Please let us know, when this feature will be added.

It haven't to be complicated, since the Service Desk of Atlassian implemented this feature.

with best regards and many thanks,

Ali

Hi Joseph and Aliakse,
We voted for this issue. We really hope it will be implemented soon. It is critical for us and it is provided with other service desks such as Zendesk. Our company wishes to keep track of as many things as possible within JIRA because it is a great tool. Hence, we are willing to extend our subscription to more adds-on and licences, but we are also open to consider other solutions if an adjusment is not delivered in a near future.

Thanks !

it's quite possible that atlassian is using the Extension for JIRA Service Desk plugin

Definitely no, since the nature of Extension for JIRA Service Desk plugin is to take transitions on behalf of one dedicated user, while Atlassian Support Service Desk allows customers to act on transitions on behalf of themselves.

it's quite possible that atlassian is using the Extension for JIRA Service Desk plugin

Atlassian is using it on it's own Service Desk... so there is no need of adding more reasons. They know it's a must for a Service Desk application.

We need to be able to let customers approve an issue. Voted

I'm in favor assuming that we can limit which transitions the customer is allowed to execute and which the customer isn't

I am really frustrated with Atlassian that they turn JSD into a product that just works best for them. They play dead when us experts tell them about the things our customers need and want. They even took one of the most useful tools in the marketplace (Vertygo SLA) and managed to turn it into something utterly unusable. How am I expected to tell the customers "if you want to measure SLA targets, you have to buy a 30K$ add-on?"

Considering Atlassian have this feature in the service desks they make public, i'm surprised this hasn't been delivered yet.

While I would really like this feature, in the meantime i've had to use automation rules on customer comment to re-open a ticket into a new status, not ideal but it's getting us a little step forward.

Agreed. I am pretty sure we have given up on SD. We are starting to migrate away from it. Have waited too long for a usable product.

It is almost useless if we do not have this function.

I am glad to see this in the description field:

...At this stage, we can re-affirm that addressing the key use cases around closing and reopening is on our roadmap to deliver.

I've recently submitted a request for support on Confluence, and naturally it uses Service Desk.

What I don't understand is that on that portal, I'm allowed to Add a comment, an attachment, or ... Resolve the issue.

(There's also some automation to freeze the issue after a while, then unfreeze)

It's really quite neat, and it's apparently done with Service Desk 2.4.3.

So it must be possible to do it?

Over one year? You mean only one year.

https://jira.atlassian.com/issues/?jql=project%20%3D%20jra%20AND%20status%20not%20in%20(resolved%2C%20closed)%20and%20votes%20%3E%3D%20100%20ORDER%20BY%20created%20ASC

just bugfixing and including automation (regrated addon), for one year or more !!!!

is their any public roadmap of ServiceDesk ?

how long does it keep to implement this little feature ? We still waiting over one year... afraid

We would also like the ability to give users access to transition a ticket from one status to another.

for our environment we want to be able to configure which transition should be visible for the customer.
Not only close/reopen.

It's problematic for a software development company to provide a public version of its product that contains unreleased functionality. Use beta features internally, not externally.

Yes, some things are really frustrating and Atlassian has to deal with becoming a massive company and the challenges that come with it.
However, some of the comments here sound more like disgruntled children complaining about the lack of ice cream in their lives. Not sure that's helping anybody.

no apologies needed lukasz.watroba. We totally understand, and will do everything we can to improve the product experience.
close/reopening workflow transition is on our roadmap now, just need a bit of time.

@aculver, we do care mate.

Well, maybe I was too harsh, so sorry for that.

I think that you should change that pricing model - because it is the main reason of frustration here - by not limiting possibility to assign, change transitions for clients and other Jira users.

You have here great software but you are limiting its usability in a really bad way, by creating limitations that are simply artificial in a worst possible way - not by providing to agent additional possibilities and functionalities but by limiting possibilities of other Jira users and SD customers in a project. Explanation that you are working on different functionalities doesn't mean that such a simple switch is hard to progress - it is just a way to cover/hide a bad pricing model that you are not willing to change for two years.

And from the client point of view - you are making those functionalities exceptionally costly (in a money and in a time of users), especially in some implementation circumstances.
Check the voting bar and you will see that I am not the only one who thinks that way.

thanks for feedback lukasz.watroba Wątroba. I'm truly sorry you feel this way.

And btw - this ticket is not a duplicate for JSD-917. That way you are limiting request.

We would like to have an ability to grant transition issues permission not only for customer but also for Jira users other that agents. There come several words that appear in my mind in current situation: dumb, stupid, harmful. The situation when Service Desk blocks an ability to transition issues to other groups makes that tool unusable, especially if you wish to integrate first and second line of support in an efficient way.

Greed and pride comes before fall.

Joseph Huynh - I do not think that such cheap talk can convince anyone here.

As JIRA Service Desk is still a very young product, we'd be happy to help beta test it using free beta testing licenses. As a reward for our help, we'd be happy to accept half price licenses for 2 years once JSD is ready for official release and production use.

I would also like escalation, closing, reopening options for customers.

Ideally the customer could be presented a screen as well.

Scenarios:

• Add a brief satisfaction survey when a ticket is closed, so rather than emailing a separate survey link being able to capture this on close would be extremely useful.
• Support requires more information and can send the workflow down a path so the customer can complete the structured data.

ajk, madhusudhan.matrubhai, kevbuy

https://jira.atlassian.com/browse/JSD-466 will be made available to you on 2.6.0-OD-06 in the upcoming weeks.

Thanks @Kevin Wise, that tip was very helpful. You Rock !!!

Alf - I resolved part of that by adding a line to ${JIRA_INSTALL_DIR}/atlassian-jira/WEB-INF/classes/outlook-email.translations (see below)

# cat outlook-email.translations
---- Original Message ----
----Original Message----
----Original Message Follows----
---- Original Message Follows ----
----Ursprüngliche Nachricht----
-----Ursprüngliche Nachricht-----
---- Ursprüngliche Nachricht ----
_____
From:

It's not perfect (you still get signature picture spam sometimes), but better than having to buy a plugin

Or JETI...

Anyways, JIRA Service Desk mail handler does not parse away all the rubbish that a e-mail reply has. To do that you need to buy another plugin (JEMH) ....

Using email as a follow up defeats the purpose of using a ticketing system. I want the full history of an event in Jira. IMHO, that is a workaround in that the product has deficiencies.

Look at what they have done, plus no one is being forced to use these tools ..

We all want flexibility buddy

We have installed the Service Pack for JIRA Service Desk plugin on our instance and after 30000 issues in our main SD project only 104 have used the reopen issue workflow transition on the customer portal.

What i see from our users is that when they have created the issue over the customer portal any further interaction from the customer (he provides more input, means resolution not workling, etc.) is done by email and not trough the portal.

So i can understand the current Atlassian approach of automation (customer comment -> transition to something else or customer comment after resolve -> reopen the issue) which we habe configured trough different ways.

Darren: We know what we want a lot better than Atlassian does. They should give us the flexibility to configure things like this to suit our needs, as they've done with the rest of Jira. For some reason, they're not giving us the same flexibility in JSD.

I don't agree with allowing portal users having transitions other then Resolve an issue if it was self resolved/opened in error.

The portal for me is to have it as simple as possible, if it becomes over complicated we may as well just use JIRA.

Though I would hope if this is developed we have the choice to do either.

We have to consider that Portal Users don't take a license, if they are then able to do what a Agent can do surely the license costs will increase to compensate.

For us, the real issue is that we have 23 agents at $25 / month. That's nearly $7000 / year.

The discussed feature is demonstrated in the Atlassian implementation of this product, which we evaluated. The feature is required for our workflow. All of our customers are internal and were expected to transition their requests (close and re-open in our design).

After paying and expending considerable time and $ on configuring the product, the feature was not there. There is effectively no reply to this support discussion about it and no price consideration offered for the degraded (yet implicitly advertised through demonstration) function.

In the US we have false advertising, false claims, or 'bait and switch' (state) laws. This would never happen here without immediate attention from the vendor, a price reduction or nasty legal issues. I say so because of the price point and the scope of people effected. In NYC we even have City laws protecting us.

Since Atalassian is clearly not concerned about those implications, how about taking the personal responsibility involved with showing this feature in your implementation seriously, and standing behind your work and representations? I'm sure that the people who use your products stand behind theirs.

Watching this issue has caused us to seriously consider whether we should continue with Atlassian. The total dismissal of the issue at such a high price point has been an eye-opener.

Thank you Joseph for your Statement

Thank you Ben - i totally agree with you.

@Joseph Huynh, thanks for the response. I think much of the frustration here is that this thread has been going on for almost 2 years and there has been no real responses from Atlassian. I think yours was the first since last December. For one, I believe this requirement is a basic must have. How it has lingered for 2 years and not made it into the numerous updates that have been rolled out is mind boggling. If Atlassian plans to add this a target date would be appreciated. If you do not plan to add it I would rather know now than later.

IMHO, Altassian has failed "Communications 101".

There is one way to get transition links on the Service Desk. You can enable HTML on the Wiki Render plugin. You could then add a comment to the user:

{html}
<script type="text/javascript">
var data = {
    transition: {
"id":"41"}
};

JSONTest = function() {
    $.ajax({
contentType: "application/json",
        url: "https://XXX/rest/api/2/issue/12345/transitions",
        type: "POST",
        data: JSON.stringify(data),
        dataType: "json",
        success: function (result) {
            switch (result) {
                case true:
                    processResponse(result);
                    break;
                default:
                   console.log(result);
            }
        },
        error: function (xhr, ajaxOptions, thrownError) {
        alert(xhr.status);
        alert(thrownError);
        }
    });
};

</script>
Dear xxx,
<br><br>
Please <a href="#" onclick="JSONTest()">approve</a> or <a href="#" onclick="JSONTest()">deny</a> this issue.{html}

You could also create a custom field called "Action Bar". Choose WIki render for this field, add HTML and javascript that hides it on SD creation but shows it on SD view. That way all "actions" would be availiable at the bottom of the SD view.

However there are some security implications for this as enabling HTML is a XSS risk, but you could also create your own render plugin (copy the normal wiki one and rename it) and enable this render for your custom field only. This way you are in control who can create HTML. If you have the Jeditor plugin already, you can achieve this by enabling Jeditor render for your custom field "Action bar".

Hi everyone,

Thanks for all the comments. We do look at these at Atlassian and appreciate constructive feedback that's given.
We do take these suggestions seriously, and the reason we have not yet built this is because we have priorities to build other things.
Features like Automation, improving the customer portal, improvement of email response stripping, improvements of notifications, etc.
We know that many of you have voted and that is a very good indicator for us in terms of prioritisation, but it is not the only input into how we build the roadmap for our product. We have to consider many other factors.
Finally, we are still looking at this feature and this is something we'll be working on.

Thanks,
Joe

And yes.. i read the part of Q. Do votes matter then?
But i also do not understand why so many features with about to 15 or 20 votes will implemented and this is still on "To Do". (what ever that means)

And, yes .. i also read the comment from Edwin ... but i don't understand why implementing this feature shoud have any negative effect for JIRA Service Desk is a product designed to address as many of our customers’ needs as possible in the best way possible.

As aTlAsIaN dOeSn'T cArE said.

why not give us the freedom to choose what transitions we want available to our customers?

Thank you for that fast (OT) response.

I have one question regarding your link to Implementation of New Features Policy and Please read our post on Atlassian Answers for a more detailed explanation.

Q: Are votes what determine the priority of a feature?
A:
[...]
Customer Support: Our support team provides clear insights into the issues that are challenging for customers, and which are generating the most calls to support.

This means for me it's better that each of us 369 voters creates a single request if we want a new feature instead of voting and commenting for one request.
Am I right??

Hey there. I am a watcher of this issue so I just thought I'd explain this before it is misinterpreted.

That screenshot does show the history of this issue, but that actually just shows when we transitioned from the New Feature and Improvement issue types to a single Suggestion one.

During that migration we have also removed the Priority field from Suggestions as the importance of a feature is not calculated based on the priority field of those issue, and hence to avoid this sort of confusion.

So this doesn't mean that it is a "Minor" suggestion, it simply means we do not use this field to choose what to implement as further detailed on our Implementation of New Features Policy.

Cheers,
Matheus Fernandes | Atlassian Support

HO-HO-HO! ))

Keep going Atlassian! Keep going! )))

Maybe nothing will happen here because for Atlassian this feature request is just Minor ..
I'm wondering how many ppl it needs for a higher priory. (See History of this request)
Over 360 ppl seems to be not enough for a higher priority as "Minor"

The other thing is Atlassian thinks the Affected Version of JSD for this feature request is 1.0 (See History of this request)

So, I think putting this issue on "To Do" is just nicer than to say "No, we don't realize it"

Why would anyone post asking for feedback from Atlassian? The 50 other requests went unanswered. Why should the latest one be any different? If I had the bandwidth I would switch away from any Atlassian products. I am very unhappy with their licensing model and lack of any attention paid to their paying customers. There will be a time in the future that this will happen. I just have bigger fish to fry.

It has been in "to do" status for 6 over months. I think "to do" means, let them think we care.

It was one of the reasons for us when we were making choise - cloud or self hosted server.
And we choosed self hosted server - much cheaper and we have that functionality by Service Pack for JSD.

We'd appreciate it as well to get a feedback from Atlassian about this. This feature should be standard for a service desk solution.

369

"To Do" status - I hope it means, that Atlassian will do it.
But it'll be great if they tell us someting about "When".

However, we are going to split Service Pack. You will be able to buy only transitions module. Does this sound good to you?

No.
Atlassian knows how to implement this very useful standard feature in JSD.
So why they only implement this for their own instance of JSD???
We have 368 votes for this feature here and nothing happens at Atlassian ... thats not really customer friendly in my eyes (I think they only want to make some additional money over marketplace fees (25%))....

I agree 100% with Marcel Faber. Though, I'm not complaining as JSD is a really good product for us. But paying that much for an automated transition ... seriously? At least for us, this will never happen.

I understand you well but at this moment the price has to match JIRA users, not JSD agents. Marketplace rules.

For us it would help more if one only had to buy Service Pack licensing to match JIRA Service Desk license and not JIRA. For us we have 25 SD licenses, but 500 JIRA licenses. Huge difference in price.

Well, when you take a look at other solutions on the market, you will find that Atlassian has still reasonable pricing. You complain a lot about missing transitions in Customer Portal but there is a solution - paid one. I understand that the price is not low, this is why we promotions.

However, we are going to split Service Pack. You will be able to buy only transitions module. Does this sound good to you?

lol .. Krzysztof, you're kidding, right?
closing, resolving, escalating requests on customer side should be a standard feature of an "service desk". And not one you have to pay extra money for it.
JIRA & Service Desk are expensive enough in my eyes.

@atlassian1263 You can grab 30% off the regular price.
The promotion is valid through July 3th.

You are correct. They obviously do not care. I am shocked with the amount of bad comments that have been expressed here and no response. Maybe Atlassian needs to get more "internet" bad press and then they will understand. I have been following this thread for about a year and I love it when a newbee posts the same complaints we have had for a long time. They actually think their post will elicit a response.

atlassian1263: You're kidding, right? Atlassian doesn't care about that.

When do we get this features??
It's kind of ridiculous that we should pay additional 3,000.00$ (in our case) for the feature that customers can close or reopen service desk requests!

@Nick me too. The Service Desk is really maturing as a usable enterprise tool and this would save us a lot of time, as clients have to request for it to be closed rather than just doing it themselves.

@Warren, yes i saw that. I asked the Agent who was dealing with my ticket but didn't get a response. Hope its coming soon.

I see that your own Atlassian Service Desk (Customer Portal) has this functionality now, so can you let us know when it will be publically available for our own service desk portals?

regards,
Warren Gunn

Hello,
I must say that I agree with the previous comment.
I would expect this to be OOTB in SD.
Customers must be able to close/escalate/repoen their tickets when applicable, else this adds extra workload on the service desk agents !!!
Best regards,
Kevin Gerard

I agree with base scenarios, but also that this is so basic it should already be there and be part of SD license.

Hello Edwin,

To answer your question about the use cases of having transitions that would be performed by end customers, is when the workflow has a status "testing" => we want the users to test the solution and then confirm if that works for them or not by either validating the test or sending back to support.

Thanks,
Imane Assoud,

As per my colleagues comment above, what are the chances you'll implement such a change, and when?

HI,

we are analysing service desk for use as a customer support portal for our organisation. We have been to now using the cloud based JIRA for our customers. Our customers are required to include detailed information when raising issues and are not naive users of JIRA. For the purposes of consistency we have a number of custom fields the customer must fill out in order to provide sufficient information. They like to have visibilty and as much control and input into the issues as possible (or we allow), so from our perspective the service desk portal is far too limiting.

We have complex workflows to fulfill our needs and have avoided custom or commercial plugins. Our displays have a number of custom fields, some of which the customer may edit via a workflow transition for users in specific project roles. Customers have the ability
to create issues, transition issues, add comments to assist with progression through the workflow and for request and provision of feedback which to us represents a stop the clock situation. Once an issue is created it is assigned to an engineer by the project lead, to be worked on through until resolution. The customer signs off on the resolution by closing the issue. We have the ability to hide comments by setting the permissions level i.e. the customer has permissions to see and do a subset of what the internal staff do based on the use of project roles and permissions schemes.

We require to be able to continue to use these workflows and simply add the SLA functionality into the situation.

Some more specific requirements from our perspective:

1) the SLA functionality should be stand alone (full service desk functionality not required) and be able to be integrated into JIRA cloud services
2) the SLA functionality should support calculation of response times and resolution times, and within this configure holidays, weekends and business hours and some states where 'stop the clock' is relevant e.g. waiting for feedback. The SLA functionality within service desk seems to fulfill these very well and we are happy with it, however currently it only supports states in the configuration. Allowing the use of custom fields here would also be beneficial to us. e.g. instead of having response time set by a transition from OPEN to IN PROGRESS, optionally being able to include the first comment or assignment to an engineer time may also be useful.

3) the SLA metrics shown on the page should be able to be able to be optionally hidden from the customer

4) the SLA functionality should not impact workflows and allow transitions, editing and creation of issues if so desired

I am hoping some of this might be possible and perhaps more easily done than modifying service desk itself. Would you kindly provide some feedback on the possibility of this occurring.

I am already looking at alternatives. I am tired of waiting and getting minimal updates.