John Funk Community Champion

Hi Elizabeth - Welcome to the Atlassian Community! So what is happening now? It just deletes the Epic and doesn't touch the children? 

Hi William, I am seeing the Rate Limited comment which is concerning. You should probably go ahead and open a support ticket with Atlassian to see what is going on. https://support.atlassian.com/contact/#/ In the meantime, maybe a helpful answer might come in here, but you should get Atlassian on the case in my opinion. 

Hi Andrius, If the field value is getting set like it should, then you can have an automation rule that runs on a Work item created trigger with a Condition that the field in question is not empty. Then add an action for Edit work item and select the Approvers field. Then copy the value from the field into the Approvers…

You wouldn't need to port to it per se. It would just be the new front end where requests are entered and then cloned into your existing project for the work to continue as it does now. 

Hi Paul - Welcome to the Atlassian Community! As Brant says, that is not available in JQL unless you have mapped a field. I am marking Brant's answer as Accepted, but please let us know if you still have questions. 

Hi Chase, I have not done a direct integration between the two products before, but there are many connector apps in the Atlassian Marketplace to assist with that, such as Elements Connect and Getint. Also, this is guidance from Hubspot…

Hi Nancy, You cannot add sub-tasks to sub-tasks. There is no way to go to that level in Jira. You can create a Bug sub-task work type and have it under a Level 0 work type like Bug or Story, but not under another sub-task. 

Hi Kenny, The user will need an Atlassian account, even if it is just a free Customer account. 

Hi Licenses - Welcome to the Atlassian Community! There are a few ways to do this. One is to use a third-party app for Time In Status. There are several good ones at low cost or maybe even free. The other way is create a custom number field and default it to 0. Then create an automation rule to increment the value of the…

First, why is that not an option? Second, no a user cannot do an approval with access to the project that I am aware of. 

Hi Emmanuel - Welcome to the Atlassian Community! I am marking Bill's answer as accepted. Please let us know if you still have questions. 

¿A quién intenta incluir en el campo Aprobadores? ¿Y qué tipo de usuario son? ¿Son miembros del equipo de la mesa de servicio? ¿Es un cliente? Si es Cliente, ¿tiene una cuenta?

I am totally lost then. What is the exact use case/scenario? 

Hi Sanchit, It is most assuredly because you have at least one Team-managed project showing up in addition to a Company-managed project. Is that the case for your filter? 

Hi Elias, If you have access to User Management information you can search for the user account and capture the account ID from the URL. Then you can search by the account ID instead of the name. The URL will end in something like: users/5de82a4d2fd6260cf27d1c3f The account ID is after the /

Glad I brought more than just the noise. :-)

¿Cómo se ve esto? ¿Pueden ver el campo? ¿Pueden hacer clic en él? ¿Intentan agregarlo a la Vista del Portal o a la vista de tickets normal? ¿Reciben algún mensaje de error? Y, de ser así, ¿qué dice?

Hi Ibtissem, Typically, you would use the Story work type. Make sure that work type is in the Work Type Scheme used by the project that you are creating the work item in. And yes, that API should work fine. 

Entonces, ¿quieres poder agregar al usuario al campo "Aprobadores"? ¿O el usuario no puede agregar a otros usuarios al campo?

Bien, gracias. ¿Cuál es el error que recibe el usuario? ¿O cuáles son los pasos que está realizando y qué experimenta que no puede ver ni hacer?

Hola Juan, ¡Bienvenido a la Comunidad Atlassian! Esto debería ser simplemente un permiso para editar el ticket. Prueba el Asistente de Permisos del ticket en cuestión y añade al usuario con el permiso para editar elemento de trabajo. Descubre qué dice.

Are sub-tasks created on every approval? 

Hi Adrian - Welcome to the Atlassian Community! Please post a screenshot of your rule and let us know exactly where the rule is failing. 

Hi Wakil, You can't keep something from transitioning in the workflow from Automation rules. You could possibly create a custom field and then not show the field on the screen. Then add a validator to the transition to In Progress to not let it move if the value of the field is not set. Then you can add a custom message to…

Hi Scott, What if you created a custom field with just a checkbox or a Yes/No radio button or such. Then change your automation rule to fire with the field value is changed. Then add the field to the screen of course and suggest each person pin the field to the top of the screen for visibility. Then you can even add a…

Hi Giridharan, Did you get this solved? If so, what was the solution? 

Yes, I believe that Jira has programmed functionality on either the Epic naming convention itself, or on that particular work type ID. I do not believe you will be able to mimic that functionality with other work types at the same level. You should probably open a support ticket with Atlassian to find out what they are…

Hi Steffan- Welcome to the Atlassian Community! I really don't see this functionality ever becoming a reality in native Jira in my work lifetime. You might consider creating a custom number field with some automation rules. Like where where the children of the Epic are set to have the same value as the Epic. Then you could…

This is probably the most limited type of project you could select. You should consider using a JSM project for your intake as you will not be able to achieve with the one you have most likely. 

Your original question was about naming tasks. That is what the Summary field does. What EXACTLY are you trying to accomplish? Please write in your own language if you feel more comfortable with that.