As I came into work this morning my colleague, on a phone call, glanced up and said, "Hold on, he just walked in." Oh great.
The user was telling us that our Enterprise Confluence (4.3.1) installation became over-subscribed. Not a big deal, or at least it shouldn't be. It turns out that Confluence does not just disable the user who joins. No, it disables editing for *all users* until the oversubscription is fixed.
Why should one innocent user be able to create an enterprise-wide crisis? (Yes, Confluence does serve an important function in our enterprise--at the moment).
OK fine, I'll just inactivate the user who is over-subscribed. Oh wait, that feature is busted in Confluence when LDAP integration is enabled, because Confluence expects to be able to edit your enterprise's AD in order to disable users, and no combination of user-directory checkbox settings will disavow it of its misguided notion that AD write access is not necessary.
What I *CAN* do is directly edit the Confluence database to set the desired users 'active' to F (false). Finding these users requires a complex query that must be obtained from Atlassian's legendary support. To wit:
select distinct(u.user_name),u.active,d.active,u.updated_date from cwd_user u inner join cwd_membership m on m.child_user_id=u.id inner join cwd_group g on m.parent_id=g.id inner join cwd_directory d on d.id=u.directory_id inner join spacepermissions p on g.group_name=p.permgroupname where u.active='T' and d.active='T' and p.permtype='USECONFLUENCE' order by u.updated_date desc;
This whittled down the 2,702 rows in cwd_user to the 505 that actually matter. Unfortunately, after updating the over-subscribed users, I have to restart Confluence in order for it to notice.
Here's some salt for the wound: I get plenty of notifications from Confluence that my license is getting close to expiration, and I need to pay more money. But I got not a peep's worth warning that the next user to log into Confluence is going to precipitate a hostage crisis. It's the users who have to let us know.
Why didn't I just pay more money earlier and sidestep the whole fire drill? Because Atlassian's licensing model jumps from 500 users to 2,000 users; there is no in-between.
What am I asking for?
1) Fix Confluence's behavior when a user over-subscribes, so that only the over-subscribed user is affected. The current behavior is inexcusable.
2) Fix user disabling so that it works from the web UI.
3) Send notifications when the active user count is getting close to the limit.
I just wanted to pop in here and say that I really like the discussion that is going on in here. This is exactly the kind of community feedback we are looking for. I did some poking inside out tracker and found the following two issues.
The first one looks like it timed out for some reason. I am looking into getting it opened back up. I have attached this post to both tickets to impress on our developers that this is a pain point for our community. Please do your part by visiting and voting on these issues. I am happy to do what I can to field additional questions, comments or complaints.
So...I understand your headache...I've run into it before. One thing I can recommend is that you change your LDAP setup to leverage the "Internal with Auth" user directory setup. It basically handles the LDAP auth validation, but the user is stored locally and synced to some extent when they login. This give you the ability to click the "inactive" check box and disable the user, thus reducing the count. Also...I don't know your setup or size of AD, but "syncing" should pull folks who are no longer there.
Changing your Auth isn't easy. What I've done is created a new directory, moved it to the first postion, so as folks add, it creates them there. The old directory in one instance, I just "disabled" it, users went "away" but still owned their content and when they signed in again, things more or less worked. There were some bumps.
As for the notifications, that has largely been left to the administrators to find the solution that works for you. For as many times as you'll say "tell me when count is getting close..." there are a bunch of folks who would say "I might add 1 license in a year and don't care." The solution I've chosen to do is to have a script that runs at an interval that queries the user counts and bumps that up against a license config file. I've also created a script to poll users that haven't been in the system for a long period of time so that I can clear up some licenses there.
Another thing would be that Atlassian is there to help, so you could engage them via support and request improvements/modifications.
But...I've been there. No one can use the system because there is one too many in the pool.
Thanks J. for the commiseration and the helpful suggestions re: LDAP configuration. I have engaged Atlassian support previously on this topic; agreed, they do indeed seem to be there to help. Atlassian's Confluence dev resource management, however, appears to be another matter. The broken user management has been on their radar for years and is still not addressed.
If this were my only issue with Confluence, I'd give LDAP reconfiguration a shot. At this point, however, there is no part of me that wants to continue to code around Confluence shortcomings. Their wholesale abandonment of their wiki users really smarted for us, and this is close to the last straw. We've paid our (additional) $7K to make the problem go away for a year. I'd be a little surprised if we were still on Confluence next April.
Well now, there's the rub :-) For all my griping, I haven't been able yet to find a viable enterprise alternative, and neither has anyone else in my org, which seems a truck-sized opportunity for someone (e.g., JetBrains? http://youtrack.jetbrains.com/issue/JT-7724). As for why, many devs are frustrated to distraction with the Confluence editor since it departed from its wiki roots. Before that, there wasn't much signal for change. (It's also extremely annoying that most of the formerly free Confluence plugins we were using now cost several hundred bucks a pop, but that's a secondary irritation).
Ok, I asked you because I do not think (despite the trouble you had) that there is any viable alternative to Confluence. I mean, you have the right to be angry, but ... let's put it in the real light.
Edit: just imagine that instead of Atl, is a giant like Orcl or my former employer I_M (hangman- guess the letter). You could do your angry dance all the time, they do not really care. Trust me.
Exactly. I_M owns Rati_nal, which makes Cle__Cas_, and I've been through it with them as well--and it was completely futile. I do hold out hope that a Real Confluence Developer will respond and acknowledge, "Yes, this is badly broken, and I will fix it". Does that make me out of touch with reality? Perhaps. Failing that, I do see that the JetBrains ticket ref'd above keeps accumulating votes. Not sure what the tipping point is...vote early and vote often!
I feel you a bit on the plugins...but I also understand why. It's not a large community of folks who maintain them, and folks gotta eat. :)
I also understand about the move away from wiki markup. I've heard no end to it from some folks here, but I also understand some of why they did it. Having to do double work isn't smart, and they want to make sure they have broader appeal then just techies. I do think a bit of it is still "you should dance with the one that brought you..." that we weren't quite ready to give up wiki markup.
Yeah, true about paying for what you use. Still feels like a bait-and-switch, though, the way it came about for our particular suite of plugins, a princely per-plugin sum at that, and it all seemed to happen at once. I just found a plugin we missed; amend that $7K to $10K, ouch.
I'm OK with broader appeal. In my opinion, they departed 'way too far from their roots; the whole move was poorly conceived and badly executed. I'm bitter about having to abandon complex formatting because the editor simply doesn't work. If it was a real editor, I might feel differently about it.
Sounds like Confluence is mission critical from the tone of your posts.
Just doing the math here.
You say you have 505 users.
And you had to increase your monies paid to Atlassian today by $10K annual (which will go less next yr - since renewal is less).
Isn't "mission critical" systems to the business worth an extra ~$20 per user/annual of value and productivity to your company - literally and tangibly?
(actually - $19.80, or $1.65 extra per month/user)
To me, that does not seem like a lot of money for a corp that size. Or even 1/4 that size if its making your company run and communicate better..
On the pts on over-subscribing, in my experience with customers, usually the admins are watching that number pretty closely when they are getting within 20-50 users of the limit, since its not like that many new people start at companies instantly usually.
We've worked with 100s of customers over the years, and I've never once encountered this in the field yet. We have gotten lots of license upgrade orders though, so you are not alone in tipping past for sure.
Just my experience.
You are right Ellen, it's really not that much money. Confluence is important, but I wouldn't say that it's mission critical; part of the tone of my posts comes from the kind of day I had with Confluence, so please correct for that effect when reading :-)
It's not really about the money, it's about the trouble for admins and users. As an admin, my point is that I shouldn't have to watch that number. An admin interface that punishes the whole community so harshly for such a minor infraction is badly broken in its design and implementation. A single user should not be able to so easily, accidentally break the system for everyone *simply by logging in*.
For instance: JetBrains' TeamCity does per-build-agent licensing, and if the agents become over-subscribed, no builds run until the issue is fixed. Kind of like Confluence, right? Except that TeamCity does not allow users to put TeamCity in that kind of state. In fact, it's hard even for admins to put TeamCity in that kind of state. Agents cannot be authorized against the license count if there are no licenses left--very much unlike Confluence. And if TeamCity *does* get in that state, it's easy to take away an agent and fix the issue immediately--again, very much unlike Confluence.
I'd agree there - the model for Jira when you're not using LDAP is far more sane - everything works until you hit your user limit, then the one function that stops working is "add new user". Which doesn't break anything else.
I know having external systems handle the numbers makes it more complex, but killing the app because you've gone over the limit really isn't the right approach, and nor is relying on admins to keep an eye on it. (Ok, my last one, I had a script that mailed me user numbers every day, but all that did was tell me "probably time to panic on Wednesday", which still doesn't feel right).
One possible solution I saw in another app was to put a banner on the screen when the count had tipped over, and then the user that did it, plus any new ones, were dumped into a "can not log in and so don't count" group.
Nic - So...I agree, but for me, it's been one of those minor issues. I am in the systems enough, where I generally know the state of the licenses. For those instances where I'm in really limited licensing (100 or less) I make my process be more restrictive so I avoid walking into a bad day because of licensing.
But...if I have a vote (which we all do to some extent), I'd prefer to put the vote towards improving the editor or some other things that annoy me more or are more problematic that chew up more of my time. I know the weakness in the licensing management and can by and large, address it to midigate the risk. Do I still get bit? Yes...but normally it's a "darn me for ignoring that email..." Honestly...I get bit worse by users or people I'm training by saying "but this is how it should work..." and having to clean that up.
That being said...I say, create an improvement request. Circulate it and let people vote. Atlassian says that part of their dev and road map should be driven by the community.
@Chris - Perhaps you should log here: http://jira.atlassian.com - a better place for this design/feature requests (or maybe already there?)
Things can get lost in here at the PM level I would guess - JAC is the place for roadmap items, since of course you and @Nic have some good pts on the solution proposed.
I pushed back on the other b/c I really get so tired of admins complaining about cost/value - even WITH plugins. (And the past freebies were simply lucky days - but past.)
Atlassian and plugins are *not* expensive for Enterprise software, period, for 500+ orgs especially. That argument really needs to die, imho.
(And fair enough abt the bad day - been there. ;) I guess good that its Friday?! TGIF - have a great one!!!)
Agreed, cost is comparatively minimal (compare to Github-Enterprise, for instance!). I certainly could've persuaded my company to upgrade earlier and sidestepped the whole light show. Lesson learned. And since we'll not approach 2,000 users for a long time (to my knowledge, at least), this particular set of design flaws and bugs has now become a non-issue for me.
As for jira.atlassian.com...The LDAP user-disable bug was brought up here years ago, complained about repeatedly, but not responded to by anyone discernible to my untrained eye as associated with Atlassian development. Doesn't give hope for being heard. https://jira.atlassian.com/browse/CONF-22337
Yes, happy Friday Ellen. May yours be great as well :-)
Hey there, folks! For most of us, the past six months- yes, you read that right- have been a journey. More people than ever before have pivoted to working remotely, and navigating being on-scre...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events