Open Strekerud opened 7 years ago
Also happens on 7.1, also passing active=False when creating a user has no effect. No error shown. JIRA log sez:
Absolutely nothing! :)
However, the method does not call a REST API, as visible through access logs, like:
<IP> 903x280x1 <user> [02/Mar/2017:15:03:56 +0100] "POST /secure/admin/user/EditUser.jspa HTTP/1.1" 200 1114 117 "-" "python-requests/2.12.4" "<some-id>"
So I thought it might require a separate websudo and bingo:
jira._gain_sudo_session({}, '/')
jira.deactivate_user('foobar')
this worked!
jira.user("foobar").active
>> False
@E14 do you know to activate the user after deactivation? gain_sudo_session worked for me. Thanks for the pointer.
@ahmedsajid Yes, I had to solve that too. I have extended "JIRA" so self
is the jira object. It will also require a _gain_sudo_session(...)
before calling it, I've deliberately duplicated the behaviour of existing functions that operate on admin-interface forms in this.
The below code is mostly (save the error logging part) ready to include into the project as well. (Unless there are some Python 2 incompatibilities)
def activate_user(self, username):
"""Enable/activate the user."""
url = self._options['server'] + '/secure/admin/user/EditUser.jspa'
self._options['headers']['Content-Type'] = 'application/x-www-form-urlencoded; charset=UTF-8'
user = self.user(username)
userInfo = {
'inline': 'true',
'decorator': 'dialog',
'username': user.name,
'fullName': user.displayName,
'email': user.emailAddress,
'editName': user.name,
'active': 'true'
}
try:
r = self._session.post(url, headers=self._options['headers'], data=userInfo)
if r.status_code == 200:
return True
else:
logging.warning(
'Got response from activating %s: %s' % (username, r.status_code))
return r.status_code
except Exception as e:
print("Error Activating %s: %s" % (username, e))
@E14 Thank you very much!
Do you want to submit a pull request to have this incorporated into the next release?
@asqui actually, not yet, feel free to put it in, if you want to have it in now already, but for me there are some questions open (logging, proper exceptions, Jira version/Python compatibility, ... more?), and I'm rewriting this method soon anyway to put in a possibly more controversial addition of _ensure_sudo_session()
I am getting the following when trying to utilize the workaround:
>>> auth_jira._gain_sudo_session({}, '/')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "acct_mgmt/venv/lib/python3.6/site-packages/jira/client.py", line 2854, in _gain_sudo_session
'webSudoPassword': self._session.auth[1],
TypeError: 'JiraCookieAuth' object does not support indexing
Anyone have a chance to see why this is happening?
Which Jira version are you on? Also, I haven't used this on > 8.x yet, but it seems I have to verify that now...
Hello, thanks for getting back to me!
Atlassian Jira Project Management Software (v7.13.3#713003-sha1:0709f78)
Were you able to find a fix for this?
@f0rkz Not sure. Have you by any chance disabled displaying of e-mails in the Jira global config?
Hello, user email visibility is set to public.
@f0rkz Sorry I can't really help here anymore, I'm working somewhere else now - I just remember that this was the issue. Once e-mail visibility was turned off, self.user didn't contain the e-mail address anymore, so you'd have to read it from the overlay. It wasn't terribly complex but I couldn't get around to it and now I don't really have access...
Anyway, since the REST API depends on configuration, you shouldn't rely on the e-mail field to exist at all.
Deactivating users was introduced in this PR: https://github.com/pycontribs/jira/pull/217
The below code returns True, but the user is not deactivated in Jira, and the user is still counted towards the license.
We're running Jira 6 (v6.2.5) on a non-cloud instance.