Nic Brough -Adaptavist- Expert

Same as you did in 2013 - workflow schemes are still the way Jira associates workflows with projects (on Server, DC and for Cloud company-managed projects. Cloud team-managed projects don't have workflows)

We can't tell you anything about this. You've not explained what QSH is or what you are doing or why. (Quasi Shear Horizontal is not something I would even think of using Jira for)

Who have you added as administrators? It is one of those 3-10 people doing it.

I am not sure what you are asking about here. Two different pieces of software do things a bit differently to each other.

It depends on what you have set in admin -> time tracking. That's a global setting, but it does default to an 8 hour day, 5 days a week.

My answer was quite blunt, I should have asked what you were worried about. You have told us that now, and what I should have said before, which still stands is "don't worry". A vote on an issue really is just a vote on that issue. It has no effect other than being a flag that someone would like you to fix that issue. You…

What do you mean by "integrate"? Could you explain what you want to do with it?

I'm afraid voting is a global thing - it's there for all projects, or it is not.

There are no "restrictions", Jira has a simple permissive system. If you want to stop someone from seeing or doing things in a project, you need to remove their access to do so. A lot of us have problems with Atlassian's default "can do anything" approach, you won't be alone if you want to complain about it.

Admin does not mean "can see/do everything" (rightly, it's a bad thing to do it that way), it means you are an admin. Check who can create issues, I would guess that you do not have the right to do it.

Yep, this script is quite short and is probably the most common use case (checking a custom field value, not your specific case) def customFieldName = "Story Points" def customField = ComponentAccessor.customFieldManager.getCustomFieldObjects(issue).findByName(customFieldName) assert customField: "Could not find custom…

Sorry, I'd assumed you were in a company-managed project. I think you are in a team-managed project, where the fields are localised. Go to the project the field appears in and go to the project settings and look at the fields, you'll find the misspelling in there

Yes, that's the searcher.

That's the field configuration, not the custom field definition. You need to go to the list of custom fields, not the field configuration for the project.

Field names are global, go to admin -> issues -> custom fields, find it and belt "edit" to rename it.

The usual problem with this is that the custom field does not have a "searcher" applied to it, so it can't be indexed. Check Admin -> Issues -> custom fields, find CODIGO DE PRODUCTO on the list and click Edit next to it, you'll be able to see the name, description and searcher for it. Select a searcher for it and then…

Please see the link I gave earlier for the Atlassian docs. I can't tell you how your network works, or what your network admins might have inflicted on it to do this downgrade. The only way I know of doing this is to route through a proxy or load balancer that is configured to do it. I guess you could also do this…

It can't enforce the workflow rules in places that are not part of the workflow. There's no way to do that.

This suggests that the issue types of story and test have different selections of fields available to them and hence when you moved from test to story, you destroyed the data in the test details field (the move process will have told you that this was going to happen)

If a project is not offered to you in the new project field, then you don't have "create issue" permission in that project.

Go into the issue the notification is about and amend it to reflect the changes you want to see.

Ah, I was looking at the body of the field, not the name. "Acceptance critera" is a custom field, which your admins have added to your system. Custom field names are determined by the person who adds them, and they can be renamed by admins, so I'd ask your admins to correct the name.

Yes, see https://support.atlassian.com/jira-cloud-administration/docs/create-issues-and-comments-from-email/

You don't. An issue is editable or it is not. That covers all the fields, not bits of them.

No, there's no need to upgrade, those versions are not a problem (I mentioned old versions for completeness because it has happened before - people talking about issues in Confluence 1 or Jira 2 without telling us the version is not unknown) Those versions confirm that the problem is in your network, not the services. It's…

Yes, there's a slight oddity here in that Request type is implemented so that it looks like a field and so you can put it on screens. It isn't a field you can change, it's a structural attribute and it determines other things, so you can't just change it as though it were a field.

There is a faulty assumption here, although it's a very understandable one. Server and Cloud are two very different things, and so are the apps written for them. When migrating from one to the other, you should assume that every app is going to change. Whatever functions an app provides on your current system, if you want…

See https://confluence.atlassian.com/jirakb/health-check-modern-http-protocols-996647804.html for a better explanation/fix

That looks like text that a person has entered into a field. You can just edit the issue in order to fix it. (I can't actually see a typo in it though)

It's nothing to do with the applications themselves, they don't choose how to serve up their pages. The Tomcat containers they run in serve the protocols. Unless you are using very very old versions which are running on Tomcats that only have the older protocols, then the problem is in your network, not with Jira,…