This issue has been open for 12 years. Atlassian obviously use JIRA internally, I imagine you use the plugin to make your product bearable? You should disable all the non-standard addins so you can see what a pain your software can be for everyone else.
This really is a shame. This request is now 11 years old. Flexible wording and being able to brand every communication from a system is critical for any organization using a service desk. If we were aware of this limitation when we made our choice, we would have chosen another product from another company. There is a difference between being a satisfied customer, and being stuck.
Abomination!
This dumb comment utility has vastly superior text formatting and styling options than those provided in Confluence!
The ability to format text according to need and preference in a platform like Confluence requires no explanation — it is obvious to anyone who has ever used a word processor.
It is an urgent requirement that should have been met in the original release, not relegated to its longstanding neglected status.
Unbelievable.
I'm speechless to even try and make a comment here... but c'mon, I can do this! Just breathe... breathe...
Ok, Nathan Sturges, Jira's Product Manager, has it ever occurred to you that Jira is only as successful as it has been simply because it actually allows customization and flexibility???
Some people want simple - and I understand why Atlassian wants to push for next-gen. I, however, as a Jira admin, don't give a flying crock about next-gen. I'm an admin for a large corporation and we want complexity! We want to design complex workflows and solutions because of the complexity of the business. And by the way, I don't want other people to manage most pf my projects! Next-gen is not our thing here!
That said, what do you do with tens of thousands of users that are on the same situation as my company???
Oh, I know! The answer is you just ignore them! And ignore a ticket created in 2004 with almost 5k votes!
This is absolutely stupid. The proof this is a big need is the fact that you actually have this feature in Jira Server! Yes, you can create priority schemes and define different priorities per project - which is something OBVIOUS (even thou it's obvious, I'll explain -
In your instance you might have projects that have a completely different approach - i.e., projects that are Service Management, others are business, others development, and so on. That said, I will most likely want to see priorities in a different way. For instance, for product support it might look something completely different that what it looks like for development - which is actually I use case I've seen for every single company I worked for/with in the last 20 years.
All that being said, your comment about simplifying is a non-sense. It might make sense for next-gen people, but what is actually the percentage of your users that are next-gen customers?
The decision to be complex and simple MUST be mine, as a user of this tool! Therefore, Atlassian's responsibility it to build a tool that allows for complex and simple. Not just try to amputate the legs that have take you this far!
That's my two cents - which I'll give to you for free today. You're welcome.
Figured I'd come back here for my annual check-in on this ignored request. This is no longer a feature comment section, it's a public forum for the discouraged & exasperated Jira admins/users that are fed up with Atlassian's MO of willful ignorance & screwing over their existing customers.
They're pushing simplicity for Cloud & leaving complexity/customization for DC.
All of the customers/organizations that naively migrated to Cloud (before discovering all of the gotchas & functionalities lost) will be migrating again to a better solution after Atlassian makes Jira Cloud the McDonalds/Walmart of issue tracking. They'll be eventually phasing out all remaining native complexity & customizations to further align with *every* Cloud "solution" scheme .... put anything/everything useful or connective behind additional PAYWALLS.
Turns out all the promises & hype of the Cloud was just a smokescreen for taking away all the controls from users, locking in subscription license revenues, pushing a bunch of hokey-pokey features that nobody asked for (emojis & team-managed projects??) all while conveniently ignoring practical & useful requests backed by thousands of votes & comments.
See ya'll here next year!
It's been a while since I've been this upset over a UI change, but this is right up there with the fiasco of the Microsoft Skype UI change that had people switch to competitors overnight.
*This change will be added to University textbooks as a case study of terrible UX design to be studied for the rest of time.*
I sincerely hope that this extremely ill-conceived ‘improvement’ will be rolled back asap. More importantly, *Atlassian should conduct an* *internal investigation into the decision-making process behind this update* — specifically the methods and criteria the responsible team used to assess the "positive" impact on the user experience.
I'd just like to point out that Atlassian have rolled out AI, which must have taken months, and which is frankly dangerous. I asked it several times to tell me what an acronym stood for. This acronym was known to me but not documented in our Confluence space. Over each request it MADE UP a different definition for the acronym, complete with explanation, and presented it as fact, with each definition explicitly not existing in our space. Cool.
The point being that Atlassian have spent considerable resource making something that doesn't work instead of adding basic, but essential, features such as are requested here.
My issue is also that some customers send 4 social media logos plus their company logo. Not only does that give me 5 attachments I have to delete one by one each time the customer replies, the Comments section gets really unruly with lots of scrolling past huge written out image links and logos blown up to fit the width of the comment field. It's like a tower of logos after every reply. If I clean up the comment, the customer will get notified (public) or I'll hide their comment from them in the portal (internal). Both is undesirable. Some customers switch between email and portal use. Overall 3 out of 5 come in via mail, and 2 of 5 via the portal.
h2. +1 SUPPORT CUSTOM WORKFLOWS
The ability for a Project Group Administrator to define/manage custom workflows is critical for our team's operation. It is silly to require the global JIRA admin to juggle this for every single project they manage.
If there is some issue/concern about stability around this feature, then there needs to be a "rollback" capability so that Project Group Administrators can undo any changes that break their project.
why don't we all just stop telling each other how to do our jobs. in 10 years when Atlassian assigns someone to this, they will implement something that tells us all how we have to do our jobs.
This was a simple feature request to allow project admins to edit their field configuration values so we don't have to give 200 people Jira admin rights to do something so basic and somehow got bastardized into a workflow debate to which there isn't even an assignee. Removing my vote and un-following as these replies are getting to be more like spam than anything useful.
I am surprised this is not already built in. Managing project workflows versus managing system permissions and access rights should be very separate entitlements within the platform. How can workflows be considered 'jira administrator' function, many corporates now distinguish between service management and support versus project admin. I see this was raised 10 years ago, how many votes are needed to get it looked at ?
Unless Atlassian has some kind of secret no-compete agreement with the makers of the Enterprise Mail Queue plugin, I really can't understand how such a usability problem hasn't been addressed yet in the product, 12+ years and 600+ votes later. Long gone are the days of "Legendary support".
Folks, please stop with the general griping. It's clear that everyone's frustrated, but this doesn't really change anything...all you've done over the last couple of days is send 17 notification e-mails to the 293 watchers, which is ironic on an issue about "e-mail chattiness". I watch this issue to hear what Atlassian has to say about it, and what useful suggestions other users might have...I'm not really interested in the same complaints that users are writing on every issue lately.
If you have concerns about how Atlassian manages their releases (and I share some of them), engage with the product managers, or pay the extra money they now charge for "technical account management" (or whatever it's called). Grumbling here achieves nothing.
This issue has been open for 12 years. Atlassian obviously use JIRA internally, I imagine you use the plugin to make your product bearable? You should disable all the non-standard addins so you can see what a pain your software can be for everyone else.
This really is a shame. This request is now 11 years old. Flexible wording and being able to brand every communication from a system is critical for any organization using a service desk. If we were aware of this limitation when we made our choice, we would have chosen another product from another company. There is a difference between being a satisfied customer, and being stuck.
Abomination! This dumb comment utility has vastly superior text formatting and styling options than those provided in Confluence! The ability to format text according to need and preference in a platform like Confluence requires no explanation — it is obvious to anyone who has ever used a word processor. It is an urgent requirement that should have been met in the original release, not relegated to its longstanding neglected status. Unbelievable.
I'm speechless to even try and make a comment here... but c'mon, I can do this! Just breathe... breathe... Ok, Nathan Sturges, Jira's Product Manager, has it ever occurred to you that Jira is only as successful as it has been simply because it actually allows customization and flexibility??? Some people want simple - and I understand why Atlassian wants to push for next-gen. I, however, as a Jira admin, don't give a flying crock about next-gen. I'm an admin for a large corporation and we want complexity! We want to design complex workflows and solutions because of the complexity of the business. And by the way, I don't want other people to manage most pf my projects! Next-gen is not our thing here! That said, what do you do with tens of thousands of users that are on the same situation as my company??? Oh, I know! The answer is you just ignore them! And ignore a ticket created in 2004 with almost 5k votes! This is absolutely stupid. The proof this is a big need is the fact that you actually have this feature in Jira Server! Yes, you can create priority schemes and define different priorities per project - which is something OBVIOUS (even thou it's obvious, I'll explain - In your instance you might have projects that have a completely different approach - i.e., projects that are Service Management, others are business, others development, and so on. That said, I will most likely want to see priorities in a different way. For instance, for product support it might look something completely different that what it looks like for development - which is actually I use case I've seen for every single company I worked for/with in the last 20 years. All that being said, your comment about simplifying is a non-sense. It might make sense for next-gen people, but what is actually the percentage of your users that are next-gen customers? The decision to be complex and simple MUST be mine, as a user of this tool! Therefore, Atlassian's responsibility it to build a tool that allows for complex and simple. Not just try to amputate the legs that have take you this far! That's my two cents - which I'll give to you for free today. You're welcome.
Figured I'd come back here for my annual check-in on this ignored request. This is no longer a feature comment section, it's a public forum for the discouraged & exasperated Jira admins/users that are fed up with Atlassian's MO of willful ignorance & screwing over their existing customers. They're pushing simplicity for Cloud & leaving complexity/customization for DC. All of the customers/organizations that naively migrated to Cloud (before discovering all of the gotchas & functionalities lost) will be migrating again to a better solution after Atlassian makes Jira Cloud the McDonalds/Walmart of issue tracking. They'll be eventually phasing out all remaining native complexity & customizations to further align with *every* Cloud "solution" scheme .... put anything/everything useful or connective behind additional PAYWALLS. Turns out all the promises & hype of the Cloud was just a smokescreen for taking away all the controls from users, locking in subscription license revenues, pushing a bunch of hokey-pokey features that nobody asked for (emojis & team-managed projects??) all while conveniently ignoring practical & useful requests backed by thousands of votes & comments. See ya'll here next year!
It's been a while since I've been this upset over a UI change, but this is right up there with the fiasco of the Microsoft Skype UI change that had people switch to competitors overnight. *This change will be added to University textbooks as a case study of terrible UX design to be studied for the rest of time.*
I sincerely hope that this extremely ill-conceived ‘improvement’ will be rolled back asap. More importantly, *Atlassian should conduct an* *internal investigation into the decision-making process behind this update* — specifically the methods and criteria the responsible team used to assess the "positive" impact on the user experience.
I'd just like to point out that Atlassian have rolled out AI, which must have taken months, and which is frankly dangerous. I asked it several times to tell me what an acronym stood for. This acronym was known to me but not documented in our Confluence space. Over each request it MADE UP a different definition for the acronym, complete with explanation, and presented it as fact, with each definition explicitly not existing in our space. Cool. The point being that Atlassian have spent considerable resource making something that doesn't work instead of adding basic, but essential, features such as are requested here.
My issue is also that some customers send 4 social media logos plus their company logo. Not only does that give me 5 attachments I have to delete one by one each time the customer replies, the Comments section gets really unruly with lots of scrolling past huge written out image links and logos blown up to fit the width of the comment field. It's like a tower of logos after every reply. If I clean up the comment, the customer will get notified (public) or I'll hide their comment from them in the portal (internal). Both is undesirable. Some customers switch between email and portal use. Overall 3 out of 5 come in via mail, and 2 of 5 via the portal.
only 17 years and counting since this was logged
h2. +1 SUPPORT CUSTOM WORKFLOWS The ability for a Project Group Administrator to define/manage custom workflows is critical for our team's operation. It is silly to require the global JIRA admin to juggle this for every single project they manage. If there is some issue/concern about stability around this feature, then there needs to be a "rollback" capability so that Project Group Administrators can undo any changes that break their project.
why don't we all just stop telling each other how to do our jobs. in 10 years when Atlassian assigns someone to this, they will implement something that tells us all how we have to do our jobs. This was a simple feature request to allow project admins to edit their field configuration values so we don't have to give 200 people Jira admin rights to do something so basic and somehow got bastardized into a workflow debate to which there isn't even an assignee. Removing my vote and un-following as these replies are getting to be more like spam than anything useful.
I am surprised this is not already built in. Managing project workflows versus managing system permissions and access rights should be very separate entitlements within the platform. How can workflows be considered 'jira administrator' function, many corporates now distinguish between service management and support versus project admin. I see this was raised 10 years ago, how many votes are needed to get it looked at ?
Unless Atlassian has some kind of secret no-compete agreement with the makers of the Enterprise Mail Queue plugin, I really can't understand how such a usability problem hasn't been addressed yet in the product, 12+ years and 600+ votes later. Long gone are the days of "Legendary support".
Folks, please stop with the general griping. It's clear that everyone's frustrated, but this doesn't really change anything...all you've done over the last couple of days is send 17 notification e-mails to the 293 watchers, which is ironic on an issue about "e-mail chattiness". I watch this issue to hear what Atlassian has to say about it, and what useful suggestions other users might have...I'm not really interested in the same complaints that users are writing on every issue lately. If you have concerns about how Atlassian manages their releases (and I share some of them), engage with the product managers, or pay the extra money they now charge for "technical account management" (or whatever it's called). Grumbling here achieves nothing.