Comments
-
If there is nothing going into the application or application-server logs, then you need to be asking why the operating system is killing the processes. I think it's far more likely that there are logs that can tell you what the crash is, but you don't know where to look. Two places to check First, look at the logs in…
-
From memory: import com.atlassian.jira.config.SubTaskManagerdef subTaskManager = ComponentAccessor.SubTaskManager subTaskManager.changeParent(issue, parentIssue, user)
-
Well, there's the docs at https://docs.adaptavist.com/sr4jc/latest - actually if you look through the "migration" section, you'll see a lot of what you can and can not migrate. But a better answer is probably to fire up a Cloud system, throw Scriptrunner on it and test for the things you currently do with it on Server.
-
Welcome to the Atlassian Community! It's not as simple as it looks, Jira doesn't have any functions for attachments outside its own simple "add it to the issue" storage, and you'll actually have to write quite a lot of code to make it useful when you want to make it upload and refer to Sharepoint instead of using the issue…
-
Loads of it! Start at https://developer.atlassian.com/cloud/jira/platform/rest/v3/intro/
-
Sub-tasks are not linked to their containing issue by the parentID. It's actually done with a hidden issue link type, but you don't need to worry about that directly. Use SubTaskManager.changeParent(subtask, new parent, current user)
-
That's being done by a validator that your admins have put into your sub-task workflow. You'll need to ask them to edit it and include the status you need.
-
Give every issue in your sheet a unique identifier in the "issue id" column. That can be as simple as 1, 2, 3 etc, but as it's going to be imported into the "external issue id" field, I'd recommend something a bit more text based, to show where it came from. For each sub-task, work out what the "issue id" is for their…
-
No, there's no multi-home. The only way to do that would be to have two separate Cloud instances. SR for Cloud is never going to have feature parity with Server. Cloud is a very different platform, and there are some things that cannot be done on Cloud the way they are on server. SR for Cloud is in fact, a complete rewrite…
-
Welcome to the Atlassian Community! This is a problem inside your build process, not really a Bitbucket pipeline problem. It looks to me like you have used an environment variable (the $AZURE_ thing) which is not being set in the build environment. Most systems put the name of a variable out like this when it's not been…
-
There's no way to get to the database on Cloud (I assume that's what you mean by "raw", please correct me if that guess is wrong!). You have to build something that can connect to the REST interface to fetch the data you want. That's effectively what the connectors you've found are doing.
-
A workflow scheme is a mapping function - it tells a project "when using this issue type, use that workflow for it" (there's a default line at the top - if you don't explicitly name an issue type, the project looks at the default) So you should probably just create your new workflow (I'd recommend copying an existing one…
-
Possibly - it depends on the event. Did you find a line in the history that did not get echoed into the activity stream?
-
I think the point about performance in NZ is probably under-explained here. We don't know where the main set of users are for this system, and the performance might be down to simple latency. If, for example, the Cloud system was owned by a French bank, which has a small office in NZ, then it's likely that the Cloud system…
-
Oh, sorry, I just realised you said "create" earlier. That's fixable - make the same change to the "create issue" permission as you did to "browse" - if someone can create issues in a project, it will be offered to them in the project list in the create screen, even when they wouldn't be able to see the issue they create!
-
Ok, that looks good, but can you confirm that the "5" on it is a story point value and your board is set to use that field for the estimation? Also, can you confirm that that issue is not a sub-task?
-
I know, it does feel like we're ignored when things are not updated, I've long advocated that Atlassian put a bit more effort into JaC. Clean out the duplicates (although that's one thing they're moderately good at when new stuff arrives) or gather them into Epics when they could be part of a bigger piece of work, look at…
-
Your file is not CSV, it looks like it's still an excel binary file. You need to save your data as CSV, and import that.
-
Where does the name of the project appear to people who don't have "browse project"?
-
Could you show us one of the done issues? (obscure the text and user fields if you want, we're only interested in the structural stuff like estimates, status, resolution and type)
-
Change the permission scheme for the project. Look at the "browse project" line - you'll want to remove what is there (the default is usually something like "all logged in users") and replace it with "role = X". Then put the right users and groups into the role. Bear in mind that permission schemes can be shared - you may…
-
You'll need to look at the issues that are missing the fields to establish if there is a pattern, and check if there are automations, listeners or post functions that may be removing what the users have entered.
-
Welcome to the Atlassian Community! The marketplace has a pricing tab. https://marketplace.atlassian.com/apps/1211768/wbs-gantt-chart-for-jira?hosting=cloud&tab=pricing for example
-
There is no "issue" here, it was a question about how ranking works. Changing the order to look at priority disables ranking, making the backlog and board a lot less useful.
-
Check the history tab - that records all changes. It might explain why the change to qa-varun is not part of the activity stream (if it was automated or triggered from the outside for example)
-
There's the first half of the last paragraph of my answer, or finding other software that's more suited to contact management.
-
Issues do not go into multiple active sprints, it would make a nonsense of your reporting and confuse your users as to who should be actually working on it. The sprint field is a bit complex though, it does contain multiple values, but they are not directly editable by the humans. It shows all the sprints the issue has…
-
There's no real way to escalate issues there. There wouldn't be a lot of point - everyone would escalate their own "favourite" issues which would effectively leave everything with no different prioritisation and just waste our time and Atlassians having to talk about it. Atlassian have a massive backlog of issues in JaC.…
-
As discussed in the conversation following the answer, look at the permission scheme.
-
Where do you want to "get" this? And do you mean current value or what the user selects and commits during the transition?