Waarning - security risk.

[danoli]

I have reported this to CommitCRM Support, they are not willing to fix it.

If you make changes to an account or ticket (or any other part of commit) that requires you to click the save button, be careful you do not lock your session. Unless you are around with your password, NO ONE ELSE can login to CommitCRM on this station to save the unsaved data.

We lost multiple crucial changes due to this that are unrecoverable.

Also, if you click Log on as different user, the session is NOT logged off until another user is logged in. So if you want to logout and leave the session for a different engineer to use, all that engineer has to do is Cancel the operation and they go back to the previous session.

I have requested an update to do the following:

1 - Prompt to save changes BEFORE the session will lock
2 - Add the ability to LOG OFF
3 - Make login as different user logout the current session as soon as it is selected.

While it may not affect you, it is a security risk as well as a potential to lose data.

Not sure why support refuse to address this, they confirmed the logic and potential risk.

[Support Team]

danoli - there's no magic bullet here and as we discussed with you by email here's what we think of this:

This does not work much differently than Windows -

Have unsaved updates in other Windows applications (nothing to do with RangerMSP), lock Windows and if the technician goes home you will need to know their password, if you shut the PC down - unsaved updates in any application are lost. etc.

As with Windows what you may do is:

Ask technicians to save before they lock the RangerMSP session.

Ask them not to use the lock feature if they might go home.

Ask them for their password so you can unlock into their locked session.


We have already logged your feedback here, however and as mentioned in our emails to you, this request is not popular and thus we will be working on other things as we think that RangerMSP does differ much in this area than other products and thus we will probably spend our time and resources on other, most popular, feature requests.

Should this become popular and something that many of our users wants us to work on I can assure you that this is exactly what we will be working on.

Thanks.

[danoli]

A minor code change (I would guess) to ensure a known issue that WILL lose data is resolved, is not too much to ask.

As I explained to you, we lost significant data due to this and it worries me that this could happen again.

While you are comparing to windows, I agree, the lock computer feature is similar, but windows does have the log our option which does prompt to save data. Windows is also the operating system, not the application which makes it a little different.

You say the request is not popular, I agree, it may not have happened to many, but I guarantee that if it happens to you (or anyone eles reading this) you will wish the problem was resolved.

Is it really that difficult to fix?

[Support Team]

Personally I don't know what it takes to implement such a feature improvement.

If it'll become a popular require it'll be implemented before other feature requests.

If it won't I guess that other feature requests will be handled first.

I hope this all makes sense and it doesn't mean that we don't understand what you're saying. We actually do understand and really appreciate your feedback here.

[danoli]

I posted this publicly to hopefully make others aware of a glitch that has cased me a loss...

We lost the contact number of a new business, a business that is expecting our call and I have no way of contacting them.
A silly mistake, yes, avoidable, YES?

Is this a feature request, I would say more a security risk.

[nattivillin]

So hitting logout doesn't log you out? You have to actually log in as someone else in order to log the first person out totally?

[danoli]

Yes, it is NOT possible to just logout.
If you click login as different user, it may look like you are logged out, just click ESC and you are back in as the last engineer...

I cannot understand why a security risk has to be 'popular' before they will fix it?

[nattivillin]

I agree, You would think that log out would mean you are actually logged off.

[DynamicIT]

Hi Team,

If I am called away from my computer by a client and it is in a potentially publicly accessible location, I'll hit WINKEY+L. If someone else jumps on it and forces my session to log off for any reason, the data loss is due to human error, not the software I am using.

Would I want every application (or even one application) to force me to answer a question about saving data when I an trying to walk away in a hurry? No, as this defeats the purpose.

Would it be great if my software helped me prevent data loss through human error? ABSOLUTELY YES.

I think Microsoft Word 2010 allows you to recover (for a short time) a document you closed and accidentally clicked NO to saving changes. Word has been around for 25 years and this feature is new. Hopefully CommitCRM can save us from our silly mistakes before they reach 25 years old :)

Danoli I feel your pain, as does everyone who loses for example some important information when Word crashes. You are reminded about the importance of hitting the SAVE button regularly, and get on with life after a little grumbling.

As best I can see, the Lock Session and Log On As Different User menu items do exactly as they say they do. There is no Log Off (on my CommitCRM 5.7). Personally, I've never used either and never seen my team use them.

[DynamicIT]

Having to log in as someone else to log off the last user is a little odd, though I have seen it with other software too (cannot remember any names).

CommitCRM - Change Request - Change the "Log On as Different User" option to "Log Off (Change User)" or similar and have the application log off the existing user (prompting for saves) before presenting the login box for the new user. This is more intuitive.

Cheers,
Mike

[Support Team]

Thanks Mike.

[danoli]

The point raised is that CommitCRM is sold as a multi-user application with hierarchical permissions.
If I was logged in with elevated permissions on an engineers machine to 'override' something he did not have permission to do, then I as the manager should be able to force a logout.

Until recently, it was assumed that 'log in as different user' did as most other apps do in this situation, log out current user in anticipation for the new user, basically, you can hit ESC and get higher privileges if the previous user was an admin.

Yes, I know you can close CommitCRM and reload but this adds time. I wouldn't want to reboot windows every time I changed user.

