ticket lock and responsible feature questions
Hello, I've got two questions 1) I disabled ticket locking for all agents' actions. Is this somewhat dangerous, enabling two agents working together on the same ticket? What could happen if two agents edit the same ticket at the same time? 2) What is the responsible feature, what's its purpose and how it works? Thanks in advance -- Gabriele D'Andrea
Gabriele D'Andrea wrote:
1) I disabled ticket locking for all agents' actions.
I didn't know you could. Why did you?
Is this somewhat dangerous, enabling two agents working together on the same ticket?
I guess so. Define dangerous.
What could happen if two agents edit the same ticket at the same time?
A customer could receive two separate responses from two agents that both didn't know the other was handling the ticket, for instance. That's already enough for us to see the use of ticket locking. It's also handy to see who is working on an issue and whether someone is working on an issue.
2) What is the responsible feature, what's its purpose and how it works?
The person responsible for handling a ticket is not necessarily always the person working on (locking) a ticket. It's just a way to track who's responsible for what. Nils Breunese.
Gabriele D'Andrea wrote:
1) I disabled ticket locking for all agents' actions.
-- I didn't know you could. Why did you? I mean I set the parameter RequiredLock to No for every agent action, just like this: Ticket::Frontend::AgentTicketCompose###RequiredLock: A ticket lock is required. In case the ticket isn't locked, the tickets get locked and the current agent will be set automatically as ticket owner. No (Default: Yes) I did it 'cause often agents need to perform some actions on the tickets, without automatically bacome the owner, and tickets should remain in queue.
What could happen if two agents edit the same ticket at the same time?
-- A customer could receive two separate responses from two agents that --- both didn't know the other was handling the ticket, for instance. --That's already enough for us to see the use of ticket locking. It's --also handy to see who is working on an issue and whether someone is --working on an issue. If that's the danger , is affordable to us, cause in our environment is not likely to happen that two agents perform actions on tickets at the same time. The only thing important is not to have some kind of disalignment in OTRS and its DB
2) What is the responsible feature, what's its purpose and how it works?
-- The person responsible for handling a ticket is not necessarily
-- always the person working on (locking) a ticket. It's just a way to
-- track who's responsible for what.
OK, so it's just a label, some kind of reminder, which doesn't affect OTRS
normal behaviour?
Gabriele
----- Original Message -----
From: "Nils Breunese (Lemonbit)"
_______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/
Gabriele D'Andrea wrote:
What could happen if two agents edit the same ticket at the same time?
-- A customer could receive two separate responses from two agents that --- both didn't know the other was handling the ticket, for instance. --That's already enough for us to see the use of ticket locking. It's --also handy to see who is working on an issue and whether someone is --working on an issue.
If that's the danger , is affordable to us, cause in our environment is not likely to happen that two agents perform actions on tickets at the same time. The only thing important is not to have some kind of disalignment in OTRS and its DB
I'm sure that if these settings could corrupt the database they wouldn't have been implemented.
What is the responsible feature, what's its purpose and how it works?
-- The person responsible for handling a ticket is not necessarily -- always the person working on (locking) a ticket. It's just a way to -- track who's responsible for what.
OK, so it's just a label, some kind of reminder, which doesn't affect OTRS normal behaviour?
I believe so. I have not tried this feature actually. Nils Breunese.
I'm sure that if these settings could corrupt the database they wouldn't have been implemented.
That's what I thought, too! :)
Thanks for your replies
--
Gabriele D'Andrea
----- Original Message -----
From: "Nils Breunese (Lemonbit)"
_______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/
participants (2)
-
Gabriele D'Andrea -
Nils Breunese (Lemonbit)