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

Regards.

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

 

h2.Brief

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.

h3. CREATE & UPDATE
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.

h3. DELETE
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
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Posted yesterday in Confluence

Calling all marketing teams who use Confluence - we want to hear from you!

Hi Community! me again 🙂 If you’re a marketing team using Confluence, we want to hear your story! How did you start using Confluence? What are your use cases? What have been some of the benefits?...

51 views 2 2
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