Mike, I understand your point, but for an application to allow a user to lock a session without any means to override is a huge risk. There is a multitude of reasons why the user may not return or be unable to log back in, leaving the system vulnerable.

[racassel]

It is a high security risk to think clicking log on as different user has logged you out. CommitCRM should address this, or remove the logon as a different user, dim the screeen, anything but a fake login screen that doesn't execute the logoff routine.

[danoli]

Hear Hear... Falling on deaf ears I am afraid. (unless you want to 'suggest' it as a fix and have other 'vote' if it should be implemented, ridiculous!) Such a simple fix!

What about a locked session keeps unsaved data behind an unrecoverable login prompt?

What about an engineer can be logged in as 'himself/herself, leaving a comment in a resolution and 'choose' which engineer wrote it.

CommitCRM is Great... But...

[hayden]

I think you need to re-train your techies. We have never had this issue has everyone here saves there data, always.

While I do see CommitCRM needs to fix the login issue, I think your staff are at fault here too.

You should know this from the Word days where you'd lose an entire document.

[nattivillin]

They can retrain, i'm sure they will. In the end, a log out should be a log out. Another other than that is just a failure of the program.

[danoli]

lol, Hayden, do not worry, I have booked all of our engineers on a 2 day course on how to double check that when the system says 'logout', it actually does what it implies. It is an in-depth course, but I am sure our 'techies' will be able to grasp the concept.....

Not sure why my staff are/were at fault, they assumed a program logged out when it implied it would. Should they double check EVERYTHING it implies? Update a charge (then double check it did it), update a history note (then double check it did it), Update an asset (then double check it did it)... need I go on?

Not sure why you try to justify a 'buggy' program based on a ancient Microsoft failing...

On a serious note, we have done the 're-train' in house. We have informed all engineers that the software does NOT log them out when it implies it will. They now either just stay logged in or close CommitCRM after every update, great...!

[danoli]

Another flaw...
Try this, go to ANY account, edit it, (I edited the customer address field), do NOT save, now, lock you session. It is a eralistc scenario, probably not common but highly possible.

Try to edit that account from ANY other machine as ANY other user. You can't.
You also have no idea who/where the account is locked. If the person who locked the session does NOT unlock the session, they you are SCREWED. The data they added is lost and you cannot access the record from the other machine (until you trash he locked session)

Guess what, CommitCRM Support do not see this as a bug...

[hayden]

Then save your stuff... jez, how hard is it?

I understand CommitCRM is to blame here a little bit, but so are your technicians and your process and procedures.

Here's an idea: Instead if your two day course on how to log out, how about you spend 10 minutes with your techies telling them to save data when they are finished with a customer.

I only have 3 techies and we all do this. I've never had the issue you describe. It's very easily avoidable.

[hayden]

Also, where does it specifically say, Log Off?

[danoli]

'Imply' is the key word here. If you click File - Log on as a different user, it takes you to the same login box as you would initially login, giving the assumption you are now logged out, when in fact, you are still in as the previous user who may have elevated privileges.

I cannot understand...

As a 'techie' I would have thought you would have an eye for 'poor programming'. I have been a coder for best part of 25 years and see this a a very bad design that is 'asking for trouble' and easily fixed with no disruption to those that it does not affect.

Why not simply call a 'logout procedure' in the code.

Forget courses and retraining etc etc, the whole point of decent decent software and feedback is that the programmer identifies potential problems before they affect users and tries to address them rather than argue the fact that you should train staff to a work around.

The fact is, the login / logout / lock session is poorly written, it has been identified by CommitCRM support as a potential problem, numerous other post also agree, so what is YOUR argument? Your techines may not see a problem, you probably do not use CommitCRM like we do, in fact, I guarantee you wont use it like us so while it may not cause you grief, it does us and other.

[danoli]

QUOTE BY HAYDEN
"Then save your stuff... jez, how hard is it?"

Let me guess, you have never accidentally lost work and wished the program had auto save or disallowed you from making simple mistake when you are knee deep in techie problems? Yes, It is easy to save, it really is, I know, but it is also really easy to fix from a code point of view and as a 'techie' I would rather have a rock solid CRM with minimal points of failure to allow me to do my work rather than worry about its pitfalls.

QUOTE BY HAYDEN
"Here's an idea: Instead if your two day course on how to log out, how about you spend 10 minutes with your techies telling them to save data when they are finished with a customer."

We have up to 10 engineers/staff working in a mad busy workshop, with upward of 20 jobs (tickets) open at any one time, 4 shared 'commit' machines in the workshop, 6 remote and 3 in different offices, engineers adding notes to different tickets via different machines, maybe 30-60 updates+ per hour. CommitCRM logs our workshop repairs (around 40 jobs per day) engineer callouts (10+ per day) telecom support calls (up to 50 a day 'maybe'), webdesign tracking (3 projects per day), business support contracts, as well as all asset tracking, charges blah blah blah. The last thing I want to worry about is AVOIDABLE problems.



QUOTE BY HAYDEN
"I only have 3 techies and we all do this. I've never had the issue you describe. It's very easily avoidable."

Oh, then I rest my case.


FYI
Remember, CommitCRM is not only used how YOU use it, we all use it differently and have varying levels or requirements so maybe when your business grows, this 'bug' may just bite you on your butt and you may wish it was resolved sooner :)