Nic Brough -Adaptavist- Expert

I don't think Atlassian will ever add anything like this. Automations are self-explanatory and "active" - you rarely care about what they used to do, only what they do currently. If you think you need to track changes to them, then treat them as code - create a Jira project to track requested changes to them

No change yet.

Do you mean explanatory notes within the automation rules? Automation blocks are designed to be self-explaining. Or do you mean a history so you can see who changed an Automation and demand that they explain why?

Welcome to the Atlassian Community! Jira is, at it's heart, an issue tracker, designed to do project and task managment. It doesn't focus on dates a lot, because it is more of a to-do list than a calendar, but it has dates and times built-in. I don't understand what you are looking for though, could you explain "booking" a…

Jira does not have field-level security. The issue-level security is done by looking at the field "security level" or "level", not a custom field (unless you automate some form of "set the level based on a custom field")

I saw two issues here: Communication was weak, despite the push to Statuspage (which was the right thing - that's what Statuspage is for!). Too many people were asking questions instead of looking at Statuspage. Why are we not referring people there? There is no explanation of what has gone wrong beyond some vague mention…

All users are displayed in the users list, de-activated or not. What is your user directory?

This is what it says in the message - you've tried to issue an invite to a list of people, one or more of whom have been deactivated. You will need to compare your list of recipients with your list of users (Admin -> user management) to work out who to remove from the recipient list.

If you have Jira Service Management installed, then it is actually intended for presenting a simple front-end to customers, and has some functions to get stuff into development as part of it! It is not uncommon for a JSM project to be run to gather requests and calls from customers, and the Agent thinks "oh, hang on, I…

Templates are actually just specialised page stored in a different place. The best thing to do is think of it as a contentless page - you create a page with formatting, placeholders and so-on (one difference is you can put instructional text in a template, stuff that only shows when in create/edit mode on a page) Macros…

User last logged in is available in the UI already, and in Access if you're using that for accounts.

Welcome to the Atlassian Community! Yes, they can. Once you archive a version, you can't add it to more issues, just releasing it lets you carry on using it.

Welcome to the Atlassian Community! The status category is a fixed list, you can't add any more to it. So you will find that you cannot do this. You can add whatever columns you want to your board, but not into different categories. This category is actually a flag on the status. The three default columns are just to get…

No. Well, partly. Some of the home directory for a Jira server can be put on a shared file system (I assume that's what you mean by "move directory to another server), but a good chunk of it is not - you can destroy a Jira's performance and corrupt the index by putting things like the index, temporary files and caches on…

Ah, yes, that's one way to get "What I am looking for is processes that might be reading the incoming mail more than once." Nicely spotted - that one is hard to work out in the Jira configuration

You're right, it will create a new status. A status can have only one name, so the only way to have different names in workflows is to create a new one for the new name.

Atlassian Cloud all runs on .atlassian.net (until Cloud-6999 eventually gets implemented, then you'll need to be relying on the individual Cloud systems, and their IP ranges)

Welcome to the Atlassian Community! Yes, I'd recommend a template for each type of page. The first page would be implemented with a set of macros in Confluence, so it would be useful to show people how to use those macros, rather than have to try to guess how the page works. The detail page definitely should be templated,…

Correct! It's something that has been added to your installation!

Yep - you can export a space from the admin tools of the space, using XML, and import it into another confluence. If it's a simple "everything", you won't need to think about much other than checking for clashing space names and pages. If you need a sub-set, you can select "custom" after choosing xml and it'll list the…

Assuming you mean for Cloud, yes, the whitelists you'll need are at https://support.atlassian.com/organization-administration/docs/ip-addresses-and-domains-for-atlassian-cloud-products/

These are hooks and fields coming from apps you have installed. They can't be removed without turning off or removing the app providing them. Some apps have configuration that lets them be turned off on a project by project basis, but I don't know if any of the ones you have support that

Jira doesn't have sub-status, so there's no way to do this. Ideally, you should be using "resolution", not status, to tell people why an issue has ended up in the closed status. If you did that, you could split your board by resolution swimlanes, or colour the cards by resolution, or use quick-filters on the resolution.…

Please explain to your manager what we've said above - "I want to do it in a certain way" is not a reason to do something really badly.

No, the database is separate.

There are a few ways you could do this, but none of them could be done by project administrators. You could write code that edits or deletes issue history content, but only your administrators could install or run it. The only other method is directly editing the database, for which you would need to go to someone with…

Yes, there's no other permissions I could be talking about in there.

Permissions do not work that way, they're flat and additive. Let's say you set up a permission scheme such that: * Browse: group developer, and group customer * Create issue: group customer * Edit issue: group developer If someone is in the customer group, they'll be able to create issues in the project, but not edit them.…

No, I am not clear on the requirement. What are you actually trying to achieve here? What would you do with a vast long list (with missing data) of field configuration settings?

Could you explain what this has to do with Atlassian?? I actually suspect that it isn't an Atlassian application, but the authors of it are using Atlassian for documentation, and you have clicked on "help with Confluence" instead of "help with Hunx"