nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Jira Product Discovery - Naming Standard Recommendations?

Gail_8p6l1l

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.

Accepted answers

Chris Timms

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

All comments

Chris Timms

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.

Regards,

-C

Gail_8p6l1l

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.

Chris Timms

@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

Regards,

-C

Gail_8p6l1l

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

Rohan Swami

@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_8p6l1l

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.

Welcome!

It looks like you're new here. Sign in or register to get started.