Waarning - security risk.

[nattivillin]

Re: Waarning - security risk.

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]

Re: Waarning - security risk.

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]

Re: Waarning - security risk.

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]

Re: Waarning - security risk.

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]

Re: Waarning - security risk.

Also, where does it specifically say, Log Off?

[danoli]

Re: Waarning - security risk.

'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]

Re: Waarning - security risk.

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 :)