To be complete: another behavior of RequiredLock is that, if it's set to 'Yes', you can't perform this action on the ticket if it's locked to someone else. So if you would set RequiredLock to 'Yes' for AgentTicketOwner, you will not be able to change the owner of a ticket if it's locked to another user. -- Michiel
On Mon, Jan 4, 2010 at 8:02 PM, Michiel Beijen <mich...@beefreeit.nl> wrote: > Hi Philippe, > > Sorry for not responding earlier. Actually, the mailing list is not > what we use for software bug tracking - we use http://bugs.otrs.org > for that. You can create an account there and log a bug report. But > then still, we will not commit to solve your issues. The "scratch your > own itch" principle applies here. This basically means that while some > bugs will be valid bugs, we only have limited time resources and may > or may not fix your bug as soon as you might hope - just because the > bug might be specifically annoying for you but other people would get > along without it just fine. > > So, if you'd want to make sure your issues get fixed, please get a > support contract and/or contact en...@otrs.com to see what we can do > comercially for you. > > Now back to your issues. >> When we change the owner of a ticket, the ticket is always locked Even if >> you put No in that parameter: >> Ticket::Frontend::AgentTicketOwner###RequiredLock è to be corrected > > This is a misconception. The RequiredLock config option is for > something else. If you would set the same option in AgentTicketNote to > 'Yes', it would mean that if you leave a note on a ticket the ticket > will get locked to you if it's not already locked. Note that it will > lock the ticket BEFORE leaving the actual note. . If you set it to > 'No', the ticket will remain unlocked if you just leave a note. > > In the case of AgentTicketOwner, the option is a little bit useless > because at the end of the transaction it will lock the ticket anyway > to the owner to which you are assigning to, but that's a different > issue. > > The idea of a lock is that you assign the ticket to somebody who is > then going to be responsible for it. You should not assign a ticket to > somebody if you have not discussed with him first; because if he's not > there the ticket might escalate. Otherwise you should probably be > using Move instead. Move to a queue would cause the ticket to be > unlocked, because no specific user is assigned to it. > I hope you can see the reasoning behind this. > >> Bug 2: bulk action >> >> Locks all the tickets > > This is also 'as designed' - the idea is that bulk action should be > close to what a 'normal' action would do. Some actions will lock > tickets, bulk actions do the same. There's another issue with it; it > will change the owner to the current user if its unlocked. See also > http://bugs.otrs.org/show_bug.cgi?id=4629 > > This can be cumbersome though, especially in some scenarios if you > just want to make bulk updates to tickets when you're changing your > queue structure, or when you're doing other such administrative tasks. > This is why we might be looking into redesigning this feature in > future releases. > > If you and/or your company are interested in sponsoring this > development and work with us to redesign it in a way that it will work > easier, better and faster, please drop me a line. > > Kindest regards, > -- > Michiel Beijen > R&D > > OTRS AG > Norsk-Data-Str 1. > 61352 Bad Homburg > Germany > > T: +31 (0) 6457 42418 > F: +49 (0) 9421 56818-18 > I: http://www.otrs.com/ > > Business location: Bad Homburg, Country Court: Bad Homburg, HRB 10751, > VAT ID: DE256610065 > Chairman: Burchard Steinbild, Managing Board: André Mindermann > > CU@ CeBIT 2010 in Hannover (Germany) and get to know more about OTRS > at booth no. C37, in hall 2 from March 2-6, 2010! http://bit.ly/4qLvqm > > > > > On Tue, Dec 29, 2009 at 3:50 PM, Martignier, Philippe > <philippe.martign...@wipo.int> wrote: >> Hi there, >> >> >> >> I upgrade to the last version 2.4.5 but the bugs for the lock are still >> there: >> >> >> >> Bug 1 : owner >> >> When we change the owner of a ticket, the ticket is always locked >> >> Even if you put No in that parameter: >> Ticket::Frontend::AgentTicketOwner###RequiredLock è to be corrected >> >> >> >> Bug 2: bulk action >> >> Locks all the tickets and no requiredlock for that è to be implemented >> >> >> >> I would like to have some input from OTRS about these two points as it is >> not the first time I post about these two points. (Ok lets pass this holiday >> period J >> >> >> >> See you next year ! >> >> >> >> Philippe Martignier >> >> Communications Division >> >> Customer Service Section >> >> Email : philippe.martign...@wipo.int >> >> Phone : 00 41 022 338 72 36 >> >> Building : GB II >> >> Office : 0,3 >> >> >> >> World Intellectual Property Organization Disclaimer: >> >> This electronic message may contain privileged, confidential and >> copyright protected information. If you have received this e-mail >> by mistake, please immediately notify the sender and delete this >> e-mail and all its attachments. Please ensure all e-mail attachments >> are scanned for viruses prior to opening or using. >> >> --------------------------------------------------------------------- >> 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 >> >> NEW! ENTERPRISE SUBSCRIPTION - Get more information NOW! >> http://www.otrs.com/en/support/enterprise-subscription/ >> > --------------------------------------------------------------------- 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 NEW! ENTERPRISE SUBSCRIPTION - Get more information NOW! http://www.otrs.com/en/support/enterprise-subscription/
