Nic Brough -Adaptavist- Expert

It's not designed as a job posting or recruitment site, but the community does have an area for this sort of thing - post something in https://community.atlassian.com/t5/Jobs-Careers/gh-p/JobsCareers

I think you're right about the layers and, most importantly, not granting extra access inappropriately. The bit I am stuck on is: >if I already have the ssh key added at an account level, it shouldn't stop me from adding it at the repo level Technically, it should, you don't want potentially misleading access points, but…

I am sorry, I did not explain that too well. My previous experience is all with people sharing keys (which should never be done). The last time I added a key to a Bitbucket repository, and later added it to my profile, with the same account, it accepted it fine. But that was when it was called "Stash" and it was on Server,…

A FQDN is the basis of a hyperlink, and is exactly what they are for. A FQDN should always give you a hyperlink, or at least the most important part of one. Most humans don't care about the technicalities of this, we just tend to expect something that looks like a link to actually be a link. I'm not sure how making bits of…

Writing a script to list these is not particularly easy, and another script for doing it is another level more hard. Obviously, automating deletion would be risky - you might delete something one of your admins still needed as a backup. The best approach to this is "just get a human to do it". One of the "Best practices…

Company-managed projects give you a huge amount of flexibility in this area, at a cost of being totally not obvious to configure. In your case, you should look at three core things: * A project is a container for issues, primarily holding ownership and configuration for the issues (all issues of type X in a project will…

Ok, log in as an admin and remove one or more user's access. You have a subscription for up to X users, and you have added another user, so you're on X+1 (or more). Atlassian systems go read-only when you go over your licence limit. Once you reduce the users, you'll get full access back, it really is just that you can't…

Ah, that makes sense, thank you. I've only ever run into this problem when people have been sharing keys before.

Did you revert all the SQL changes you made before re-indexing? Or restore the backup?

Welcome to the Atlassian Community! Yeah, this is another reason for not looking at any Atlassian database. Your SQL isn't for Jira, it's for Confluence. And it's wrong, because you're not going to get the right information from it. Forget the database, you're wasting your time. For Jira attachment size, look at your…

I'm not sure what you are trying to do with "branch to epic parent"?

Why do you want to remove accounts (that can't do anything) from a project? What problem are you solving by removing them from projects?

I am sorry, "told you to use it" is a bit narrow, there are a lot of ways you might land on an Atlassian system. I should have been more clear. You need to contact the administrators of the system you are asking for access to. You have created, and are using an Atlassian account, which is what they ask you to use for…

journalctl is a part of the systemd sub-system on your Unix-like operating system. If you're using a Linux system that uses systemd for handling services, then journalctl is usually in the default path, so you can run it from anywhere.

I'd burn it with fire - it's got all the hallmarks of malicious systems. The domain name is a dead giveaway!

Some of this is historical - Jira started to support Scrum and Kanban a while after it was written as an issue tracker. Some functionality is not quite what you think it should be because it is layered over something it is not designed for. So, with that in mind 1. Multiple assignees are an unmitigated disaster in almost…

>so, someone else may be using my ssh key, and there is no way to find out who, and I can't even get support from the company to find out who? No. You, or someone else, has used your ssh key with a different account. >I would never share my ssh key Right thing to do in theory, but you have shared it. From what you've said,…

Yes, you can just add a level. Only caveat is that I would look at what is already there and ask people if they're using it. Obviously, if there isn't anything, then just go for it!

Weeeeelll, technically it does. You can fetch a "version" from the REST API. It's completely useless to anyone other than Atlassian, but sadly, a lot of us have to work with incompetent security consultants, auditors and compliance people that just don't understand what "software as a service" is, and demand version…

There's no way to establish that, other than knowing who you shared the key with. If you have a fully supported Bitbucket account (11+ users) you can raise a support request with Atlassian, who can tell you some basic info without breaching privacy.

It's not the repository, it's the account. You are not supposed to share keys with other people or accounts. You have, somewhere, another account that has already used that key (so your current account should not be trying to use it). You'll need to log in to the old account, go to profile -> Settings -> keys and remove…

The last couple of times I've run into this, it's the indexing. The macros rely on the index to retrieve their data when rendering for view, but they read the database or cache when you are in edit mode and previewing. Confluence queues pages for indexing - when you edit, it doesn't run the re-index immediately, it drops…

Not the employees, but the networks that your employees use. You can't identify people who don't log in, but whitelisting means you can say "only allow access if it comes from one of these ip addresses - organisational networks for example"

Welcome to the Atlassian Community! The plan is not the system! It's just what you pay for the subscription. You have a Cloud site with Jira Software, and at the moment, you are on the free plan for it. If you upgrade the plan, nothing moves, you just get more functions and/or people who can use it!

You can't block people out unless you know who they are, or you have a way of ring-fencing your systems to keep them out based on location. So, on Cloud, yes, you could let the world, not just your employees, see spaces without logging in. But if you need to limit it to just your employees, then you either need to identify…

Welcome to the Atlassian Community! You can make a Confluence anonymously accessible (not just globally, but space by space). This would allow the world to see it though, so it's only suitable for sites you want to be 100% visible to everyone (unless you buy premium and start messing with whitelisting your company access).…

Yeah, that's one reason you shouldn't be sharing keys across accounts. If you are on a supported installation (basically, 11+ users on any platform), you can raise a request with Atlassian for them to search for the key and at least tell you where it is!

You've said you are on Premium, so you can do this. Portfolio went away a few years ago, we now have Advanced Roadmaps, and that's where you can do this. Go to Admin -> Products -> Advanced Roadmaps -> Hierarchy You'll be able to set it up there.

Welcome to the Atlassian Community! Only administrators can create projects in Jira Server and DC, and you do NOT want to be letting any of your untrained people have those rights. You can do the "only see some projects" though. Your administrators can use permission schemes to determine who can see a project.

This is actually a Linux configuration problem, it's nothing to do with Jira, beyond a misconfiguration that happens to affect Jira. You need to check the permissions on all the directories Jira is installed in, using for data, and all the logs under /var/log/ that Jira might be trying to use. journalctl may show you which…