Issue Number | 3533 |
---|---|
Summary | Unable to inactivate user |
Created | 2012-07-26 11:35:19 |
Issue Type | Improvement |
Submitted By | Osei-Poku, William (NIH/NCI) [C] |
Assigned To | alan |
Status | Closed |
Resolved | 2013-07-17 06:23:30 |
Resolution | Fixed |
Path | /home/bkline/backups/jira/ocecdr/issue.107861 |
BZISSUE::5228
BZDATETIME::2012-07-26 11:35:19
BZCREATOR::William Osei-Poku
BZASSIGNEE::Alan Meyer
BZQACONTACT::William Osei-Poku
The "Inactivate User" function/button on the Manage Users interface does not work. The page just refreshes after clicking on the button and nothing happens afterwards.
BZDATETIME::2012-07-26 18:14:29
BZCOMMENTOR::Alan Meyer
BZCOMMENT::1
Lifting the lid on this issue and gazing into the pit I see a nest of curious looking bugs crawling around.
In the Edit User Information screen we have a button for "Inactivate User", but there is no code behind it.
There is code for "Delete User" but there is no button for that.
In the database, we have a column for "expired", it's a date field, but there is no column for "active status".
The "Delete User" functionality in the Admin system, the one that has no button, is clearly intended as a deletion rather than an inactivation because it checks to see if there are any actions attributable to this user and, if so, refuses to delete him.
Meanwhile, back in the server, I see that the logon code does not look at the "expired" column. It only looks at the user name and password. If the user name and password are good, even an expired user can logon. I haven't checked all possible places, but there may be other places that should also check the expired column and do not.
Looking in the database, I find that there are 206 users for whom the expired column has been set. The latest one on Mahler was Merrily Tovmassian, expired on July 9 of this year. Before that there was Sarah Robinson, expired on both Mahler and Bach on February 16, 2011. I haven't yet found the software that was used to expire the users. However I have verified that I can still logon as Sarah Robinson if I enter her userid and password.
The one bright spot (or perhaps not quite as dim spot) I've found so far is that William's deleting the password worked. I found the user tcunningham had her password deleted. I tried to logon by entering a userid with no password and the system would not allow it. I don't think this was by design. It appears to have just worked out that way due to an artifact of what happens when nothing is entered in a field in a web form.
So, the first thing I'd love to know is how Merilly, Sara, and the 204 other users with "expired" dates got that way. Is there some way to delete a user other than the Edit User Information screen? I haven't found it yet. No Delete User transaction was recorded in the command log at the time of the deletion, so it appears that someone (not I said the baby bear) edits the database by hand.
Volker expressed an interest in taking over this bug. Won't he be thrilled if I re-assign it to him?
BZDATETIME::2012-07-26 18:21:48
BZCOMMENTOR::Alan Meyer
BZCOMMENT::2
Update:
A command was executed to delete Merilly Tovmassian. I didn't find it before because I spelled her name wrong. But I'm still not sure where the command came from.
However, I'm still able to login as mtovmassian. The delete command populates the "expired" field but doesn't prevent a login.
BZDATETIME::2012-08-02 10:22:43
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::3
In the Manage Actions Menu item (#3 under Developers/System Administrators), there is an Action for Delete User but none for Inactivate User and I do remember that there was a Delete User button in the Edit User Information screen. I used that to completely remove a user from the screen. It seems to me that is what has been replaced by the Inactivate User button.
BZDATETIME::2013-04-02 15:13:40
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::4
I was able to inactivate users on Mahler as expected. Though not related to this issue, I also used the new interface to change my password successfully.
BZDATETIME::2013-04-08 18:41:18
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::5
I see 3 Global Changes on the CDR Menu and the one we have been using
and will continue to use is the "Global Change Links". I don't see any
reason why we need to use the other two Global Changes (below) since
they are used on participating sites, Investigators and addresses
primarily in InScopeProtocol(s) and we no long update
InScopeProtocol(s).
1. Global Change Protocol Links
2. Global Change Zip Codes
I am not sure if this is the right issue to update with this information but I wanted to respond to questions about Global Changes in our last meeting**
BZDATETIME::2013-04-08 19:49:13
BZCOMMENTOR::Alan Meyer
BZCOMMENT::6
(In reply to comment #5)
> I see 3 Global Changes on the CDR Menu and the one we have been
using and will
> continue to use is the "Global Change Links". I don't see any
reason why we
> need to use the other two Global Changes (below) since they are
used on
> participating sites, Investigators and addresses primarily in
> InScopeProtocol(s) and we no long update InScopeProtocol(s).
> 1. Global Change Protocol Links
> 2. Global Change Zip Codes
>
> ** I am not sure if this is the right issue to update with this
information but
> I wanted to respond to questions about Global Changes in our last
meeting**
I'm not sure where the info should go so I'll also respond in the context of this issue.
Should we retire 1 and 2 above and remove them from the menus?
BZDATETIME::2013-04-09 12:02:54
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::7
(In reply to comment #6)
> I'm not sure where the info should go so I'll also respond in
the context of
> this issue.
>
> Should we retire 1 and 2 above and remove them from the menus?
Unless you have a reason to retire them immediately, there is another issue - OCECDR-3543 which is tracking all the menu changes. I will include these two in the issue.
BZDATETIME::2013-04-10 18:06:07
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::8
I started testing the new password management feature but I had to stop because it allowed me to create any combination of letters as the new password. For example, it accepts "js" as the password and it will also accept 8 character long passwords. I am just wondering if you turned the requirements off?
BZDATETIME::2013-04-11 11:56:18
BZCOMMENTOR::Alan Meyer
BZCOMMENT::9
(In reply to comment #8)
> I started testing the new password management feature but I had to
stop because
> it allowed me to create any combination of letters as the new
password. For
> example, it accepts "js" as the password and it will also accept 8
character
> long passwords. I am just wondering if you turned the requirements
off?
Yes, that's what happened.
I was testing with an experimental version of the server but Volker restarted the last, default version of the server when you noticed that Mahler wasn't accepting requests.
I'm going to do some more changes, then I'll make the modified version of the server the default instead of the old one. I'll try to do that before I leave tonight.
BZDATETIME::2013-04-12 01:01:15
BZCOMMENTOR::Alan Meyer
BZCOMMENT::10
(In reply to comment #9)
> ...
> I'm going to do some more changes, then I'll make the modified
version of the
> server the default instead of the old one. I'll try to do that
before I leave
> tonight.
Done.
BZDATETIME::2013-05-01 17:29:39
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::11
I did a few more tests and everything seems to work fine except that it allowed me to recycle previous passwords.
BZDATETIME::2013-05-01 17:47:58
BZCOMMENTOR::Alan Meyer
BZCOMMENT::12
(In reply to comment #11)
> I did a few more tests and everything seems to work fine except
that it allowed
> me to recycle previous passwords.
Yes, I'm not saving the old ones for checking.
Ultimately, we'll probably switch to a system that uses the NIH userid and password, so I didn't put more into this than was required by CBIIT.
This is in production. William will test and close the issue if it works correctly.
Works in Production.
Elapsed: 0:00:00.001380