JIRA issue description formatting issue

I've been having an issue with the H3 formatting in JIRA OnDemand today. I don't know why, but when I use the h3. formatter, it doesn't actually format the text correctly after I save my issue description. But, while I'm editing, if I click the preview button below I see the text formatted correctly.

As a work around, I've been manually formatting my (otherwise H3) titles with a "bold" and "underline" to keep them clear that they're a separate section under the H2 sections.

3 answers

Hello Matthew

I just do the same test and the same thing happened that you described. I believe it is a JIRA bug.

And I found this at Syntax Help, I think the bug is the preview.

image2016-6-4 4:10:8.png


Matthew, could you sent the prints here? I always use H3. or h3. and it works. 

This is what I'm attempting. If I change the h3. to h4., it will work as expected. Right now, I'm seeing that the font is larger for h3. but not bold like in the preview. In another issue I wrote, the font wasn't larger either. (I'm including screen grabs as well)

image2016-6-3 15:13:51.png 

image2016-6-3 15:15:33.png



Create a model and/or library for accessing and modifying the organizations.

h2. Task
A library should include a set of public methods for higher-level CRUD operations to the organizations. They should always abide the rules, and manage the organization trees. This will remove low-level CRUD operations from standard coding workflow.

The +create+ and +update+ operations should always follow the hierarchy rules:
# A user entity may exist in multiple organizations.
# A user entity may only exist in any individual organization once as a single role.
# All organizations will start with an *{{ILO}}*.
# An *{{ILO}}* can be a direct parent to an *{{A}}*, *{{BR}}*, and *{{B}}*.
# An *{{A}}* can be a direct parent to a *{{BR}}*, *{{LO}}*, and *{{B}}*.
# A *{{BR}}* can be a direct parent to a *{{LO}}* and *{{B}}*.
# A *{{LO}}* can only be parent to a *{{B}}*.

h3. READ
In addition, the +read+ operations should be limited based on the user's organizational or non-organizational roles:
- If a user is a *platform admin*, they may see any and all users in any organization.
- If a user is _not_ a platform admin, they may only see the users (and other objects like "applications") below their account in the organization tree.

The +delete+ operation should ONLY be available to an element in the hierarchy when there is no other entity below it. (i.e. it may not have users or other objects below it). This ensures there's never a hierarchy change or orphaned objects. Also, a paper trail must always exist.


Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Tuesday in Statuspage

Introducing Statuspage Getting Started guides! First up: What is Statuspage?

Over the next several weeks we'll be sharing some of our Getting Started guides here in the community. Throughout this series of posts, we'd love to hear from customers and non-customers ab...

25 views 2 1
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you