• 0
Guest David Miles

Disabling Users.

Question

Hello POS Lavu Community, 

 

I wanted to post about the importance of disabling usernames who are no longer employed with your establishment. Once an employee has been terminated, or is seeking different opportunities, please take the necessary steps to ensure they will not have access to the account's backend or frontend. 

 

*****Disabling users is recommended as a security measure for our clients, and should be done immediately after the employee parts ways*****

 

This is done in the account's backend settings, under the {Edit Users} tab. Please click on the {Active} box to disable the employee, which is located on the user's information page. 

 

post-54-0-39004900-1360964693_thumb.png

 

If an employee is not deleted out of the POS Lavu or LavuLite account, then they could potentially log into the backend and the frontend, and - if they are disgruntled - tamper with the establishment's settings. 

 

David Miles 
Lavu 

0

Share this post


Link to post
Share on other sites

17 answers to this question

  • 0

How about deleting them at all?

I have a question that is somehow related to that.

How do you change the backend log in info in case I trust someone with that and I fire them. They could log in from home and ruin my whole backend?

0

Share this post


Link to post
Share on other sites
  • 0

Deleting a user would also prevent them from logging in. Disabling is useful when an employee could be coming back - I worked with a coffee shop client that had one person added as 3 different users, since they were a college student that would come back and work for them between semesters, seasonally, and when they needed extra money. Disabling that user would have been better than deleting them and then adding them back, since they'll now show up as 3 people in the time card area - every user since starting will show up there, since you can go back in your date range to when they were working there.

 

As for changing the backend log in info, each user that logs in to the backend should have different login info. This is better since when someone is fired, you can disable or remove their login info before you tell them they've been let go. Second, if there is ever any kind of sabotage, the login and IP address used can be retrieved by Lavu, in the case that you don't know who did it.

 

If you are just using one login for everyone, just change the password on that username in the admin control panel, and it's different instantly. The next user will have to log in using the different password.

0

Share this post


Link to post
Share on other sites
  • 0

How about deleting them at all? 

I have a question that is somehow related to that. 

How do you change the backend log in info in case I trust someone with that and I fire them. They could log in from home and ruin my whole backend?

 

Hi WhenInRome, 

 

I don't recommend completely deleting a user, unless the are not trustworthy. It the user stole from your establishment, or did something that wasn't integrity minded, then you may want to disable them; deleting a user would completely wipe them from your system. But if they were model employees, put in a two week notice, and you would welcome them back, then I would say just disable them. That way they could be reenabled. 

 

Another good reason to disable someone - as opposed to deleting them - is if they are taking a leave of absence. 

 

If they are disabled, all of their login credentials would be the same but they wouldn't be able to access the backend or the frontend. Definitely disable them though, because you wouldn't want them coming for lunch and adjusting their ticket with their personal iPhones. 

 

David Miles 

Lavu 

0

Share this post


Link to post
Share on other sites
  • 0

Be careful when you delete users. you will lose the "Pin" code that is linked to that account and can't use the same pin code with new & existing user accounts.

0

Share this post


Link to post
Share on other sites
  • 0

I noticed that you cant reuse the pin anymore. Is that a bug that is going to be fixed or is going to stay that way? I liked the small pin number double digit 33,44,55... I can no longer use them. I think the smart thing would have been to just change the name to keep the same pin.

About them coming over to adjust their own tickets its not possible because I change the admin all the time and the servers pin is only to put orders in.

0

Share this post


Link to post
Share on other sites
  • 0

Hi whenInRome,

I'm not sure if this is a bug or if this was intentional. Let me ask around, and see if this is intentional and if there is some reasoning behind this. I'll post what I find out,

David Miles

Lavu

0

Share this post


Link to post
Share on other sites
  • 0

WhenInRome,

I did get an answer on this. This is the intended function. That PIN number has been flagged as deleted on our end, but it is still tied to a lot of orders, clock ins, just information that is recorded. There are times when we would still need to reference old orders, even if the user is deleted. Taking everything out would complicate things.

