Deleting users

[dprice-p40]

We have had a change of clerks, and need to delete the old clerk (who has moved on to another calling). How do we do that? I don't see any way to delete a user in MLS. In fact, as we were trying to figure it out, we found users still listed that have long ago moved out of our branch. There must be a way to only have current users showing, but we couldn't find it. (The only option we could find was to remove their priviledges to see data -- but why can't we just delete them totally?) Ideas?
Dave Price
Mt. Pleasant IA Branch

[danpass]

You are really much better off creating user names based on the position. For example:

Bishop
1st Coun
2nd Coun
Ward Clerk
VT Coordinator

and so on. Then within the settings for each user, you select the specific member who currently has the calling and let the individual type in their password of choice. When a new person gets called to that position, all you have to do is edit the settings for the user and assign the new person and have them enter their own password.

[russellhltn]

You are really much better off creating user names based on the position. For example:

Bishop
1st Coun
2nd Coun
Ward Clerk
VT Coordinator

That is contrary to the instructions. The financial data of who did what needs to be traceable to the person, and not the position.

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. (I think that 3 years + current year) The older versions of MLS did allow you to appear to delete them, but then if that person was called back to a position that needed to use MLS, their name couldn't be added because it was already in the system (although hidden).

The newer MLS versions don't allow you to delete. Simply remove the privileges. At some future time if they need MLS access, you can give them the needed privileges back.

[danpass]

That is contrary to the instructions.

, I've never heard this before. I checked the MLS built-in help section for adding users. In an example user name they do use the person's name rather than their position. Are these the instructions your are referring to? If not, please point me to where I can see this.

The financial data of who did what needs to be traceable to the person, and not the position.

I would hope that MLS is logging both the user name as well as the associated member's name when it records transactions. Assuming this is so, the advantage of using the member's position for the user name is that should a need arise to find out who did something in MLS, one would be able to see the member's name as well as in what capacity they were serving at the time.

I was the stake computer clerk at the time that MLS was first released. I set up the new computers and trained all the ward and stake clerks to always use the member's position for user name. No one from HQ has ever indicated to us that we needed to change. So your comment really came as a surprise to me.

I would hate to have to change this now, but if instructed to I will...

[russellhltn]

Well darn. Try as I might, all I can come up with is "Each member using MLS must sign on to the system using his or her own user ID and password." and "As members receive new callings or are released from callings, their access to MLS should be changed to reflect current assignments." The examples given, including the training shows names.

That certainly suggests to me that the UserID should be tied with the person and not the position, but I'm sure it can be argued the other way too.

To me the bigger issue is to identify "whom". If for example, a question has comes up on a donation batch from some time ago. I'd think it would be more important to identify the persons who initialed the batch so you can start asking them questions then to see the position and try to figure out who had that calling at that time. If the person was able to initial the batch, then (assuming the MLS rights reflect their calling), then they are authorized to do it. When you're trying to track down problem, the person is more important then the calling held at the time.

I also think it's easier to track things when the IDs reflect the person. You can be reasonably sure that Brother Brown is using "Jim Brown", but if he was the Ward Clerk and is now the EQ President, can you be sure he's logging in with the right ID (and therefor the correct privileges)?

[jkarras-p40]

In my ward the previous clerk set people up with last name only. I kept this convention. A few weeks ago the 1st counselor in the bishopric asked if I would change his user name from last only to first and last. He said he wanted this because of the way it prints out on some of the finance documents.

I am not up on all of those documents because I don't usually help with finances though.

[Eric Werny-p40]

This makes a lot of sense.

In my ward the previous clerk set people up with last name only. I kept this convention. A few weeks ago the 1st counselor in the bishopric asked if I would change his user name from last only to first and last. He said he wanted this because of the way it prints out on some of the finance documents.

I am not up on all of those documents because I don't usually help with finances though.

[mkmurray]

If for example, a question has comes up on a donation batch from some time ago. I'd think it would be more important to identify the persons who initialed the batch so you can start asking them questions then to see the position and try to figure out who had that calling at that time. If the person was able to initial the batch, then (assuming the MLS rights reflect their calling), then they are authorized to do it. When you're trying to track down problem, the person is more important then the calling held at the time.

Danpass did mention he was going off a hopeful assumption that user name and real member name were being tied to such finiancial transactions. I'm not sure if it is a safe assumption though. We might have to hear from an MLS team member or anyone else that would know how to verify this.

I also think it's easier to track things when the IDs reflect the person. You can be reasonably sure that Brother Brown is using "Jim Brown", but if he was the Ward Clerk and is now the EQ President, can you be sure he's logging in with the right ID (and therefor the correct privileges)?

I think this is a good point. There could be circumstances that go overlooked and cause privileges to still be granted to someone who shouldn't have them, etc.

[russellhltn]

Danpass did mention he was going off a hopeful assumption that user name and real member name were being tied to such financial transactions.

I think what he's referring to is there is the ability in MLS to connect one's UserID to one's membership record. Now just what that does I have no idea since as far as I can tell (or have heard) it doesn't do anything. But then that's something else that could easily go wrong. If the UserID "Financial Clerk" is passed off to a new person, will they re-link that ID to the new membership record? It would be easy to overlook, and then things are attributed to the wrong person.

[danpass]

Danpass did mention he was going off a hopeful assumption that user name and real member name were being tied to such financial transactions.

I think what he's referring to is there is the ability in MLS to connect one's UserID to one's membership record.

Yes and yes. MLS does have the ability to connect the userid and membership record. Hopefully, MLS does record both the userid and the name of the member that is assigned to the userid.

If the UserID "Financial Clerk" is passed off to a new person, will they re-link that ID to the new membership record? It would be easy to overlook, and then things are attributed to the wrong person.

Of course you link the userid to the new member. It is actually pretty difficult to overlook. When you go into the user properties to have the new user type in their password...



it is fairly obvious that a new member record needs to be assigned if the person sitting there with you is not the person showing in the member field.

In the event that the old financial clerk decides to just give his password to the new financial clerk (We instruct users to never share their password with another person), one of two things would happen. The new user could choose to reset the password...



at which time it should be abundantly clear the correct member name is not showing and hopefully cause him to ask an administrator to fix it. In the event that this does not happen or if the new finance clerk does not choose to change the password, then it would be up to an administrator to discover the situation. An incorrectly assigned userid is very easy to spot...



when viewing the Users section of the System Options. When you click on the userid to fix the problem you get this window



Which lets you correctly assign the member record and also clears out the password fields and requires you to enter a new password.

The reasons I like using this userid naming convention are:

1. Simple to maintain. Once you create a userid, the rights for that userid are not very likely to need changing
2. We don't need to worry about forgetting to remove someone's access or changing their rights when their calling changes
3. The Users System Options page does not get cluttered with names of people who no longer need to be there

Note: The member names that show in the screen shots above are not real names. They are names that are in the sample MLS database.