Comments
-
What do you mean by "send and store"? When you decide you need to send an issue over to Perforce, what are you looking for? My initial guess is that you mean "Jira should build some text as a simple document, and tell Perforce to drop it into a particular directory, and add it as an item to be source controlled" Is that…
-
There are too many ways to do SSO at the moment, it's not (economically) possible to code for everything as part of the core product. Atlassian have done what everyone else has done - built in as much as they can that is standard, and then relied on the vendors of SSO products to do the rest. (Although, yes, I would…
-
Sorry, that was vague, I usually remember to include the route. Log in as an admin and then go to <admin cog> -> System -> General configuration -> edit settings Look for "allow unassigned issues" in there and set it appropriately. There are some things to think about when you are going to change this, but Jira will…
-
Sorry, the original question says "Description field for bugs", so I was going with that. But your bug screen definitely has it as well, so it's not that. The only other thing I can think of is that your people are experiencing Jira trying to be "clever", where it hides fields they may not want, until they explicitly tell…
-
Um, no? As we've explained it already? Please see the two comments before your latest one (9th August)
-
Sprints draw their information on what to measure from the boards that they are in. On a board, an issue is "done" when it is in the last column of the board. So, to make your issues "done", they need to be in a status that is mapped to the last column on the board(s) that display them.
-
You should also bear in mind that Jira does a lot of sharing of configuration, so you are going to find cases where "I only have admin for silo X" can't work because a workflow, field, permission, notification scheme etc might well be used by silo Y as well.
-
Jira does not have a "project export", mostly because it would be useless to other systems - Monday is different to Jira and there's not much of a useful translation between them. A Jira project is essentially three things. Some storage for some (small amount of) metadata, a pile of configuration settings to tell it how…
-
Requests do not have security schemes of any form, only the issues behind them. The only way you could do this is have distinct issue types with a 1:1 mapping between them (request A = issue type A, request B = issue type B, etc) and then have some form of automation that sets a security level on issue types B and C such…
-
We can't help you with that, we're people who use Atlassian software, but we have less knowledge about your system and ownership than you do. If you've genuinely tried everything you can inside your organisation to find out who the admins are, you can ask Atlassian with a support call, but it's going to be a lot slower…
-
If your Jira is exposed to the internet, then yes. The whole world can see everything in a project that anyone can access.
-
Cloud means that the deployment model is simple - you sign up to the service, and start adding users who can then use it. I'm not sure that needs a huge amount of documentation.
-
Ah, I think what has happened is that KBase uses Jira for a service desk and while you were looking for help, you have clicked on a link for "help with Jira", rather than "help with KBase" I'm afraid we are stuck (unless someone from KBase is also here), all we can really say is that you probably need to get in touch with…
-
Regular backups should be done with database tools, as they're faster both to get from Jira and use to recreate a system. But they're not much use for moving between databases. The XML export is database agnostic, so it can be dumped out by one Jira, read into another and neither of them care what the underlying database…
-
The (bulk) migration is triggered because the issue types you are changing between have different configuration and hence it needs you to review all the structural things you are going to be affecting. The migration is "bloated" because you are doing something that is complex and could need a lot of input. To avoid this…
-
Your definition of done is inconsistent in your teams and hence in your process. You need to decide if "in review" is actually done or not, and have everyone understand which one it is. At the moment, you're using it as a subjective measure - some of your people think it means done, others do not. That cannot work, it is…
-
Ah, I see. "Fast" here was just a word picked to say they've made it a bit more simple (i.e. end-users having to think less). It's not editable though.
-
Ok, I understand. There might be a way to search, but without knowing what method was used to do the migration, we cannot know what shape the data might be in, so we cannot really talk about the possibilities with any confidence. The fact the key changed suggests an import of some form, rather than a "migration" (I tend to…
-
You'll need to explain what "Intercom" is.
-
How did you "migrate to Cloud"?
-
You are in the right area, but your first screenshot is showing us the screens for all the issue types except "bug"! Could you expand that one and have a look?
-
Not quite sure what you mean by "fast kanban", but the next-gen Kanban boards are simple and do drop items that are done and inactive for a fortnight. You can't change the way it does that. But you can display anything you want on a dashboard. Most of the gadgets on a dashboard are driven by a filter behind them, and…
-
Components is a system field and does not quite allow what you're saying. The function is actually limited to people who have project administration rights, which should not really be "everyone". No other fields have this function - select lists, multi-selects, radio, check-box etc - they're all expected to be managed by…
-
You'll need to find the people who look after your servers and get them to take a look at what it is failing on, or give you an account so you can start looking. Head for the logs first after checking the basics (that the service is actually running)
-
Not really, that would need a full-on translation engine to be built into Confluence, and that is not a small task. If you were on Server, I'd recommend a look at https://marketplace.atlassian.com/apps/1211616/scroll-translations-for-confluence which does do parallel pages in different languages, and can accept attempts at…
-
Ah, you're not using the standard post-function I usually use. See the first post-function on the list - that needs to be removed.
-
In the global settings, you can also disallow unassigned issues, but that is a global setting.
-
There are some example listeners at https://library.adaptavist.com/search?page=1&products=jira&platforms=cloud&term=listener
-
Go to the project admin and look for the screen scheme in use, descend into that and you'll see where you are using different screens for create and edit by issue type.
-
Pop over to the version history at https://marketplace.atlassian.com/apps/6820/scriptrunner-for-jira?hosting=cloud&tab=versions and click "view all" to get the list of releases, along with the platforms they are compatible with. As a general rule, simply take the highest one that says it works with your version.