But there is an infinite amount of pin combos, so this shouldn't be a deal breaker. Maybe we can re enable those two digit numbers for your account? I bet if you emailed support, they would be able to talk with dev for you.

David Miles

Lavu

0

Share this post


Link to post
Share on other sites
  • 0

I am a software programmer...I NEVER allow my software to actually delete data that might be important one day (which is most data). So instead, I design my software to use the word "trash" instead of "delete". I tell them it's "gone forever", but really what I do is have a BOOLEAN field in the database that sets to 1. I use this to prevent them from showing up on anything new or logging in, or showing up on current list of employees etc...

 

But then a "past employee" list can be generated (because the data is still there), as well as all the activity log entries. From a human resource standpoint and when Lavu grows to the point where there will be a full Human Resources Department, they will want to have access to this data for at least 12 month's. What if you find out shortly after firing them that they were involved in a crime ring and you are being asked to look at your books to make sure they didn't steal from you. If you delete all evidence in the system, you can't find that out later. So by "trashing" the person they appear to be gone from all active stuff, but their information is still within reach if needed later...but it's out of sight -- out of mind until then. 

0

Share this post


Link to post
Share on other sites
  • 0

*NOTE

 

I am not a software programmer for POS Lavu. I manage a POS Lavu system for a local company. Just to be clear, I have no control over POS Lavu, I just provide feedback and ideas to help improve it :)

0

Share this post


Link to post
Share on other sites
  • 0

I am a software programmer...I NEVER allow my software to actually delete data that might be important one day (which is most data). So instead, I design my software to use the word "trash" instead of "delete". I tell them it's "gone forever", but really what I do is have a BOOLEAN field in the database that sets to 1. I use this to prevent them from showing up on anything new or logging in, or showing up on current list of employees etc...

 

This is a legit point. We will want to keep all data available, in case that info needs to be accessed later. 

 

David Miles

Lavu

0

Share this post


Link to post
Share on other sites
  • 0

David,

 

I should point out that when using this method, you have to be clever when it comes to someone wanting to add an employee back later. For example, I often use email addresses as usernames and it's set to a distinct value in the database. So if I simply "trash" someone, I can't leave their email and/or username in there, because what if they get hired back in the future or someone wants to use that username? So I generally move that information to an extra "note" field in the record when doing a "trash" action, and then I generate a uniqid() from PHP to create a unique random string and I plop it in the database. That way the username and/or email is free to be used in the future if needed, but the record can still stay "trashed". (as far as the customers are concerned, the information is literally deleted and gone forever). This also helps to insure that I can simply use USER_ID as a field when logging information since I know that the USER will ALWAYS be in the table even when something is "trashed". 

0

Share this post


Link to post
Share on other sites
  • 0

This is a good point as well, and one that I believe development has considered. In the "old" new backend, there was a way to restore deleted users to recover their information later, and we may again see that functionality with future control panel updates.

0

Share this post


Link to post
Share on other sites
  • 0

I noticed that even though a user has been marked as inactive their name still appears in the transfer tabs section. Shouldn't they be invisible to everything except in the backend (in case of a rehire)?!

0

Share this post


Link to post
Share on other sites
  • 0

I had a customer say they had marked the employee inactive but was still able to login.

 

0

Share this post


Link to post
Share on other sites
  • 0

I noticed that even though a user has been marked as inactive their name still appears in the transfer tabs section. Shouldn't they be invisible to everything except in the backend (in case of a rehire)?!

 

I will pass this along to development.

 

I had a customer say they had marked the employee inactive but was still able to login.

 

The issue which that particular client experienced has been corrected.

0

Share this post


Link to post
Share on other sites
  • 0

We need an inactive user list versus having both active and inactive showing up in the backend screen.  Has this been requested or is it already possible?

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now