-
Suggestion
-
Resolution: Fixed
-
335
-
Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.
Update Oct 15 2024:
Hi, we are happy to share some new updates to this ticket in regards to the issue listed:
- Introduce an option for organization admins to stop managed users from creating additional cloud sites
The product requests feature, a proactive shadow IT control allowing admins to more centrally manage and prevent new user-created instances across their cloud footprint, is available to customers who have a Jira, Confluence, or Jira Service Management Enterprise plan - and coverage now expands to Trello and Bitbucket (Premium plan, in beta).
For further information, please refer to our latest community post: An update on product requests: bringing shadow IT controls to Trello and Bitbucket
- duplicates
-
ACCESS-1468 Allow Administrators to control managed users' associated sites and products
- Closed
-
CLOUD-10325 Allow non-Enterprise administrators to control managed users' associated sites and products
- Closed
- is related to
-
ACCESS-1468 Allow Administrators to control managed users' associated sites and products
- Closed
-
CLOUD-10325 Allow non-Enterprise administrators to control managed users' associated sites and products
- Closed
-
ACCESS-1027 Allow org admins to transfer ownership of products owned by managed accounts
- Gathering Interest
-
CLOUD-11240 Allow Administrators to turn off the Slack integration offer for managed users
- Gathering Interest
- mentioned in
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
[ID-7697] Prevent managed users from creating cloud site using a verified domain.
We open a ticket with Atlassain EVERY time this happens. If it costs us time, it's going to cost them time.
What a23395f92dd8 said! In addition it is really tedious to follow up the cleanup process on all managed accounts given the retention/deletion time.
This feature should be available for all the subscription tiers. It's unbelievable that it is locked behind a paywall. It's basically security risk in a company-managed site!
I've been talking with Atlassian support about accidental site creations. A new ticket has been created to reduce the chance that new sites will be created accidentally via the "sign-up" flow.
Note this new ticket is just about reducing the likelihood that new sites will be accidentally created, not preventing new sites completely. To quote the ticket description: "The intention of this Suggestion ticket is not to block new Cloud site creations, but to reduce the occurrences of accidental site creations".
I suggest you go and vote for / follow this new ticket: https://jira.atlassian.com/browse/CLOUD-12193
And as always I sent a reply I'm not happy with the 14/45 days deletion time ;
Thank you for sharing your concerns with us. I understand how frustrating this situation must be for you, and I truly appreciate your patience as we work toward a more permanent solution.
I would like to address your concerns and let you know that we value your feedback. We are actively engaging with our internal teams and directly expressing the frustration you are experiencing regarding this issue. Our goal is to provide enhanced shadow IT controls for non-enterprise customers, though I am unable to provide a specific timeline for when these improvements will be available.
Please note that I have initiated the hard deletion from my end to get the site "****" deleted and it will take around 14 days. I will soon share the final deletion date with you after I receive a confirmation from the internal team.
I sincerely appreciate your understanding and cooperation as we work together to resolve these issues.
Appreciate the perspective. I think the point of frustration for a lot of us is, whether it can be deleted in 14 days, 45 days, or 1 minute, that this is entirely preventable by Atlassian and serves nobody's interest except Atlassian's interest in increasing their metrics and profit. It is a frustrating and an total waste of everyone's time to have to deal with any of these sites being created by unwitting users who are misdirected by intentionally and poorly designed login pages. The solution, according to Atlassian is, pay more. I will happily pay more for other features that bring value to my teams, but this is a design decision by Atlassian to intentionally inflate their metrics and profit. They would rather ignore the noise here than fix the problem, and the problem they have created is 101 security and manageability. Its basic, not enterprise. DO YOU HEAR US ATLASSIAN?
0780f5450831 just wanted you and others know that as frustrating as this problem is (and I just had two new sites accidentally created in the last 24 hours, so it'd definitely still happening), you really can delete a site and the organization in less than 45 days (but more than 14). [Yes yes, it's a soft-delete, which I don't care about since it was an accidental site.]
Most recently, I had sites two Confluence sites created 20-Dec-2024. I cancelled them on 22-Dec-2024 and requested expedited deletion. On 10-Jan-2025 (20 days - maybe they took off Christmas and New Years), the sites were deleted, and I was able to delete the organizations as well.
Another more recent example: 5-Jan-2025 a Confluence site was created. It was cancelled 6-Jan-2025, and again after filing a ticket to request expedited deletion, it was finally deleted yesterday, 21-Jan-2025, and we were able to delete the org. That's 15 days exactly.
I wish I could automate this process. :-/
Hi all,
Indeed, we are all familiar with this typical repsonse by Atlassian support:
- When a site is marked for deletion, there is a 14-day period before you can proceed with deleting the organization. This time allows us to ensure that all necessary processes are in place to protect your data.You will be able to delete the organization 14 days after the deletion request is initiated. I will soon share the deletion date for your site after confirming with the internal team.
- Following this, there is an additional 30-day soft deletion window. This is part of Atlassian’s commitment to safeguarding your information against accidental loss. During this period, your data is tagged as "Soft Deleted" but not permanently erased. This provides a safety net in case the deletion was unintentional or if you need to recover any data.
What we really need is the same kind of responsibility and some proactivity (instead of reactivity) when a user is creating a site entirely by accident:
- We need the ability to control whether managed users are allowed (or not allowed) to request new sites or products
- When a user is allowed to request a new site or product, this must be subject to approval by an organization admin BEFORE the site or product is created!
This is the ONLY REASONABLE SOLUTION for this problem which is already lasting for way too long!
Stefaan
PS: for everyone following this topic, please also follow and vote for the below topics, because that's the only way to increase our visibility for this ENORMOUS PROBLEM with Atlassian products that have names or features like "PREMIUM", "MANAGED", "GUARD":
- https://jira.atlassian.com/browse/CLOUD-10325
- https://jira.atlassian.com/browse/CLOUD-12089
- https://jira.atlassian.com/browse/ACCESS-1135
- https://jira.atlassian.com/browse/ACCESS-1645
- https://jira.atlassian.com/browse/ACCESS-1468
- https://jira.atlassian.com/browse/ID-7697
- https://jira.atlassian.com/browse/ACCESS-1679
- https://community.atlassian.com/t5/Articles/What-s-the-word-I-m-looking-for/ba-p/2862486
- https://community.atlassian.com/t5/Confluence-questions/SECURITY-ISSUE-during-login-procedure-of-managed-users/qaq-p/2841895
- https://community.atlassian.com/t5/Atlassian-Account-questions/How-to-Prevent-Atlassian-Products-being-added-by-users-w-company/qaq-p/2401874
- https://community.atlassian.com/t5/Questions/Why-is-Atlassian-promoting-Shadow-IT-Or-Accidental-IT/qaq-p/2731538
- https://community.atlassian.com/t5/Enterprise-articles/An-update-on-product-requests-bringing-shadow-IT-controls-to/ba-p/2840760
- https://community.atlassian.com/t5/Articles/Proposal-to-prevent-Accidental-Site-Creations-accidentalit/ba-p/2867193#M558
It’s so easy for users to create new sites—why is it so difficult to delete them?
This week, another user accidentally created a site and submitted a support ticket to expedite its deletion. The response? 45 days. Even after requesting a shorter timeframe, the response remains the same: 45 days.
Thanks for getting in touch with Atlassian Support. My name is <..>, and I'm the support engineer who will be assisting you further with this issue.
I want to sincerely apologize for any frustration or inconvenience this situation has caused. We truly understand how important it is for you to resolve this quickly, and I'm here to assist you.
When a site is marked for deletion, there is a 14-day period before you can proceed with deleting the organization. This time allows us to ensure that all necessary processes are in place to protect your data.You will be able to delete the organization 14 days after the deletion request is initiated. I will soon share the deletion date for your site after confirming with the internal team.
Following this, there is an additional 30-day soft deletion window. This is part of Atlassian’s commitment to safeguarding your information against accidental loss. During this period, your data is tagged as "Soft Deleted" but not permanently erased. This provides a safety net in case the deletion was unintentional or if you need to recover any data.
We understand that waiting for this process can be challenging, but please know that it’s designed to give you peace of mind by allowing a recovery option if needed.
Hi team,
We’ve noticed a recurring issue related to the unintended creation of sites with URLs like "team-[random_string].atlassian.net," which are auto-generated by Atlassian when users sign up for new products. This appears to happen due to a UI flow where Atlassian suggests a URL based on the user's managed account status.
Although it was confirmed that this is an end-user-triggered process, it’s clear many users are unaware they’ve created a site, leading to unnecessary instances that benefit neither the user nor Atlassian.
We believe it would be valuable to revisit this case and -evaluate it.
Referred case: PCS-362222.
Personally I don't even mind if users can sign up for new products, as long as I'm notified about it. But stopping them accidentally creating new "sites" seems like a no-brainer (to everyone except Atlassian it seems).
I did a bit more investigation on the "sign-up" flows that result in accidental site creation. Every Atlassian product has a "Get if free" or "Try now" button on their home page, but the page they take you to is slightly different for each, and some are better than others.
The Confluence sign-up is the worst: https://www.atlassian.com/try/cloud/signup?bundle=confluence - this one pre-fills a new site name for you. The Jira one (https://www.atlassian.com/try/cloud/signup?bundle=jira-software) is the same.
However Compass (https://www.atlassian.com/try/cloud/signup?bundle=compass) and Loom (https://www.atlassian.com/try/cloud/signup?bundle=loom) do it right. For me at least, they pre-fill the "site" text box with our existing site, and make it non-editable. There is a small "Start new site" link, but users are unlikely to click that accidentally.
If Atlassian could just change the Confluence and Jira sign-up pages to work like the Compass/Loom ones then I think most of the problems we're all dealing with would go away.
SUGGESTIONS FOR ATLASSIAN...
Since Atlassian has locked out our ability to block creation behind an "Enterprise" paywall, then How about improving TWO THINGS: (1) The ability to DELETE the sites, and (2) the Site creation process?
1. Please ADD A WAY to QUICKLY remove the product & site – an EXPEDITED removal process.
- Simply give us multiple confirmation prompts to ensure we know we're deleting the site – and then let us delete it, immediately! (Similar to how a "Product" is deleted.)
- I understand the need for confirmation-delays, but ~90 days is excessive.
- The current deletion process in the “improved” billing experience takes almost 3 months. (The old way took 2 weeks!) Think about that for a second. I have to keep a trouble ticket open for 3 months to track the work on this. I have to show it in my stats for 3 months. I have to keep this on my radar for 3 months. All for a mistaken click from a user.
2. During CREATION, the Atlassian system should improve user prompts – Add CONFIRMATIONS.
- Confirm the user's actions with pop-ups/messages to ensure they know what they are doing.
- Prompts like, “YOU ARE ABOUT TO CREATE A WHOLE NEW SITE…” and “YOU ARE ABOUT TO ADD A BILLABLE PRODUCT TO THIS SITE” and a confirmation, "CONFIRM: I AM AUTHORIZED TO CREATE THIS NEW SITE AND ADD THIS NEW BILLABLE PRODUCT" and "CHECK WITH YOUR ATLASSIAN ADMINISTRATOR BEFORE CONTINUING" !!
- This would reduce the accidental creations.
- Every one of the site creations in my organization were created accidentally. This is 100% due to the way the system presents options for our users. The Jira App prompted it or the user wasn’t logged in and so they thought they were clicking into Confluence but they were actually creating a new site.
Respectfully,
Mark
Hi 7c3017d4daee and 7a79c351a973 - in the immortal words of John McClean, "Welcome to the party, pal!"
Unfortunately we mere mortals can't add images to tickets, so Charles, your screenshot is a broken image. But I've written all of this up (with screenshots) here:
The irony of this is that Griffin, the poor owner of this ticket, is a Product Manager for Atlassian Access Guard, which, yes, technically if you are on Enterprise Tier, then Access Guard can help prevent this issue.
But as we've made clear in all of our comments, this shouldn't really be put on Access's Guard's (or Griffin's) shoulders. The blame is 100% with whomever owns the Product Pages for Jira and Confluence.
In my follow up post and comment, I found that it looks like the Jira team is attempting to address this issue, looking at session cookies or something to pop-up showing your correct Jira instance if you are already logged in on the main https://atlassian.com page. And more recently, on the Jira product page (https://www.atlassian.com/software/jira), they put a huge box at the top linking to your existing site. Alas, the Confluence product team hasn't figured out how to do this yet. Here's some screenshots:
Anyways, maybe that explains why the majority of my accidental site creations are for Confluence, not Jira. (On mobile devices, https://atlassian.com does NOT show the pop-up with your existing site, so that might explain why I'm still getting some accidental Jira sites.)
7c3017d4daee Thanks, that's really helpful.
I just went to https://www.atlassian.com/software/confluence entered my email and hit "Sign Up". This then prompted me to log in via our SAML SSO. After doing that I was presented with a screen prompting me to create a site! However if I go that URL and instead hit "Sign in" (top right) instead of "Sign up" then I just get redirected to our existing site as expected.
It feels like this is the real issue that should be fixed. The "Sign up" flow should revert to the "Sign in" flow once it's identified that the user is part of an existing SSO domain, NOT prompt them to create a new site.
7a79c351a973 it is easy to see why the average user would mess this up. Either Atlassian are brand dead with their landing page UI design or they are very intentionally trying to get people to do this. It is MOST confusing on the Google sponsored ad landing pages. Example here: [Confluence | Your Remote-Friendly Team Workspace | Atlassian|https://www.atlassian.com/software/confluence?gclsrc=aw.ds&&campaign=18312196225&adgroup=138055852541&targetid=aud-2204202926820:kwd-22737151&matchtype=e&network=g&device=c&device_model=&creative=696317320971&keyword=confluence&placement=&target=&ds_eid=700000001542923&ds_e1=GOOGLE&gad_source=1&gclid=Cj0KCQiA1p28BhCBARIsADP9HrPuEoDnluTGoEgn9FeJonDvb1Wn1dhQxfza2iYbgElKde1iyGtZpZsaAr5kEALw_wcB]. They make this look like a SIGN IN page. Someone enters their email address there and clicks sign up and it IMMEDIATELY spins up one of those new sites. BRUTAL. I've tried to identify as many of these URLs as possible and I have added them as an indicator of compromise in Defender to block our users from going to these sites. The problem is, the URLS change frequently since they are paid ad landing pages so it's an exercise in futility.
Does anyone know exactly how users are managing to accidentally create these sites? The users tell me that they were prompted to do so when logging in somehow, but I haven't been able to replicate it. If Atlassian were able to fix whatever UI flow prompts the users to do this, that would go a long way towards mitigating this issue.
Indeed, no need to upgrade to "paid" site to get a site deleted, just create the ticket on your main site.
During some time I created tickets for multiple sites, but now I create a ticket for each site separately (I have a "template" for this kind of tickets, where I also explain that I don't agree with this practice).
Atlassian must feel how all customers are wasting their time on this stupid and shameful shadow IT practice, which also creates serious security issues!
Darryl Lee - just open a ticket on your main tenant. We are going to do this every single time a user creates a new site/product. Atlassian needs to fix this.
1ddde525104a and 7a79c351a973 - Yes, I open a ticket to expedite every time, but as I mentioned briefly, many of these sites are created as free, and there is no way to open a ticket for free sites. So ironically I have to "upgrade" these sites to paid plans before I can file tickets to have their deletions expedited.
27c4fad69a4e - I was told that "soft deletion" of an instance (Jira or Confluence site) will allow deletion of the Organization. This was proven to be true after a recent soft deletion where I was able to then delete the Organization. (Woe to the person who has to try to "undelete" a site after you've deleted the Organization.)
That’s a great point. We too are considering opening a ticket to expedite every single time this happens. This is ridiculous. When we have to waste time on it, Atlassian gets to waste time on it.
I will add my voice of disapproval to the many here. We have users regularly accidentally creating new products/sites. It's such a waste of time and money to chase those up, disable them, wait a couple of months then delete them. Please make this setting available to non-enterprise customers - this is not an "enterprise feature", it's a basic IT governance control.
I'll try raising tickets with Atlassian support to expedite deletion of these every time it happens.
8f4050917dd7 Does this also account for the recent change I keep getting reference of when requesting accidental site deletes?
Unfortunately, there has been a change in our internal processes regarding expedite deletion. The new process will take 15 days for the soft deletion, during which the instance will no longer be available in your org, but it will take another 30 days after the soft delete for the complete deletion, meaning the total deletion process will take 45 days.
8f4050917dd7 Interesting, I will try this. I did file a support ticket the first time, but it was unsuccessful.
I'll try replicate your steps and see if I can get the sites removed with expedition.
Still won't fix the underlying issue that it's seems FAR too easy to accidentally create new workspaces connected to our email domain. All three have claimed they tried to log in to Confluence / Jira and accidentally ended up with a new space.
Hi 9f4060b22593 - I certainly don't want to make excuses for Atlassian, but their Support Team has been fairly responsive. It has typically been around a three week process where I have to keep up on tickets and scheduled deletion dates. Here's a recent process from start to finish.
- On 2024-11-26, I discover THREE new sites accidentally created on 2024-11-24 and 2024-11-25.
- Cancel sites (and I upgraded Free sites to Standard Plans so I can specifically select support for the "paid" site) - A recent example: 2024-11-26
- File a support ticket requesting expedited deletion - I put all 3 sites in one ticket, filed 2024-11-27 - took the day off for Thanksgiving.
- Support will want to confirm that I REALLY WANT TO delete the site and NO I do not want to rename it. - 2024-11-28 - I replied the same morning
- Support will forward the request to the deletion team, and they say the site will be "soft-deleted" in 15 days. (Which is sufficient to be able to delete the organization.) - 2024-12-03 confirmed deletion request was sent. I requested exact date.
- Expected deletion date: 2024-12-18
- I will typically NOT allow resolution of ticket, and if they ask, instead request that the ticket be frozen until expected deletion date.
- Today was the day (2024-12-18). Sites were deleted as promised. I did NOT get any email confirmations about site deletions, nor was the ticket updated (so yes, this is another thing I have to check regularly).
- Deleted Organizations.
So yeah, not 75 days. But still hella annoying.
Came here looking for a solution to the problem, but only met with "Pay for Enterprise and this won't happen"? That's mind boggling!
In the last 2 months, we have had 3 separate users accidentally creating new Confluence workspaces when they meant to log in. It seems disturbingly easy to make this mistake for an unexperienced user.
And to add to it, there's a 75+ DAYS waiting time to fully remove a workspace, even if you act on it within minutes of creation. No words.
I'm thinking this is worthy of a class-action lawsuit. How many of us are paying for guard licenses which have just 'appeared' on our bills because our users accidentally sign up for trials, all the while they (Atlassian) have the capability to prevent it, but ignore it out of greed. Atlassian is not a company that lives by their values.
I'm not gonna point the finger at gjones@atlassian.com, moves like this smells like management/leadership forcing the issue & direct the underlings to gaslight customers with obfuscating claptrap and pass it off as a resolution.
There is no way a managed user part of an authenticated domain should be allowed to create new product. We pay for Premium and Guard for exactly that type of governance.
Charitably, this is a huge oversight.
Uncharitably, this feels like a bait-n-switch, shadow IT money grab.
Hi,
Please check this article (and scroll through the long history of posts):
There are many articles about the same problem, these are just some examples:
- https://jira.atlassian.com/browse/CLOUD-10325
- https://jira.atlassian.com/browse/CLOUD-12089
- https://jira.atlassian.com/browse/ACCESS-1645
- https://jira.atlassian.com/browse/ID-7697
- https://community.atlassian.com/t5/Confluence-questions/SECURITY-ISSUE-during-login-procedure-of-managed-users/qaq-p/2841895
- https://community.atlassian.com/t5/Questions/Why-is-Atlassian-promoting-Shadow-IT-Or-Accidental-IT/qaq-p/2731538
- https://community.atlassian.com/t5/Enterprise-articles/An-update-on-product-requests-bringing-shadow-IT-controls-to/ba-p/2840760
- https://community.atlassian.com/t5/Articles/Proposal-to-prevent-Accidental-Site-Creations-accidentalit/ba-p/2867193#M558
Shame on Atlassian!
They couldn't care less about their customers!
Stefaan
Please make this available for all plans. We have users creating Atlassian Cloud product sites by accident and we can't do anything about it.
There is no development for the standard plan yet as far as I understand.
When will you solve this problem? If daily monitoring is not done because of this situation, it will cost us.
You are especially charging for users under the same domain that was previously set up for trial and not removed.
Please correct this mistake.
Explaining this situation during the renewal period harms your company and the our companie that use it.
This is not a resolution - this is a "solution" that simply brings Trello and Bitbucket into the Enterprise plan money grab. We have problem "A". You just solved problem "B." Thanks for
This is a disappointing and unacceptable response and is not customer-focused. It would be one thing if this functionality didn't exist at all, but having it available and choosing to paywall it behind Enterprise goes away from a core Atlassian value: "Dont #@!% the customer"
Here's my vote - This IS unacceptable. The only reason to reserve this admin functionality to Enterprise is to force orgs to upgrade. Some people call this a money grab. It is advantageous to Atlassian to do it this way - 1) It increases the user base and, 2) increases the probability that unwitting users become entrenched and add on paid products or, forces organizations to upgrade to Enterprise.
As the person that sets the strategy for our organization, this makes me strongly consider other options.
This is security 101. Please enable this feature for all. Do the right thing.
This is very bad business practise, Atlassian team!
It is security flaw what should not even be possible to allow non Admin users to create new instances without any validation and then automatically transfer those new sites under company billing plan. All my users who have created those sites (I'm dealing with a third case on this month) do not even realize what they have done as in their mind, they just logged in and then Jira started to ask some questions they just answered something to get in. To restric this from happening by hiding this under some paywall is cynical and not very professional way to handle this. This should be considered as a bug to be shamed of, not to promote as a paid feature. You are better than this!
Just a thought - should we open a new JIRA issue since this one is closed? We might be commenting under the proverbial rug given the issue status.
Just wanted to add my $0.02 that this is absolutely ridiculous. A non administrator managed user shouldn't be able to create any new products or organizations under our account. And certainly paywalling this basic functionality behind the enterprise license is probably the least customer focused decision that Atlassian could make.
If this is bothering you like it is me, see also the following recommended further reading :
- https://jira.atlassian.com/browse/CLOUD-10325?focusedId=3519823&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-3519823
- https://community.atlassian.com/t5/Confluence-questions/SECURITY-ISSUE-during-login-procedure-of-managed-users/qaq-p/2841895
- https://community.atlassian.com/t5/Questions/Why-is-Atlassian-promoting-Shadow-IT-Or-Accidental-IT/qaq-p/2731538
- CLOUD-12089
After 4 site deletions in a few months, it sure seems Atlassian's open door policies allowing licensed users with a claimed domain to go out and create new sites that get billed back to the original is just too convenient.
The provided "solution" is just shuffling off additional manual work to administrators & waste time going through the same mundane & tedious steps: reach out to user that created organization, cancel whatever subscriptions they set up, create a ticket to Atlassian support to DELETE the organization, wait for 2-3 weeks, repeat.
Oh my lord, you guys really put what should be a standard (or at least Premium, what are we paying extra for??) security feature behind the Enterprise paywall?
I'd say that decision did accomplish one thing, now we know this security 'gap' was architected by Atlassian as an opportunity to collect unintended subscription fees. And their solution to fix the gap is....collecting even higher unintended subscription fees.
What Stefaan said - basic security and organization management for our site should be a function of every Atlassian plan, it's crazy to think that something as basic as this has been throttled to only Enterprise plans.
Being able to control the creation of new organizations/sites/products by managed users must be a standard security feature for every paid product version, otherwise why name the user a managed user?
The standard Atlassian products contain the ability to set permissions on users and groups, but not the ability to block organization/site/product creation by managed users? C'mon!
Also Atlassian is fully aware of this: the "discovered products" function is located under the "Security" menu item, indeed, because it is a security hazard!
Moreover, it can take up to one month before such shadow IT site created by a managed user shows up under “discovered products”, this is completely unacceptable.
Even worse, the UI design by Atlassian continuously tricks the managed users into creating new organizations/sites/products by accident, especially during login.
Instead, while logging in to the platform, a managed user should be guided towards the organizations/sites/products that he/she has access to.
Any organization that takes security and data protection seriously, cannot allow such practices of guiding the users away from the managed environment.
Any self-respecting organization should also not implement such "features".
More:
https://community.atlassian.com/t5/Confluence-questions/SECURITY-ISSUE-during-login-procedure-of-managed-users/qaq-p/2841895
https://community.atlassian.com/t5/Enterprise-articles/An-update-on-product-requests-bringing-shadow-IT-controls-to/ba-p/2840760
As the one introducing Atlassian products (Confluence and Jira, 800 payed licenses!) in our company and encouraging everyone in our company to use the Atlassian products, I have to comment here and push Atlassian to stop this shadow-IT misuse!
Please Atlassian, we cannot continue like this!!!
This shows how little Atlassian cares about anything other than profit. Every year, they increase their license prices by about 10%, despite having millions of paying users. Meanwhile, there are features that have been requested by thousands—sometimes tens of thousands—of users that remain ignored for years. I remember how long we waited just to get a simple text-highlighting option in Confluence. It's ridiculous.
The lack of this feature is a major issue for our company. It feels like they want to avoid fixing it because they know they might getting new paid users this way, leading to more profit. It's infuriating to think that someone with the power to make a difference is just driven by greed and don't get me started about the "premium" licencing...
gjones@atlassian.com how come it's closed and not possible to vote for when so many customers clearly see this as a huge issue with the product?
It seems Atlassian will not implement this without enough pressure, so I will do my part to create the pressure by creating support tickets every time a user creates one of those shadow IT sites and request the deletion. I'm really, really tired of stacking piles of falsely created instances.
It's not acceptable that 1) this feature is locked behind the enterprise license, it should be part of the standard license and 2) it takes MONTHS to delete these user errors again.
The fact that this is considered an enterprise 'feature' (which undoubtedly should be considered a BUG fix), is outrageous. Shadow IT systems should under no circumstances ever be allowed to exist in the first place. Why hide this so called 'feature' behind a paywall which fixes something that shouldn't even be allowed to exist in the first place?!
Just like the people whom commented before me, our users were fully unaware they were creating sites and adding products to it. As ef4a19b077a6 mentioned, it more or less appears that Atlassian is straight up encouraging personnel (which lets not forget, they are ALREADY making a profit from as they are licensed by their company) to spend more money unknowingly and unwillingly on their product, whilst also creating an absolute mess for IT staff to clean-up (as the removal process is a pain to say the least...).
It also concerns me that standard users are able to perform administrative actions which we (as organisation) 'should' have full control over. This has potential to introduce data leaks and privacy concerns as many regular users simply lack certain knowledge on how to properly manage digital landscapes (hence you should divide 'regular' and 'administrative' users for certain actions, site-creation and adding products being two of them).
I truly want to encourage Atlassian to revise their statement and introduce this "BUG" fix to ALL paid license models they provide. Until then this issue has NOT been fixed for the gross majority of people watching this ticket, thus should not be considered as such.
dca798797247, ef4a19b077a6 is on the right track - as I've confirmed this with my users and documented the flow with screenshots here.
As I mentioned over in CLOUD-10325, if Atlassian isn't willing to "give" non-Enterprise users this feature, it would be nice if they addressed the BUG in their sign-in/sign-up process that has managed users (whose org already has existing Jira/Confluence sites) go through a login process and "Welcome" those users, only to essentially trick them into accidentally signing up for new sites, when all they really want to do is log into their existing ones.
I've interviewed several of my users, and they all say they did this by mistake while trying to log in.
This could be fixed if Atlassian redirected users after logging in (who again, it already KNOWS if they have accounts in existing sites) to https://home.atlassian.com/
They need to treat this as a BUG, not a feature request.
So I guess we just open another issue and all pile in there with vitriol again? This is ridiculous. We use a TON of SaaS tools and this is by far the MOST admin unfriendly stance I've ever seen a SaaS provider take. Unacceptable.
I'd be curious to understand how Atlassian justifies doing this to paying customers based on their core values.
- "Open company, no bullshit" - Please be open and transparent with us as to why you think this is a feature that paying organizations shouldn't have? Why is this hidden behind "Enterprise"?
- "Build with heart and balance" - I don't think you've "consider[ed] options fully and with care" - unless of course, you've considered it and thought "ehh #@!% 'em I can make more money doing it this way than being decent and helping people who pay to use my platform."
- "Don't #@% the customer" - As the customer, I feel like you're #@%ing me. Everyone on this thread feels that way.
- "Play, as a team" - You guys "spend a huge amount of [your] time at work." So do we, and we'd like to spend less, and if you guys would listen to what we're telling you, instead of milking us for profit, you'd probably agree that this is bull that you don't provide this feature to all of your PAYING customers.
- "Be the change you seek" - "All Atlassians should have the courage and resourcefulness to spark change - TO MAKE BETTER OUR PRODUCTS, OUR PEOPLE, OUR PLACE..." So, is there no one with the courage and resourcefulness to take up the mantel of your PAYING customers to make change to such a foolish and greedy decision?
I guess we'll all just have to sit here and wonder if Atlassian will have the COURAGE to stand up for the customers they are #@%ing over. But don't hold your breath, as we have yet to see any response from Atlassian even acknowledging that there might be some contention over such a #@^ing stupid, greedy decision as this.
You have the capability, you've hidden it behind a paywall, and you refuse to acknowledge that... all the while you pretend like security is important - but only if people are willing to pay EVEN MORE for it.
Yeah not really fixed if this is an Enterprise feature. We are premium customers so I would expect this to at least be a feature for Premium level subscribers.
Agreed. Placing a feature designed to prevent costly misuse behind a plan that demands even higher payments is questionable, if not exploitative. We’re not freemium users; we're already paying customers. We need controls to prevent user errors from leading to cost increases or wasted time, especially since the cancellation process is neither quick nor straightforward.
Why is this implemented for only those with Enterprise subscriptions to the tools that this control supports? If I don't use Trello at all, for example, I should be able to block random managed accounts from creating it.
I get you want to jack up ARR, but this is a really ugly way of doing it.