Comments
-
OffCourse the easiest way is to upgrade. If not, every workaround will ask for some effort in order to test it. Which is not easy to do too. A workaround would be for example : adding a reverse-proxy and blocking URI/URL and having more security and filtering rules between servers...etc. But this solution : * Has to be…
-
Do you still have the issue ?
-
please follow this tutorial : link
-
the due date is the parents' one. If you want to get the subtask due date you have to use smart values {{triggerIssue.duedate}} : link
-
you can use JQL condition.
-
are you creating your project using the shared configuration feature?
-
Hi @Zyreanna Johnson If you want to contact Atlassian support you can do that here : https://support.atlassian.com Other than that, if you have a question you can ask it here.
-
when transitioning an issue into "Done" column, do you update the resolution? I think that you don't. So you need to update the resolution field to 'Done' for example.
-
@Jamil Rahimov : These are only warnings. Can you look for ERRORs at startup ? if Jira is not able to start, you will find errors messages that Jira has failed to startup due to some errors. Moreover you can also check tomcat logs in the install directory (<JIRA_INSTALL_DIR/logs/catalina.out).
-
what the logs say?
-
I would suggest the following : * Trigger : Field Value changed for field 'due date' and for all operations * Test if : the issue is subtask * Then : go to its parent and* Test if : the parent due date is before the subtask due date * If yes : update the parent due date with the subtask due date
-
Seems ok. Have you gone through Jira Logs? have you seen some errors while startup?
-
a screeshot from Jira will be better.
-
@Ash the youtube link is private and not accessible. Can you make it public?
-
can you share what do you see in the logs ?
-
what licence have you applied? (check this link for more info on how to get this info)
-
agree with @Oliver Siebenmarck _Polymetis Apps_
-
You can you the REST API : link
-
* To create a project you have to be Jira Admin. * To create an issue in a project you have to have the "Browse Project" + "Create issue" Permissions in the Project Permission Scheme Those rules stay the same for API Call.
-
It is only possible to reset manually. You will find a detailed answer here link
-
Script fields are (partially) supported in Cloud : link
-
are you ready to use a script field since you have script runner? if yes you can add a script field in which you take the created and check if it is after 10PM and then return a value. Then you can use JQL on your script field. Hope it helps.
-
Does your agile board span multiple projects?
-
I think that the easiest way is to display subtasks in columns in the search issues view (see image below). So in you JQL you will search only tasks and for each task you can display all needed information + subtasks.
-
Summary field is always mandatory in Jira (and as far as I remember it always was). If you want to set a default value you can use this documentation link. But if you want to hide it (and off course set a default value) you have to use a plugin, like script runner for jira (using behaviors), or power scripts (using live…
-
The easiest way, in my opinion, is to create a custom field that you will fill automatically if the ticket is created after 10 PM. For example : * Create a select list custom field named "Created after 10 PM" (yes, no) with default value to "no" * Add an automation rule* Trigger : Upon issue creation * Add JQL condition…
-
Why don't you create a separate "create screen" for your subtask and put all the fields and custom fields you want to set in it? Besides you have to deactivate the assignment of issues to the project lead because if not, Jira will automatically assigne your subtask to the project lead although you have specified an…
-
Message edited so readers won't get confused. Thank you vm @Bruno Vincent
-
Message edited in order to change "Require Consistant Proxy IP address" by "Require Consistant Client IP address" This is it. It worked. Need to make additional tests but the first tests are working fine. In fact Atlassian support haven't suggested this option and we didn't notice it either. So as a conclusion (that needs…
-
Hi @Bruno Vincent In fact, we have already tried that and it didn't work. The reason behind it is that when you access crowd the first time, you may get though a first IP adresse (IP1 for example). But when you make a second call, you get through another IP address (IP2 for example). The 'fun' part is that crowd is getting…