Deleting users

[russellhltn]

Hopefully, MLS does record both the userid and the name of the member that is assigned to the userid.

Looks like most of the concerns I had have been answered except for that one.

[mkmurray]

Hopefully, MLS does record both the userid and the name of the member that is assigned to the userid.

Looks like most of the concerns I had have been answered except for that one.

So the real question is which of the two identifiers is recorded in the logs as a user performs various tasks while using MLS? Can anyone from the MLS team answer this?

[dprice-p40]

...The reason for not being allowed to delete these people is that they at some point did some financial transactions and their information needs to be there until that data is purged. ...The newer MLS versions don't allow you to delete.

And yet -- in MLS 2.7 there is now the "Remove" option that I don't recall seeing before. I haven't used it yet (because I just noticed it after upgrading to 2.7 last week -- it's in the screenshot in danpass' posting on the right side of the "users" page)... Is this something new? I'll try it out tomorrow night when I'm next down to the church to see if "Remove" is does indeed remove.

Dave Price
Mt Pleasant IA

[russellhltn]

Is this something new? I'll try it out tomorrow night when I'm next down to the church to see if "Remove" is does indeed remove.

I don't remember how the old one did it, but it did have some kind of delete feature. Are you seeing "remove" on users that you couldn't delete before? If the MLS user hasn't done any financial transaction, I wouldn't expect there to be any problems in removing them.

[aebrown]

And yet -- in MLS 2.7 there is now the "Remove" option that I don't recall seeing before. I haven't used it yet (because I just noticed it after upgrading to 2.7 last week -- it's in the screenshot in danpass' posting on the right side of the "users" page)... Is this something new? I'll try it out tomorrow night when I'm next down to the church to see if "Remove" is does indeed remove.

The Remove option will either deactivate or remove a user. When you click the Remove link for a user, MLS will always prompt you to confirm the deletion of the user. If you click OK, then the user will simply be deleted if the user is not tied to any transactions. If they are tied to any transactions, then the user will simply be deactivated, but will remain in the user list and the Remove link will change to a Restore link.

That way if the user needs access to MLS at a later date, you can restore the user, set the correct rights for the new calling, and the user ID will be active again (with the same password as before).

What is new with MLS 2.7 is the Restore option. Prior to MLS 2.7, the act of Removing a user who was tied to transactions would put them in the same inactive state, but there would be no way to access the user, since they would be completely removed from the user list. However, if you ever tried to create a new user with that name, you would get an error message saying that the user already exists. There was no way to remove these phantom records prior to MLS 2.7, so it's very helpful that these inactive user records are no longer hidden.

[aebrown]

So the real question is which of the two identifiers is recorded in the logs as a user performs various tasks while using MLS? Can anyone from the MLS team answer this?

I'm not on the MLS team, but I'm certain that only the user ID is recorded as connecting a user to a transaction. Here's my reasoning:

When a donation batch is authorized, the user ID is printed below a line which the authorizer is supposed to initial. If the actual member name were guaranteed to be known, it would make much more sense to print the member's name for them to initial, but MLS doesn't do this.

Furthermore, a username doesn't have to be connected to a member at all. Such a "memberless" user can authorize donation batches, and of course such an authorization has no connection to a member. For example, I am a user with admin rights in every MLS system in our stake because I am the stake technology specialist. Of course I don't go around authorizing any donation batches for any ward, but technically I am able to do it.

Finally, a member who is tied to a user name can move out of the ward. The membership record is completely gone from MLS, but the user ID remains. You can go back to any batch that person authorized and their user ID will still be there, but it clearly is not tied to a member anymore.

As I read the "Using MLS: Ward and Branch Instructions" I find it imposible to read the instructions in any way that allows for user IDs to be tied to a calling. They can only be tied to a user. Otherwise statements like "User passwords should not be shared with others. Each user should change his or her password periodically" just don't make any sense.

Given that user IDs are not permanently connected to a member, it seems that the only policy that leaves a proper audit trail is for user IDs to be tied to individuals, not to callings.

[wadeburt]

Well this thread means I am going to have to rethink everything ! When I was the Technology Specialist, I was responsible for converting the Nashville Tennessee Stake, now the Madison Tennessee Stake, to MLS. I very distinctly remember being told to create positions and move members in and out of those positions rather than adding a member every time a calling is changed.

Looks like it is back to the drawing board for me.....

[danpass]

Well this thread means I am going to have to rethink everything ! When I was the Technology Specialist, I was responsible for converting the Nashville Tennessee Stake, now the Madison Tennessee Stake, to MLS. I very distinctly remember being told to create positions and move members in and out of those positions rather than adding a member every time a calling is changed.

Looks like it is back to the drawing board for me.....

I wouldn't switch to member name based usernames just yet.

I feel that I have made a strong case earlier in this thread for basing usernames on postitions. In my opinion, this strategy is more simple to administer and less susceptible to error.

Others have argued that this strategy could potentially undermine the integrity or value of the audit trail in logged transactions.

If in fact MLS is only logging the username and not the MRN/member (when there is a MRN linked to the username), then I think that changes should be made in MLS to record both pieces of information in its database. Along with this, usernames that are not linked with a membership record should be restricted from authorizing financial transactions.

The fact that your stake nor mine have been asked change after several years of doing it this way makes me think that this is a non-issue with the folks at HQ. If they do care, hopefully they will let us know what their preference is.

[russellhltn]

If in fact MLS is only logging the username and not the MRN/member (when there is a MRN linked to the username), then I think that changes should be made in MLS to record both pieces of information in its database.

As pointed out, both pieces of information is not always available. If I remember correctly, there has been counsel for the stake to have a login on the ward machine to be able to use as needed. Obviously the stake person is not going to have a MRN in MLS other then in the home ward.

[danpass]

As pointed out, both pieces of information is not always available. If I remember correctly, there has been counsel for the stake to have a login on the ward machine to be able to use as needed. Obviously the stake person is not going to have a MRN in MLS other then in the home ward.

This is correct. Since it is possible for a login to not be linked to a membership record, I made the recommendation that MLS be changed to allow authorization of finance transactions to be made only by users with logins linked to membership records. This would ensure that both data elements are available to store in the transaction record.