Comments
-
The square bracket still works. In edit mode hit [ and wait a sec, it will go grey, then start offering you some page names, web links and search. If you're linking in the same Confluence, always use [page name] or [space: page name] as that keeps internal links during any migrations. I also quite like that you can put in…
-
No, sorry, I've not been clear on "condition" - although Jira uses the word to describe workflow conditions, it's been used in Scriptrunner behaviors as well. If you look at your first screenshot, there's a line about "conditions" there as well.
-
See https://marketplace.atlassian.com/apps/6820/scriptrunner-for-jira/version-history Note that Scriptrunner is an app, so it runs on Jira Core - the version of Software and Service Desk is not relevant (as they also run on Jira Core)
-
I think you've written a condition and not told it to do anything. Instead of doing the show/hide in the script, use the "shown" flag and a condition that says "if customfield Trager = IHK".
-
I suspect if you check the configuration for the projects, you will find they are using the same "Field configuration scheme" and/or the same "Field configurations".
-
Brant is actually right here. Technically. You can not "install Jira Software without installing Jira Core". Software needs a lot of the functions that Core provides - fields, issues, workflow, users, etc. If you're running Software, it's running on top of a Core installation. What you have been installing is a "bundle",…
-
There are several in the marketplace. Obviously, I'm going to say Scriptrunner - I work for Adaptavist, but it is the one that will give you the most power. I'd also take a look at Autoblocks (also ours, but it allows you to write quite complex logic without needing to know much about code or having to thoroughly…
-
Heh, Atlassian Community used to be based on Questions for Confluence. Anyway, I would take a look at the first handful of results on https://marketplace.atlassian.com/search?product=confluence&query=forums (Obviously, I work for one of the vendors caught by that search, but I would say I've seen a couple of the others…
-
I think you are misunderstanding what Community is - it's a load of people talking about Atlassian software. We are not support. This is not a support request, it is asking a question in a public forum. We're volunteers. I read (and try to answer) a lot of questions, but I miss responses, especially ones that give little…
-
Customers do not interact with issues, their interface is purely on Requests. Jira uses issues to provide the back-end of requests. Sub-tasks cannot be mapped on to requests. This is because sub-tasks live within the context of a parent issue, which you don't have with requests. The only way to do what you want is to copy…
-
It's not about "doing scrum", it's about what the board is showing you. A board is a view, not a container. If you do not map a status, then that status is not part of the board. It's not a "feature" to do this, it's just incorrect.
-
None of the Atlassian products delete a database. An import from xml can overwrite an existing database, but if you're losing tables, you need to talk to your database admins - they should be able to find out who is dropping all the tables.
-
This is going to sound harsh, but when you say "but not having to complete the whole story in one sprint." That tells me you are not doing anything resembling Agile Scrum. You might as well throw away sprints, simplify estimates down to non-time-boxed numbers of hours, and treat epics as simple themes to help reporting. As…
-
This might help - https://library.adaptavist.com/entity/copy-field-value-from-linked-issue - strip the bit about reading down links and apply the field (after translating) to the current issue.
-
My understanding is that the move is going to be towards the Align/Scaled approach.
-
Yes, this will work. I over-simplified, missing out "open" -> rest of desired workflow "No you don't, closed" should have an option to push it back to "we think we need", ideally with some way to qualify or justify why it should be don.
-
One of your admins has changed the field configuration for the project, making the fields required.
-
If you do not have a status on the board, then it is not part of the board. The backlog is part of the board. So, yes, if you don't map a status, then issues in that status CAN NOT appear as part of the board, and that includes the backlog.
-
I think you seem to be looking at two separate boards.
-
If you hover the mouse cursor over the red X's it will give you helpful error messages. To get you started, I think line 18 will give you something like "no such property". This is because the call you want is a method, not a property, and you've got the name wrong! Check the case of the letters in the call, and add () to…
-
That's the point of the discussion - it does work. Some people want a backlog column, others do not. You can (now) choose. I prefer backlog on one view, and my current sprint on the board view. But that's just me.
-
Yes, and no. Yes, because you can have any status you want as the landing point for "create" But, no, because once you create the issue, you have a created issue. There's no "request to think about maybe creating something". You've created it. A lot of places do do workflows that have: * Create -> "We think we need" ->…
-
But, technically, that one is not incompatible. Just not desirable. Some places do do sprints with Epics. They are, of course, not doing Scrum, but if it works for them, why break it for them.
-
The backlog is * Everything selected by the board filter * Minus done issues * Minus sub-tasks * Minus things in an active sprint The backlog absolutely is generated by the board filter, not the other way around. Your filter is complex and long. Can you try going to "board configuration" to see what we're really looking…
-
This one is a bit complex - as Jira has grown, the usages have changed, and become inconsistent. * In plain Jira, a lot of people use it to represent the version(s) in which it was fixed, often having versions that were analagous to builds done by CI/CD systems. This also applies to Kanban boards - when you hit "release",…
-
Yes, it creates them when you create your service desk project.
-
A board is not a container for issues, it is a view of a selection of them. When the board was cloned, the selection was cloned, not the issues. Your team member deleted the issue, so it went from both boards, because there was only one actual issue being displayed The issue links have nothing to do with deletion of…
-
That's quite a complex query, and if it is viewing "too many" issues on the board, I would say there is something not quite right with the OR parts. Decompose it, and try to simplify. Do you really mean * All issues where the Project is CVE where status is in (list) and Sprint is empty * And * All the issues where Sprint…
-
Customers get "raise request". They will never use "create" to create issues. For "ad hoc" requests (which I am not sure we understand), you'll probably need just a an "ad hoc" request type.
-
If you use the Scrum or Kanban project templates, you get that type of board with them automatically. I'm guessing you probably want to customise these for some reason? You'll need some scripting or automation apps to do that.