Josh McManus Specialist

One further limitation that I ran into was "archiving" teams. For things like Versions, you can Release/Archive versions to prevent them from populating the pick list in Fix Version, but there's no similar function for Teams. However, what happens to Jira issues assigned to a Team when a Team gets deleted? For completed…

I'm also encountering a similar issue. I have limited subtask types to aid in user experience, but two different parent issue types that inform some requirements on the relevant subtasks. Design (standard issue type) with subtasks: Implement, Validate, Rework, and Deliver. Story (standard issue type) with subtasks:…

I feel so seen. <3

Thanks for all your feedback so far! Let me see if I can reply to some of these comments: @Tomas Vaicekauskas "I assume you've been asked about scaling your business initiative to a program level to avoid subtasks, which are inconvenient for large-scale models. It would be interesting to hear your thoughts on this." * It…

I'm also very interested in solutions to this issue. One thing that I think is a particularly complicating factor is that Automation Rules can't be shared between projects unless you're a Jira Administrator. I would love it if I could create highly-refined rules that Project Administrators could browse and choose to enable…

I'm working on a plan for this currently with my organization. We have Atlassian Guard, and we use Okta as our SSO solution (with AD underpinning it). My plan so far has been to work with HR to come up with a list of consistent Roles within our organization that we can outline for every new Job Requisition we post, and…

Hi @Loretta Brunette , In order to reduce Work Item Type proliferation in my instance, I'm attempting to leverage multiple forms for a single work item type and automatically populate certain fields based on the Form used to generate the issue. It doesn't seem like a form can populate a field under the hood (i.e. set…

This is great! Learning this structure organically was definitely a challenge in my early days, and this diagram would have been very helpful. I'll certainly be leveraging it to train new admins in the future. Thanks! One thing I noticed that might be a helpful addition: transitions can leverage fields in Conditions,…

I wish I could, but alas my research in answering your request has led to further disappointment! Apparently when you create a Managed Team by syncing it to the Atlassian Group, team membership becomes controlled by the Group and users can no longer manage team membership on their own. What a frustrating missed…

Definitely useful information! Thank you for sharing. For ITSM I can understand how this model could work...I think my concern is that the number of products we make and the number of "initiatives" that come up around those projects would lead to a lot of new projects and it wouldn't be very clear where the KTLO work would…

It sounds like a custom Labels field would suit your needs. You can create a new field that is a Labels type field and it acts the same way as Labels. None of your serials will be able to have spaces in them, but if that meets your needs it seems like an ideal use case. This doesn't solve your project restriction…

Ah right, no you're right on this front. This was a relatively recent development and I forgot that they added this. Totally fair!

The issue with the Team field and Automation is that there's no way to trigger off of the field update. Instead you have to trigger off of Work Item Edited which makes the automation run with every issue update, regardless of whether that field is edited or not.

There is some new functionality that I noticed recently that allows an admin to sync a Team to a Group, which means team members can handle user management but you can enable permissions to the group. It does seem a little complicated since it requires a Site Admin to set this up...but it does enable things like tying…

You're telling me "Copy of Copy of Unified ABC Workflow scheme w/Added Status no Bugs 2.0" isn't clear? ;)

Can confirm. I'm still working with my organization to get the budget allocated for the purchase, but based on what it offers for free and my time with the trial I am definitely a convert. I don't know how any decent-sized organization that cares about the health of their project data pipeline lives without the…

This is what I'm currently suggesting to some of my teams. They regularly get into priority conflicts between CS priorities and PM priorities and it usually leads to the engineering team feeling pulled on. I'm suggesting they move to an "on-call" model where engineers rotate through the "support queue" where they don't…

Voted! It would even be more consistent if they went with EMPTY since it's what is used in JQL for that very result.

Oh man, this infected our system in a very weird way. Somehow at some point in the past someone thought they needed to add a resolution of "unresolved" to our resolution list. Now we have both "Unresolved" = EMPTY and "Unresolved" = Unresolved. Fun times!

@Michiel SchuijerI am able to limit Resolutions through workflow transition properties. You can use the property "jira.field.resolution.include" or "jira.field.resolution.exclude" and then list the resolution ID's that you want to operate on for that transition. The great thing about this is you can create special-purpose…

Software project and Business project are unrelated to Team-Managed vs Company-Managed. Team Managed and Company Managed are about who controls the configuration and settings within the project. Software project and Business project (both Company Managed project types) are about what kind of features are included with the…

The problem with this is that it creates a requirement to share credentials for that integration account in order to generate new API keys. Shared credentials to access functions that aren't otherwise accessible to Site Administrators when they need it seems to violate some rather basic security practices. I don't…

I see, and otherwise migrate these projects to the same issuetype scheme and workflow scheme that allows all statuses and all issuetypes so i can start using a single workflow/issuetype/field config schemes for all "archived" projects and still minimize administration overhead and complexity. That does seem to achieve the…

This is a very valuable recommendation. Right now I'm considering migrating all issues in a project I want to archive into a Read-Only active project with a field that indicates what project these issues were migrated from. Not an ideal workaround, but it allows us to search for issues while reducing the admin overhead of…

So I've had a version of this automation running for a while now for my teams, however just recently there's been a discovery that it's undercounting story points because we have Epics with >100 child issues...meaning we are hitting that 100 issue query limit in the Lookup component. Does anyone have any ideas on how we…

While this certainly is exciting to see, I think it's worth saying here that my organization is still significantly impacted by the removal of Capacity Planning. This was a feature we leveraged quite heavily in Live Plans, and we even had a way of using it to add in "fuzziness" buffer for work that was further out in the…

So I'm trying to work around the lack of Dashboard Gadget and Confluence Filter support for the Team field, and the best method I could come up with is using Automation to synchronize the field we previously used for Team assignment and people can use that field for filters/dashboards/etc. However, since I don't have…

If you have a field in a configuration, you should be able to remove it from the "Create/Edit/View" screens for those issue types in your project. You may need to build these screens specifically if you are using the default screen schemes for your issues in your project. You can find this in the "Issue Type Screen…

This is hitting us as well, and is showing up across lots of channels and teams. Any ideas for troubleshooting?