And then I guess at some point they just removed the markdown part?
I make an effort to write detailed comments about what I did, what I discovered etc. This is really helpful to reproduce the issues, and a few months down the line it helps to clarify exactly what happened.
JIRA text editor is FUCKED. Try adding bullet points after a code insertion. Does not work. I have to first create all the bullets, then step through them and write out whats on my mind. For more complex stuff, I just write in my code editor. How can you fuck up the most basic functionality?!
This results in a fun game of me trying out single backticks, triple backticks, braces, double braces, other miscellaneous punctuation symbols, and various indents before giving up and trying the formatting toolbar, only to waste another couple of minutes clicking around to see what works.
Somehow I can never remember what worked either, so I find myself repeating this ridiculous dance on at least a weekly basis.
Although IIRC, there was a recent update that at least harmonised the code formatting syntax between editors, although I can't remember if it actually worked....
I thought I was the only one who is annoyed with this. Not only that, but the editor when you first create the ticket and the one used to later edit it are different too. I can't think of any sane technical reason that might explain using more than one rich text editor.
But the last time I enjoyed using Confluence was in the 1.x days with non wysiwyg wiki markup. Confluence been truly awful for a while now - eg why can't I ever find what I'm searching for?
For your specific example of not being able to see tickets as admin, I imagine that feature was added for teams where sensitive information is stored in the ticketing system for things like user reported issues. User reported issues often has PII or other personal data and while developers need to see that information, admins often don't. When I worked at a bank, any remotely sensitive columns in the database were either inaccessible to developers by configuration or by encrypting them to and from client code when the DB didn't support column level permissions (while Sybase could manage column level permissions, Mongo and Elasticsearch didn't at the time).
I don't understand why I can't see a ticket on my board because some team in another company once requested a seemingly unrelated feature. It's trying to be too many things to too many companies all at the same time, and thus ends up as an unusable mess of complex settings.
Have you used the bulk issue change tool? The UI isn't necessarily very user-friendly but I would not label it as requiring a lot of time, I actually feel it works quite well for this use case.
I'd like to add another point:
#. There are too many "views" or ways of visualizing the work that needs to be done, ie the plan view and the kanban view, my issues etc.
If I'm not looking at the 'right' view I'll miss something and maybe get in trouble from project management.
1. It's extremely slow.
2. It's difficult to predict the effect of making any kind of change.
3. The permissions system is so convoluted, I can be the admin of a board, and yet not have permission to see a ticket on it.
4. It relegates the conversation to a second-class UI element, when this is the most important part of any project management system.
5. Trying to operate on a bunch of tickets all at the same time (e.g. move all tickets in this status into some other status) requires a lot of time.
6. Every Jira setup is so different, trying to compare a piece of work from one area of the organisation to a similar piece of work elsewhere is useless.
7. The UI is extremely buggy. I can add a mandatory field to a ticket, then when I try to use a shortcut to create a new ticket, it won't work because I can't fill out that mandatory field.
8. There are random side-effects when one person does something on one bit of the system, and VOILA everybody's workflow is broken, with no obvious warning that would happen.