Remove internal user lookup

[dimitarOnGithub]

This PR removes the internal user lookup functionality performed by the assign_issue, add_watcher and remove_watcher methods.

By doing so, issues reported in #1855 and #1284 should be resolved and #1734 might also be fixed, though further testing is required there. Additionally, this fixes an actual bug that the internal lookup logic introduced, namely the fact that while _get_user_id method would work for 100% exact usernames, it'd still return the first result if it fails to do so, as seen below:

Cloud

>>> jira.search_users(query='dummy')
[<JIRA User: displayName='dummy', accountId='...5c6e8'>, <JIRA User: displayName='dummy', accountId='...39292'>]
>>> jira._get_user_id('dummy')
'...5c6e8'

Server

>>> jira.search_users('bot')
[<JIRA User: displayName='CDE Bot', key='cde.bot', name='cde.bot'>, <JIRA User: displayName='Ops Bot', key='opsbot', name='opsbot'>, <JIRA User: displayName='Dev CO Bot', key='devco.bot', name='devco.bot'>]
>>> jira._get_user_id('bot')
'cde.bot'

This is caused by the fallback assignment that returns the first user from the search results if it fails to find an exact match.

It also makes the _get_user_identifier method public and provides the ability to pass a User resource object to the methods.

Going forward, users will have to provide the exact username (for hosted) or accountId (for cloud) in order to perform any of those operations.

[dimitarOnGithub]

@adehad this is the PR for what I mentioned on #1855. I did some manual tests for both server and cloud on the instances I have access to, but I didn't quite manage to set up my local environment for the automated tests, I need to spend some more time on that as it seems harder than the JIRA library itself haha

[adehad]

In general I like the idea of the merge request and it is the direction I want the library to go moving forward, I don't want to be passing strings or integers around, I much rather they be objects.

I think what we are missing in the orignal implementation was checking if the entered str/int was a valid user. In a sense could we use JIRA.user(id_or_accountId) to first check if the user provided a valid complete ID, if so then use that, otherwise fallback to the search and maybe add a warning to use a more specific search

[dimitarOnGithub]

Sorry about the mess with the docs, for some reason my local working copy was showing the document entirely borked, hence why I did the silly thing with the indentations. b0b552e should fix that.

[adehad]

just something I noticed that would be pretty critical to his working is removing this decorator that is trying to be helpful but removes the type safety unfortunately.

I thought we had a code coverage action but it isn't seeing the stats from this PR, so I couldn't exactly confirm it wasn't reaching the new code branch

[adehad]

Suggested change

@translate_resource_args

It will be critical for this approach to work to remove this decorator which would have automagically converted the object to a string

[dimitarOnGithub]

I don't think the decorator touches on the User objects, it seems to only manipulate the Issue in this case

[adehad]

Suggested change

@translate_resource_args

[adehad]

Suggested change

@translate_resource_args

[github-actions]

Label error. Requires exactly 1 of: bug, enhancement, major, minor, patch, skip-changelog. Found:

[dimitarOnGithub]

@adehad sorry for the delay with this, here's the updated functionality with having a with_lookup flag in the JIRA's init.

Not sure about the linter errors in the automatic checks, the value provided is a str which is one of the expected variable types.