Re: [rt-users] Mandatory fields at ticket's Basic screen
Anyone?... On Wed, Sep 12, 2012 at 6:23 PM, Jack Zabolotnyi wrote: > Hi everyone. > > Here is my workflow: we have "Service" custom field applied to ticket and > it is mandatory. Only members of Engeneers group can see and change this > field. > When general user (not member of Engeneers group) creates ticket, he can't > see "Service" field and it is set to "(no value)". This is very ok for me. > But, when member of Engeneers group updates this ticket (via Basic page), > RT accepts changes even if this mandaroty field is untouched (has "(no > value)" ) > (After changing value to other than "(no value)" i can't put it bak, and > this is predictable) > > Am i doing something wrong or i miss something? > > Thanks in advance for any help. > > -- > Jack Zabolotnyi > Arces Network, LLC > > e: jzabolot...@arces.net > w: http://www.arces.net > > PGP key: 2048R/7F2AB658 2012-07-02 > PGP fingerprint: 4C7E 00A8 5210 F3D9 0509 C70E 87C8 666E 7F2A B658 > > -- Jack Zabolotnyi Arces Network, LLC e: jzabolot...@arces.net w: http://www.arces.net PGP key: 2048R/7F2AB658 2012-07-02 PGP fingerprint: 4C7E 00A8 5210 F3D9 0509 C70E 87C8 666E 7F2A B658 Final RT training for 2012 in Atlanta, GA - October 23 & 24 http://bestpractical.com/training We're hiring! http://bestpractical.com/jobs
Re: [rt-users] sendmail error (exited with code 75) - RHEL6
2012/9/17 Raphaël Berlamont > 2012/9/17 Thomas Sibley > >> I bet OTRS and RT step >> on each other's toes. > > If you add: >> >>PerlOptions +Parent >> >> to your RT virtualhost's block, does that help? >> > > Well, at least, now I don't have any OTRS references in the configuration > page, but the real result will be available tomorrow. > > I'll let you know. > Hello Thomas, hello list. I'm happy to say that the problem seems to be solved : today, not a single sendmail error. Thank you very very much Thomas. Best regards, -- Raphaël Berlamont Final RT training for 2012 in Atlanta, GA - October 23 & 24 http://bestpractical.com/training We're hiring! http://bestpractical.com/jobs
Re: [rt-users] A ticket's life through multiple queues
Hi, I once worked at a managed helpdesk company as a support agent. At the time we used an in house solution, but it was very similar to rt in it's queue, owner, requestor setup (the only difference being that there could only be one requestor in this solution, but that doesn't really pertain here). The way we did it was that we would have the ticket from a user in the helpdesk queue, do our bit of work on it, and if we needed work from another department done we would create a child ticket in, say, the Sydney systems queue, which they would resolve once finished with (or pass ownership of back to the agent requesting extra details, who would pass it back with the details, etc etc). In out setup the owner of a ticket is emailed when a child ticket is solved, I'm sure this could be done in rt with scrips. Once they see the child ticket resolved they contact the user and resolve the original ticket. That way you have stats on what work everyone has done, as well as less worry abou t which queue to resolve in. Hope this helps On 18/09/2012, at 23:19, "Giuseppe Sollazzo" wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi everyone, > I have a little "philosophical" doubt about RT, so to say. > > In my institutions, we have several groups, most of which have their own > queue set. They mostly work on their queues, but occasionally need to > transfer the ticket under another queue. In some cases, a ticket need to > pass through 3-4 queues. > > My questions... > > Is this a common scenario? > How do other institutions deal with this kind of issues? > For statistical purposes, do you assign the ticket to a given queue > before closing it? > > Thanks, > Giuseppe > > - -- > Regards Chris O'Kelly Web Administrator Minecorp Australia P: 07 3723 1000 M: 0450 586 190 Minecorp Australia 37 Murdoch Circuit Acacia Ridge QLD 4110 www.minecorp.com.au Sent Via a Mobile Device. > > Giuseppe Sollazzo > Senior Systems Analyst > Computing Services > Information Services > St. George's, University Of London > Cranmer Terrace > London SW17 0RE > > Email: gsoll...@sgul.ac.uk > Direct Dial: +44 20 8725 5160 > Fax: +44 20 8725 3583 > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJQWHROAAoJEAqigArPBfJXGfIH/0DjKotSQbypQhnzK7coywO5 > prQqoU5HRXtyWckCjDEfFlCYCX6ieb4JsWw5Fzrgr8Gy6wNBUwkeF0+tCr8JOGpt > rW5/kZ+ui8/fREnTnBRHhWRlwoiSj+NEkd4KkD9QlVYIfK0YonBIuy+35Mz7b1Rk > V+koWBG4PQOhULUA8TGasp2YiRmYmTilnke3/Ji+kL0fk3giI88Sll3eq0pHkEYL > vKXzylFlKCWR74vCqt61fPW0E9cfpL8nXzL37j54Co7uogcDYiTTiY79xhehEMmb > lV6xaznU/gL8TqnhbBweMD3b4Y10P7XFU9sDYaF9SaqFp35kWU7h6kJQoVf0XLM= > =qujX > -END PGP SIGNATURE- > > > > Final RT training for 2012 in Atlanta, GA - October 23 & 24 > http://bestpractical.com/training > > We're hiring! http://bestpractical.com/jobs Final RT training for 2012 in Atlanta, GA - October 23 & 24 http://bestpractical.com/training We're hiring! http://bestpractical.com/jobs
Re: [rt-users] How to automatically disable user account
Thank you! That is exactly what I was missing. I tried looking through some other Perl scripts already in the folder to see what to "use," but hadn't run across those. I figured it would tell me, too, if it needed anything else sourced. At any rate, that fixed the problem. One other thing, it turns out that $user->SetDisabled(); doesn't actually work, as it needs a variable. SetDisabled(1) will disable account, while SetDisabled(0) will actually re-enable the account. Threw me off at first, but I'm good now. Thanks again for the help! - Aaron On Tue, Sep 18, 2012 at 7:27 AM, Tim Cutts wrote: > > On 17 Sep 2012, at 22:54, aaronr wrote: > > > > > I am looking for this same information. > > > > I found this program from a few years ago, which is supposed to disable a > > user: > > > > - > > #! /usr/bin/perl -w > > > > use lib '/srv/www/rt4/lib'; > > > > > > use RT::Base; > > use RT::Config; > > use RT::User; > > > > > > my $UserId = "sgeadmin"; > > my $user = RT::User->new($RT::SystemUser); > > $user->Load($UserId); > > $user->SetDisabled(); > > - > > It's missing some preamble needed to initialise the RT perl API. > Something like this: > > #! /usr/bin/perl -w > > use lib '/srv/www/rt4/lib'; > > use RT; > use RT::User; > > RT::LoadConfig; > RT::Init; > > my $UserId = "sgeadmin"; > my $user = RT::User->new($RT::SystemUser); > $user->Load($UserId); > $user->SetDisabled(); > > Should work. > > Tim > > -- > The Wellcome Trust Sanger Institute is operated by Genome Research > Limited, a charity registered in England with number 1021457 and a > company registered in England with number 2742969, whose registered > office is 215 Euston Road, London, NW1 2BE. > Final RT training for 2012 in Atlanta, GA - October 23 & 24 http://bestpractical.com/training We're hiring! http://bestpractical.com/jobs
Re: [rt-users] A ticket's life through multiple queues
On 18 Sep 2012, at 14:17, Giuseppe Sollazzo wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi everyone, > I have a little "philosophical" doubt about RT, so to say. > > In my institutions, we have several groups, most of which have their own > queue set. They mostly work on their queues, but occasionally need to > transfer the ticket under another queue. In some cases, a ticket need to > pass through 3-4 queues. > > My questions... > > Is this a common scenario? Yes. > How do other institutions deal with this kind of issues? With difficulty, I think. :-) > For statistical purposes, do you assign the ticket to a given queue > before closing it? As you've noticed, passing tickets between queues makes it very difficult to measure how much time was spent by each person on the ticket, making your performance metrics pretty meaningless. I think the orthodox argument goes like this: If the task actually requires multiple people to work on it, then it isn't a single task. It's multiple tasks. So, you spawn dependent tickets of the current ticket in the appropriate queues, each containing one of the sub-tasks, and only resolve the parent ticket when those are completed. This is a bit more work, but it makes your results measurable. If you want to measure how fast the end user got their request resolved, than you compile stats based on the parent tickets, but you now have individual tickets in other queues which you can perform stats on to identify how well those queues are working. You also can now have different owners for the different aspects of the work, so you have a better view of who's responsible for what. Ruslan's SpawnLinkedTicketInQueue extension can be useful for this: http://search.cpan.org/~ruz/RT-Extension-SpawnLinkedTicketInQueue-0.05/lib/RT/Extension/SpawnLinkedTicketInQueue.pm and if the sub-units of work are predictable, you can even generate the sub-tickets with Scrips, in theory, although I've never gone that far. Regards, Tim -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. Final RT training for 2012 in Atlanta, GA - October 23 & 24 http://bestpractical.com/training We're hiring! http://bestpractical.com/jobs
Re: [rt-users] How to automatically disable user account
On 17 Sep 2012, at 22:54, aaronr wrote: > > I am looking for this same information. > > I found this program from a few years ago, which is supposed to disable a > user: > > - > #! /usr/bin/perl -w > > use lib '/srv/www/rt4/lib'; > > > use RT::Base; > use RT::Config; > use RT::User; > > > my $UserId = "sgeadmin"; > my $user = RT::User->new($RT::SystemUser); > $user->Load($UserId); > $user->SetDisabled(); > - It's missing some preamble needed to initialise the RT perl API. Something like this: #! /usr/bin/perl -w use lib '/srv/www/rt4/lib'; use RT; use RT::User; RT::LoadConfig; RT::Init; my $UserId = "sgeadmin"; my $user = RT::User->new($RT::SystemUser); $user->Load($UserId); $user->SetDisabled(); Should work. Tim -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. Final RT training for 2012 in Atlanta, GA - October 23 & 24 http://bestpractical.com/training We're hiring! http://bestpractical.com/jobs
[rt-users] A ticket's life through multiple queues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, I have a little "philosophical" doubt about RT, so to say. In my institutions, we have several groups, most of which have their own queue set. They mostly work on their queues, but occasionally need to transfer the ticket under another queue. In some cases, a ticket need to pass through 3-4 queues. My questions... Is this a common scenario? How do other institutions deal with this kind of issues? For statistical purposes, do you assign the ticket to a given queue before closing it? Thanks, Giuseppe - -- Giuseppe Sollazzo Senior Systems Analyst Computing Services Information Services St. George's, University Of London Cranmer Terrace London SW17 0RE Email: gsoll...@sgul.ac.uk Direct Dial: +44 20 8725 5160 Fax: +44 20 8725 3583 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQWHROAAoJEAqigArPBfJXGfIH/0DjKotSQbypQhnzK7coywO5 prQqoU5HRXtyWckCjDEfFlCYCX6ieb4JsWw5Fzrgr8Gy6wNBUwkeF0+tCr8JOGpt rW5/kZ+ui8/fREnTnBRHhWRlwoiSj+NEkd4KkD9QlVYIfK0YonBIuy+35Mz7b1Rk V+koWBG4PQOhULUA8TGasp2YiRmYmTilnke3/Ji+kL0fk3giI88Sll3eq0pHkEYL vKXzylFlKCWR74vCqt61fPW0E9cfpL8nXzL37j54Co7uogcDYiTTiY79xhehEMmb lV6xaznU/gL8TqnhbBweMD3b4Y10P7XFU9sDYaF9SaqFp35kWU7h6kJQoVf0XLM= =qujX -END PGP SIGNATURE- Final RT training for 2012 in Atlanta, GA - October 23 & 24 http://bestpractical.com/training We're hiring! http://bestpractical.com/jobs
