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.

Changing the pricing won't fix the limitations. Even if they made JSD free, it would be just as limiting. We want JSD to have the same flexibility and extensibility that Jira had 5 years ago. Atlassian's attitude towards customers has really changed and it's sad.

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.

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.

ronanl: We shouldn't have to pay thousands of dollars more for a plugin to give us a few buttons which should be part of the base Service Desk.

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.