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.

Atlassian doesn't care anymore. Not sure why we're still paying thousands of dollars a year for them to implement feature we need if they are just going to ignore our needs.

Sorry to be going over old ground here, but just so I'm clear

• for cloud customers, the Service Pack for SD offers a way to address this gap
• for download customers, we are waiting on Atlassian to include the functionality in a new release, whenever that may be

Is that correct ?

I for my part like JIRA because of it´s flexibility and configurability to any need. This recent tendency to "minimise the complexity" is something which worries me greatly! I think Atlassian is going the wrong way here, and if this continues JIRA 8 with ServiceDesk 4 will probably be a product I don´t want to work with anymore...

It's a pity to understand that feature which looks fine in your own service desk is only internal and you don't want to implement it for all your clients. This buttons are really important feature.
Please implement it for us as fast as you can.

This is an major issue for us in using the service desk as our customers need to be able to transition issues as we are able to do on your service desk. At this point we would be happy with the basic functions that you have implemented in your customer portal.

For Cloud

Service Pack for SD helps you

Hi. Do you have any plan for this property for customer portal. This is so so so important

during our evaluation we reached now a situation where
we have to decide "continue or break".

The backend side of JSD looks pretty cool and Jira underneath
is giving a great power and possibilies.
But the frontend side to the customer lacks a lot of features.

This feature is an absolute must-have for us.

Is there a rough timeframe for this feature?

Hi Edwin,
Thank you for The update.

Even though your own service desk is highly customized, then I still do not get why you leave out functionalities in JSD which your support team is clearly using.
If you haven't already done it, then I suggest you talk with your own supporters to understand what features they need, and already uses, for their service desk.
Next step could be to make a confluence page with a list of those features, where we (customers) can add our votes to the features we would like in JSD.
By doing this I believe you get the most important features covered for making JSD the perfect service desk.

For this issue I believe you have received plenty of feedback in regards to what transitions we would like a customer to do, so now I personally hope this feature will be in the next update of JSD

+1 for Andrew's comment

In addition to the use cases for escalating, closing, reopening, it looks like an ability to pause / freeze a request is also another one that I’ve heard from you. Thank you for sharing your use cases.
In considering how we can support this feature request, we’ll be directing our focus to solving these use cases first. As some suggested, our likely approach will likely focus on transitions that do not involve workflow transition screens first.

Again, why not give us the freedom to choose what transitions we want available to our customers? Why limit it to a set of pre-defined transitions? Transitions which require a screen may add an extra click for the customer, but let us choose whether we want that or not.

Thanks for the update, Edwin!

Hi all,

Thanks for all your feedback and responses since our last update on this ticket. In addition to the use cases for escalating, closing, reopening, it looks like an ability to pause / freeze a request is also another one that I’ve heard from you. Thank you for sharing your use cases.

In considering how we can support this feature request, we’ll be directing our focus to solving these use cases first. As some suggested, our likely approach will likely focus on transitions that do not involve workflow transition screens first.

At this stage, I can assure you that our team is well aware of this issue and it is high on our agenda.

There have also been some a few questions about our usage on support.atlassian.com and why it is different to JIRA Service Desk. To explain, JIRA Service Desk is a product designed to address as many of our customers’ needs as possible in the best way possible - but that is not the objective of support.atlassian.com. support.atlassian.com is (and actually always has been) a highly customised instance of our products - most of the customisations predate even JIRA Service Desk itself. There are many peculiarities of support.atlassian.com that will make it impractical for us to ship as is - e.g. it expects a “hardcoded” set of transitions, fields, etc. For the JIRA Service Desk we want to ensure we are shipping the right product.

Thanks!
Edwin Wong
Service Desk Product Manager

Expecting this functionality soon, As customer should be able to resolve the issue, if further action not needed from support...

OK now someone from Atlassian need to come up with answers.
JSD 2.3 has just been released and these are the issues resolved.
JSD-269 got 198 votes, good to see that it has been resolved. Now we just need to see this issue be part of next release.
@atlassian, please give us an update here!

Atlassian it would be great as well to respond how many customers MUST suffer that you work on some improvements ?
This case has 250 votes. So 250 customers suffer and you provide this functionality in your own portal.
There you have a "reopen this issue" link.

I fully agree with the feedback from the other customers.
I guess atlassian changed over time from a company providing good tools for customers to a company wanting to get most
money from customers with minimum effort.
I 100% agree that several base requirements are not fulfilled with the product and you have to wait years to get if at all
some improvement.
This is not how it should be. If atlassian claims to follow "eat the own dog food" philosophy than really do it.
The customer portal looking like service desk has plenty of functionality which aren't available for the customer.
It's clear why as the base product is missed plenty of base features and would not be sufficient.

Unluckily we customers recognize all this gaps too late and so you have to suffer or switch to another product.
This costs as well money.

