Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Jira Product Discovery - Naming Standard Recommendations?

Gail
Contributor
May 16, 2023

I am the administrator for all Atlassian products.   I keep documentation on things like a list of our custom fields, statuses, etc. and I am wondering if anyone has run into issues with JPD fields being named the same as a Jira Software field?    I would love to know how you solved the problem of naming standards.

My thought was to prefix or suffix the field name with JPD or something similar.   Once JPD goes GA, I need to have some standards in place so I don't go nuts trying to figure out why we have what looks like duplicate field names.

Thanks.

2 answers

1 accepted

1 vote
Answer accepted
Chris Timms
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 16, 2023

Hello @Gail 

 

I am not sure JPD (or generally, team managed projects) are compatible with a requirement to maintain a list of all custom fields separate to the project those fields make sense in.

JPD makes it really easy to create and maintain new fields per project.You can find more information on the difference between team and company projects here but it seems like team managed projects are resistant to central management and documentation like what you describe by design.

Regards,

-C

Gail
Contributor
May 17, 2023

Thanks Chris.  

To clarify more - i wasn't looking to document team-managed/JPD objects.   I pulled an API call to get a list of all our custom fields.   When I reviewed it, I happened to see a duplicate named field effort.   I only knew of one field used for our company-managed projects.   In more digging I found 20 JPD fields listed.   I don't really care that they show on this list, but what I am concerned with is when they use the same name as existing objects.

These duplicate fields can be seen/used in filters, so this will be confusing to users.

I was just wondering if I needed to come up with a JPD special naming pattern before we go GA.   This was totally unexpected.    

jpdfields3.png

Like David Griffin likes this
Chris Timms
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 17, 2023

@Gail makes sense - thanks for the reply!

 

JPD is going to spin up those 'default' fields any time you create a new JPD project, so if you can keep pace with the maintenance then a JPD-specific prefix is the only way I can think of that will solve for field ambiguity caused by creating a JPD project. This will be the case anytime someone creates a new team-managed project in your instance, though. Hopefully that's not happening too often :D

Regards,

-C

Gail
Contributor
May 17, 2023

thanks.  Luckily I am the only one allowed to create projects so I can at least keep a list of the "culprits" lol.  

Like # people like this
Rabbit Stoddard
Contributor
May 17, 2023

I’d honestly prefer they don’t show unless they’re company managed project fields, myself. 

Like # people like this
0 votes
Rohan Swami
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
May 22, 2023

@Gail @Chris Timms you're exactly right in the way JPD fields are created. Thanks for sharing your use case here, I was unaware customers were reviewing JPD fields through APIs!

Gail
Contributor
May 22, 2023

Thanks Rohan.   That is the only way I am aware of in Cloud to get a full custom field listing without copying and pasting.   It was suggested to me by Atlassian Support.   If there is a better way, I would love to know.    

Like kmaciesza likes this

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events