[#759] scan and apply user_zone properly when igroupadmin creates a user #760
Conversation
|
need to write a test wherein we create an entry in the catalog for a remote-zone user, then add and remove that user from a group. |
| _user_name = user_name + ("" if not user_zone else f"#{user_zone}") | ||
| else: | ||
| _user_name = user_name | ||
| user_name, user_zone = user_name.split("#") |
There was a problem hiding this comment.
Two more cases which we might want to consider / test...
- What should happen if
create_with_passwordis called like this?
groupadmin.users.create_with_password("newUser#tempZone", "newPassword", user_zone="otherZone")- Or this?
groupadmin.users.create_with_password("newUser#tempZone#otherZone", "newPassword")For reference, iadmin mkuser returns a USER_INVALID_USERNAME_FORMAT error when doing something like (2). I don't actually know if that's coming from the client or server side.
There was a problem hiding this comment.
Neither of those cases make sense to me. Can you explain what the goal of those are?
There was a problem hiding this comment.
Is the user attempting to create a remote user in the local zone?
There was a problem hiding this comment.
I think he's just writing a pathological test to check the behavior of the system.
There was a problem hiding this comment.
Does the iRODS server accept case 1?!
There was a problem hiding this comment.
it can be appended to help form the _user_name parameter in line 72.
Sorry, I should clarify. I was more referring to the fact that the user_zone parameter is not passed to the server directly. If provided, it is grafted to the user_name, but not sent as a separate parameter to the GeneralAdmin API.
Anyway, this conversation was originally about adding some pathological tests around this feature. Perhaps we should open a separate issue for that for later if things are working as intended now. Then, we can address that at another time and get this in for the next release.
There was a problem hiding this comment.
Sorry, I should clarify. I was more referring to the fact that the
user_zoneparameter is not passed to the server directly. If provided, it is grafted to the user_name, but not sent as a separate parameter to the GeneralAdmin API.
You mentioned the GeneralAdmin but it's actually the UserAdmin api we're using in this function, yes?
In a nutshell, UserAdmin lets you specify zone for a user to be created but only as part of a USER#ZONE formatted username. So, given that fact, are there any further suggestion or questions for me about how/whether this code should change? The code as it now exists in this PR seems to support that, so I'm a little confused still about the scope & purpose of this conversation....
There was a problem hiding this comment.
(Apart from the pathological cases, which i can certainly look into and/ or include in a test. )
There was a problem hiding this comment.
I could make _user_name more distinct to make it clear it includes a potential zone field
There was a problem hiding this comment.
What do you think, user_optionally_with_zone?
| # ------------------------------------------------------------------------------------- | ||
| # Not sure why, but repeat runs of this test give CATALOG_ALREADY_HAS_ITEM_BY_THAT_NAME | ||
| # unless we vary the username on each run. (discuss: is this a new iRODS issue?) | ||
| # ------------------------------------------------------------------------------------- |
There was a problem hiding this comment.
I'm guessing we can now remove this comment because the problem turned out to be #763? Have you tried updating the call to remove the test user(s) and seen success?
In any case, we should either remove the comment or put in a TODO comment linked to that issue.
There was a problem hiding this comment.
maybe change the comment to say "remove randomization of user name on resolution of #763" since that issue is in future milestone?
| _user_name = user_name + ("" if not user_zone else f"#{user_zone}") | ||
| else: | ||
| _user_name = user_name | ||
| user_name, user_zone = user_name.split("#") |
There was a problem hiding this comment.
it can be appended to help form the _user_name parameter in line 72.
Sorry, I should clarify. I was more referring to the fact that the user_zone parameter is not passed to the server directly. If provided, it is grafted to the user_name, but not sent as a separate parameter to the GeneralAdmin API.
Anyway, this conversation was originally about adding some pathological tests around this feature. Perhaps we should open a separate issue for that for later if things are working as intended now. Then, we can address that at another time and get this in for the next release.
No description provided.