So it would be great if the product manager sometimes ready this posts here and atlassian changes the way to focus on providing
features which MUST be in place.
The same is valid as well for confluence. We have plenty of plugins we need to somehow handle this product.
Bulk Labeling for example, Bulk Changes of pages

Yep that has been raised a couple of times.
I have even complained to Atlassian support about the missing functionality is found in a plugin, which will cost me 1000$ more. Support directed me to this issue, so here I am together with the rest of you

Actually it might be the functionality that comes with ServicePack for ServiceDesk (https://marketplace.atlassian.com/plugins/com.intenso.jira.plugins.jsd-extender) as buttons are the same - a paid plugin unfortunately.

They are using JSD, with their own customizations, which aren't included in JSD for their customers.

@Charis Psarropoulos
from the bottom of my last support ticket:

What I don't understand is that a crucial tool like this is not being tested by a select group of customer of Atlassian (with a discount on the price). So this group of customers can give feedback to Atlassian in what works and not. Even address if something is missing. Atlassian can decide what they want to fix/adjust or not. And when all works fine then and only then Atlassian can put this on the market.
Right now I (as a customer) get the feeling that this product is not finished and is missing crucial elements and functionalities.

I really hope Atlassian will improve their test possibilities and there way of communicating with her customers. I would suggest to be more open about issues that are created and when an issue will be fixed. Don't use a voting system if this is not a leading part of your process.

Atlassian please be more open and transparent and customers will understand you better and they will become more patient (manage the expectations and try to unburden your customers).
I really love the applications that you made Atlassian but please don't ignore your customers and make sure you do it right or not at all.

I have been on this thread for a long time now. Atlassian has been ignoring this. We got one comment from them I believe in December of last year but no indication of where they plan to go. I have a deadline of the end of this month and I will then start to look at alternatives to Jira. I cannot run my business as is with SD and the cost of going to the next level of Jira with the added costs of the add-ins for the next level is out of the question. Appears we can be here moaning and groaning but it has not made any difference in the past 8 months. I am very disappointed of the lack of customer service and lack of communication from Atlassian. What a way to run a business. Must be that there is no competition? I do not know in that I have not searched yet.

I'm kinda tired being treated like a milk cow beta tester here..
Atlassian, take a stand and communicate

I completely agree with @Matt Sommer's speculation. In fact Matt beat me to it for posting this revelation. Disabling transition for customers is the only "Band-aid" solution Atlassian has, to work around the licensing issue.

So we are kind of barking up the wrong tree here.

Just mentioning that as Atlassian themselves have claimed, they are NOT using SD for their support, only a highly customized Jira instance. So, these functions are not there for Atlassian's SD, since there is no such thing (comment made 29/Oct/2014).
Having the ability for the customer to proceed within the workflow through the SD interface is essential for us too and it is a serious point of consideration during our SD evaluation.

We use JIRA for projects with our clients. We esimate the issue in JIRA where the client can accept the estimation (psuhing it truth the workflow). This is issential functionality for us to start using Service Desk instead, which has a far better customer experience then JIRA with all the options shown to our clients.

@Jon Leiberman - I agree entirely. It doesn't look good to have a more fully featured product being waved in front of our noses without giving customers the ability to benefit from those features too. It's concerning as to how much time is being spent on customising the product for their own in house use vs use for customers, particularly when it takes so long to implement highly voted for features into the product.

Customer should definitely be able to resolve the issue – it's just core functionality

Sorry If I came off the wrong way.
I accept it's a new product and that we're early adopters.
My point was that the only reference implementation one can see is the use of SD by Atlassian.
That implementation has multiple features that are not available to paying customers – which you don't find out until you're way down the roll-out road. That part is bad behaviour.

I'm just speculating here but it seems obvious this isn't being implemented because of the new licensing mechanism that's being used; service agents. The original licensing mechanism was similar to the other add-ons which made it cost prohibitive for many companies (for instance if there are 5000 users but only 10 people transitioning issues). To address this they added a Service Agent role that can transition issues (so you'd only have to pay for 10 users instead of 5000). The fall-out of this is that you can't allow users to transitions issues from the portal if they aren't service agents because then it would be a loop hole in their licensing (a service agent could transition tickets from the portal instead of full JIRA). So, adding a band-aid they are proposing adding pre-determined workflow transitions so they can control which Roles can execute them thus not opening a loop hole.

tl;dr: this feature relates directly to the JIRA Service Desk licensing mechanism and probably won't get implemented the way ya'll are asking for unless they change the way the tool is licensed.

It seems there are many pretty fundamental features that prevent the product being rolled out to customers. Our biggest one is the lack of focus on email rather than portal ticket management. Plain text email is not an option (which for blind users is a necessity), nor is email customisation, and the main killer for us is there is no way to CC other people into emails which are then created as tickets, and for those people to be involved in the ticket without having a user account in JIRA/SD (in other words, we need it to behave like normal email correspondence).

