Could we not grant new users edit rights to Confluence until we have a better spam control solution?
Right now it takes about 15 clicks to delete 1 user and 1 page in Confleunce. At one point, a user I deleted was still logged in and creating pages almost faster than I could delete them.
Is there a way to kill a login session after I’ve deleted a user?
Done and announcement made:
Thanks. Does Atlassian have anything to say about this problem?
I need to do similar for jira but I need sleep this kills ONE of our issues.
Confluence/crowd should have a rest api, I believe some of those operations
could be done by script? Sorry, no experience there.
The problem is alleviated for now. I now have motivation to automate things though.
The other thing we need to think about:
- do we want to do similar where users can search for, but not create issues until they are trusted within the community?
I don’t think we can do that with JIRA – I’m not sure how to handle this.
I spend time each week deleting spam JIRA tickets, so I would definitely
appreciate a gate people have to pass before being able to create tickets.
Our JIRA setup already asked anonymous read access.
-Darius (by phone)
I can probably safely delete any user whose username starts with a number
Just spent past few hours deleting spam and we’re spam free at least in the Documentation space: https://wiki.openmrs.org/display/docs/Home
UPDATE: All spam is now deleted! New users will have to go out of their way to ask us for access and I will actually ask what they need to edit and why they need it.
Okay – so we do not allow anonymous issue creation AT ALL now on jira. I’ve switched permissions in jira already,
I propose the following, LDAP groups is how things are managed with Atlassian products so here’s the current way I have it:
Users are NOT granted access to confluence by default. They must request it.
This SHOULD filter out spammers. This is only one way to go about it.
ID Dashboard doesn’t block jira users. I have the conf file changed for ID dashboard to also not grant access to jira but that’s a thing I’m not 100% comfortable doing…
We need to grant jira access on a case-by-case basis now.