It is frustrating, but the product is in it's early stages. I think a lot of the issues stem from lack of observation of competing products and their fundamental features, not enough user feedback done prior to the product being released, and the fact that it's really just an add-on when it should be it's own stand alone product as there is too much conflict between JIRA and SD and other add-ons and SD.

Just my two pence...

We feel your pain. We did roll out JSD today and will stick to it, hoping Atlassian is shwoing us some love, but it's a real bummer they
didn't implement such critical and important features from the go. Let's wait and hope for the best.
I know, this might not be the ideal solution for everyone, if at all

The issue I have is that we evaluated Atlassian's implementation of Service Desk in order to make a decision to roll it out.

So we have spent money deploying this based on a product representation which is not accurate.

We should receive a significant discount based on degraded functionality. We can't use one of our Desks at all without this functionality. We didn't know that until we started roll out and had to pull it back.

Months? Try decades... https://jira.atlassian.com/issues/?jql=project%20%3D%20JRA%20AND%20resolution%20is%20empty%20ORDER%20BY%20created%20ASC%2C%20resolution%20ASC

For example, this highly voted (1649) feature is almost 11 years old with no resolution: https://jira.atlassian.com/browse/JRA-3821

I had the same response when I raised a ticket about it a few months ago.

What irritates me about it is that Atlassian clearly see that Service Desk functionality is lacking, so therefore add the functionality in for themselves to use, but when customer repeatedly ask for these features, nothing happens for months on end. Adding options to the portal for customers to have more control over their tickets should be fundamental to the user experience of the portal.

Exactly my point.
I too pointed this out to Atlassian support.
One would assume the Service Desk used by Atlassian is the same you can by from them!

Furthermore, Atlassian is prioritizing the issues based on what users want, and this is done by choosing the ones with the most votes.
Looking at this query in their own JIRA instance, then I would expect to see this issue in the next release:
https://jira.atlassian.com/issues/?jql=issue%20in%20votedIssues()%20AND%20resolution%20%3D%20EMPTY%20order%20by%20votes%20desc
JSD-40 is no. 8 in the list and no. 1 if you only look at issues for the JSD project.

Hi,
please deliver this:

• Escalation of a request - allowing the customer to escalate this request when it is becoming critical, or their needs are not being met.
• Closing a request - allowing the customer to close off the request when it is finally resolved, or when they no longer require that request.
• Reopening a request - the customer can come back to a closed request and mark it re-open it.

I just raised the ticket asking how to configure it, seeing the buttons on your service desk and the response is - this is not a part of the product now. What?

I expect that fixes which your team use in production to make the system more usable should exist at least as workarounds for customers also.

Why not to incorporate your own fixes? This is what I have got from your support personnel today:
The ServiceDesk that we used for our support system is heavily customized for our customer usability

This thread has been going on for a long time and has been ignored for the most part by Atlassian. Maybe your prod will help.

Good question, I really hope we're able to enable these functions somehow. Atlassian way too often seem to forget what listening to their loyal and well paying customer base means...

Huh, why is this functionality present in Atlassian's own Service Desk (which also runs on JIRA ServiceDesk) but not in the end users' version?!

Our organization has an urgent need for our Service Desk "Customers" to be able to change the workflow status of their issues.

The good thing is we on this thread agree with you , Pedro. The problem is we cannot seem to get Atlassian to agree. If they do, we have not heard it yet.

I am really commited with the KISS principles and always try to do things as simple as possible, but I think that allowing customers to close or reopen their issues is a must. Apart from ITIL recommendations I think this is just logical.

I totally echo "Ben Bazian" comments.

BTW Atlassian released JSD 2.2 and if you look at the bug fixes and their corresponding votes, https://confluence.atlassian.com/display/SERVICEDESK/Issues+resolved+in+JIRA+Service+Desk+2.2 it's wierd they are still picking up low hanging fruits.

It appears they are more concerned about the looks and feel when the functionality is in doldrums, what an irony.

@Manuel Borja, IMHO we got the frame of the house without any of the internal plumbing. What we are asking for is not an add-on feature. It is a basic feature like the plumbing. I have no issue with specialized add-ons. I do have a problem with paying extra for basic functionality.

Manuel, your thinking has some merit but it is no good for us OnDemand customers, who lack even a workaround!

Some products in the market are like a big house. So you have to buy the big house. The problem is that maybe you just use the bathroom and one room but you payed for the whole house. Atlassian approach is the opposite and I think it is good. You can buy the bathroom and the room. If we compare the price of JSD + plugin against the price of competitor products, maybe we will opt for JSD + plugin. You buy in 15 minutes, implement in some days and you get years of awesome features. Just my opinion

Maybe Atlassian should just but Service Pack for JIRA Service Desk and incorporate it. As I have stated earlier, I am tired of purchasing all these add-ons to make the product work. I guess next time I buy a car I may have to buy the tires separately.