Re: [rt-users] Mandatory Custom Fields in 3.8
Can anyone help please ? Just tell me if it is possible or not :) Thanks F350 wrote: Greetings all, I was wondering if there is a way to oblige users to fill in custom fields before resolving tickets. Can we do that in RT 3.8.0 ? I created a custom field of type Select one value and I would like the support team to select a value before closing each ticket. That would help for the end of the semester statistics. Thanks -- View this message in context: http://www.nabble.com/Mandatory-Custom-Fields-in-3.8-tp18565630p18647127.html Sent from the Request Tracker - User mailing list archive at Nabble.com. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Mandatory Custom Fields in 3.8
On Fri, Jul 25, 2008 at 01:07:49AM -0700, F350 wrote: Can anyone help please ? Just tell me if it is possible or not :) Thanks F350 wrote: Greetings all, I was wondering if there is a way to oblige users to fill in custom fields before resolving tickets. Can we do that in RT 3.8.0 ? I created a custom field of type Select one value and I would like the support team to select a value before closing each ticket. That would help for the end of the semester statistics. You can make it mandatory in the CF configuration, then you can add the Callback http://wiki.bestpractical.com/view/EditCustomFieldsOnUpdate to let you're users edit CFs when clocking on resolve. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] strange subject charset
hi: i am using rt 3.4.5 now and tried to upgrade to 3.8.0 in another machine. after upgrade, i found the Chinese characters in the subject of old tickets become ???. others fields are ok. i go to the attachment table with phpMyAdmin and found situation below: the subject data in rt 3.4.5 table is encoded by some method. it's not utf8. but the subject data present as utf8 correctly in browser. after upgrade: the subject data in rt 3.8.0 table is now utf8.(they are converted by the upgrade procedure!!) but the subject data now present as ??? in browser. if I key-in new data in rt 3.8.0, they look like rt 3.4.5: the subject data in database is encoded, not utf8. they can show correctly as utf8 in browser. in fact, i like my data as utf8 in database, they look better. but more important, they must show correctly in browser. how can i fix this? maybe i should set some parameters or update some perl modules? thanks a lot for help!! ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Mandatory Custom Fields in 3.8
On Fri, Jul 25, 2008 at 01:07:49AM -0700, F350 wrote: Can anyone help please ? Just tell me if it is possible or not :) Thanks Yes. This is what the Validation field does for Custom Fields. Go to your custom field's edit page and select: (?#Mandatory). If you're adventurous, this can be an arbitrary Perl regular expression. F350 wrote: Greetings all, I was wondering if there is a way to oblige users to fill in custom fields before resolving tickets. Can we do that in RT 3.8.0 ? I created a custom field of type Select one value and I would like the support team to select a value before closing each ticket. That would help for the end of the semester statistics. Thanks -- View this message in context: http://www.nabble.com/Mandatory-Custom-Fields-in-3.8-tp18565630p18647127.html Sent from the Request Tracker - User mailing list archive at Nabble.com. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] RT version 3.8.0 and RT-Authen-ExternalAuth-0.05
Hi, I have just installed RT 3.8.0 and RT-Authen-ExternalAuth-0.05. *Before* I post a more detailed report, I just would like to know if this is known to work with the new RT. When I start apache I see this this is 'talking' initially to my OpenLDAP, but when I try to authenticate as an OpenLDAP user I get your username and password is incorrect. I see no activity at this point on my OpenLDAP. My RT_SiteConfig.pm ldap details look OK (although I do have some questions about some options) I simply see in /var/log/messages: (I presume that Set($LogToSyslog, 'debug'); gives the most details) Jul 25 10:37:06 rt RT: FAILED LOGIN for jbloggs from 149.157.xx.yy (/ opt/rt3/share/html/autohandler:265) I see that RT-Authen-ExternalAuth is installed in: [EMAIL PROTECTED] plugins]# pwd /opt/rt3/local/plugins [EMAIL PROTECTED] plugins]# ls RT-Authen-ExternalAuth which is a different path [I think] to previous versions of RT. Regards, Jason Doran National University of Ireland, Maynooth smime.p7s Description: S/MIME cryptographic signature ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] RT version 3.8.0 and RT-Authen-ExternalAuth-0.05
I can say it works with Active Directory. I had to install perl-LDAP
though, on my CentOS5 machine. yum install perl-LDAP
I had just got the plugin working under 3.6.6 when 3.8.0 came out. I
moved my 3.6.6 directory out of the way, did it's install, and then ran
the ExternalAuth install.
I noticed the path changed too when I copied over the plugin's
RT_SiteConfig.pm file and had to fix the require line in my main
RT_SiteConfig.pm.
In case this can help, here's a stripped and manually redacted version
of my RT_SiteConfig.pm in the Plugin's etc/ directory which works in my
Windows 2000 Active Directory environment: (It's included via the main
RT_SiteConfig.pm with a 'require
/opt/rt3/local/plugins/RT-AuthenExternalAuth/etc/RT_SiteConfig.pm;'
line)
Set($ExternalAuthPriority, [ 'My_LDAP'
]
);
Set($ExternalInfoPriority, [ 'My_LDAP'
]
);
Set($ExternalServiceUsesSSLorTLS,0);
Set($AutoCreateNonExternalUsers,0);
Set($ExternalSettings, {
'My_LDAP' = {
'type' = 'ldap',
'auth' = 1,
'info' = 1,
'server'= 'adomaincontroller.example.com',
'user' =
'CN=RTLDAPLookupUser,OU=someou,DC=example,DC=com',
'pass' = 'passwordofrtlookupuser',
'base' = 'DC=example,DC=com',
'filter'= '(objectClass=Person)',
'd_filter' =
'(userAccountControl:1.2.840.113556.1.4.803:=2)',
'tls' = 0,
'net_ldap_args' = [version = 3 ],
'group' = '',
'group_attr'= '',
'attr_match_list' = ['Name',
'EmailAddress',
'RealName',
'WorkPhone',
'Address2'
],
'attr_map' = {
'Name' = 'sAMAccountName',
'EmailAddress' = 'mail',
'Organization' = 'physicalDeliveryOfficeName',
'RealName' = 'cn',
'ExternalAuthId' = 'sAMAccountName',
'Gecos' = 'sAMAccountName',
'WorkPhone' = 'telephoneNumber',
'Address1' = 'streetAddress',
'City' = 'l',
'State' = 'st',
'Zip' = 'postalCode',
'Country' = 'co'
}
],
}
}
);
1;
I also used ldapdisplay to test the ldap query of the Active Directory:
ldapsearch -LLL -x -D CN=RTLDAPLookupUser,OU=someou,DC=example,DC=com
-w passwordofrtlookupuser -h adomaincontroller.example.com
((sAMAccountName=BRIAN)(objectClass=Person))
BTW, for about an hour I found I was changing the left side of the
password of the RT lookup user in RT_SiteConfig.pm, (The parameter name)
rather than the right side, the value. I don't know why, I was just
replacing `user` with the user and `pass` with the password I guess,
even though I did the correct right-side replacement on everything else.
HTH.
Brian
On Fri, 2008-07-25 at 11:29 +0100, Jason Doran wrote:
Hi,
I have just installed RT 3.8.0 and RT-Authen-ExternalAuth-0.05.
*Before* I post a more detailed report, I just would like to know if
this
is known to work with the new RT.
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Mandatory Custom Fields in 3.8
Shawn M Moore wrote: Yes. This is what the Validation field does for Custom Fields. Go to your custom field's edit page and select: (?#Mandatory). If you're adventurous, this can be an arbitrary Perl regular expression. Is it possible to require a mandatory field using a regex? Unfortunately I'm not at a terminal where I can get into RT and check, and I'll probably forget by then anyway. :P Thanks. -scott ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] Workflow for release management
I've been scanning the archives for ideas about release management. Our specific sticking point is to better handle the testing (QA) and release process in RT. I'm hoping someone here can offer suggestions. In a small organization we have a few different projects we manage. We are currently using a number of RT queues to collect bug reports and feature requests. At any given time we have a pool of tickets. We would like to select a subset of these tickets for our next release, which our goal is to do every two weeks. We then have about ten or so developers that work on implementing these tickets. Then, once completed, pass the tickets off to the testing team (one or two individuals). Tickets are then accepted or rejected (and sent back to development). Once all tickets are accepted (or delayed for another release) we need to release. Ideally, all tickets should then be tagged to that release so if we need to look back we can see what ticket was associated with a given release. Clearly, we will want a way to easily view and select tickets for each phase of the process. Is anyone working with a similar process? Could you describe how you are supporting this workflow with RT? I'm not clear, for example, if it makes sense to use separate queues for the different phases, or custom fields to indicate that a ticket has been selected for the next release, and if it's in development, QA, or pending release. Our plan is to also tightly couple RT with subversion. The goal is to not allow any subversion checkins that do not include an RT ticket number (with the flexibility to allow creation of new RT tickets upon checkin). The log message of the checking will be added to the ticket and the check in will also create a link in the RT ticket back to the subversion change set. I assume this will not be too difficult to implement, but I assume it's also not uncommon usage so suggestions or pointers are very welcome, too. Thanks very much, -- Bill Moseley [EMAIL PROTECTED] ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Workflow for release management
Bill, Sounds like you do exactly what we do for some of our software support groups. We added a few new active status values and built some scrips to add two new functional processes; Review Approval and QA WorkFlow. WE modified the tabs in the Modify Ticket pages to display these new options. They work like this: 1) A ticket is received(email)/created in the Requests Queue. This queue is used to collect requests that may/may not be approved and moved to an appropriate support queue. A notification is sent to the Requestor. 2) Ticket Status is changed to pending rv (new TAB on page). The ticket is evaluated and investigated and the result (upon completion of evaluation) the Ticket Status is changed to rejected (not approved) or rq approvd (approved. new TAB on page). If rejected, a comment is required to explain why and that is included in the notification tamplate. A notification is sent to the Requestor. 3) The ticket is moved to the appropriate support queue. the ticket can now be opened and worked on. If several sub-tasks are required, they are created as Children tickets. If other tasks are required from other groups, depending on tickets are created in those queues. A notification is sent to the Requestor AND new Queue Admin (AdminCc). 4) The new Queue Admin assigns the ticket to a developer/owner. 5) The ticket status is changed to open. The ticket is worked on from developing specs to system testing. These steps are indicated using a Custom Field called Work-Status. A notification is sent to the Requestor. 6) The ticket status is changed to pending qa (new TAB on page). Due to new scrips, RT automatically changes the new Custom Field QA Approved value to Not Started and the CF Work-Status value to Acceptance Testing. A notification scrip is sent to the Requestor AND the QA Approval Group. The QA Test scripts are attached to the notification. 7) The QA Approval group tests the work product. When complete, anyone in THAT group only (CF rights) changes the value in the CF QA Approved to either Yes or No. Due toi new scrips, RT automatically change the ticket status to stalled (if CF QA Approved is No) or to qa approvd (if CF QA Approved is Yes). A notification scrip is sent to the Requestor, Owner, AdminCc, AND the Migrator/Promoter. The Migration/Promotion instructions are attached to the notification. 8) The Migrator/Promoter moves the product into production, and possibly changes the ticket status to resolved, depending on how the Queue Admin has setup his infrastructure permissions. Otherwise, the Queue Admin resolves the ticket. I am currently looking into having RT automatically execute the version control migration when the ticket status is changed to resolved via CF/scrips. This entire process is documented in our User and Admin guides. I'm sure you will want to do things a differently in some manner, but this should give you an idea of how we handled it. We'd be more than happy to help in any way we can. Hope this design concept helps. Kenn LBNL On 7/25/2008 10:42 AM, Bill Moseley wrote: I've been scanning the archives for ideas about release management. Our specific sticking point is to better handle the testing (QA) and release process in RT. I'm hoping someone here can offer suggestions. In a small organization we have a few different projects we manage. We are currently using a number of RT queues to collect bug reports and feature requests. At any given time we have a pool of tickets. We would like to select a subset of these tickets for our next release, which our goal is to do every two weeks. We then have about ten or so developers that work on implementing these tickets. Then, once completed, pass the tickets off to the testing team (one or two individuals). Tickets are then accepted or rejected (and sent back to development). Once all tickets are accepted (or delayed for another release) we need to release. Ideally, all tickets should then be tagged to that release so if we need to look back we can see what ticket was associated with a given release. Clearly, we will want a way to easily view and select tickets for each phase of the process. Is anyone working with a similar process? Could you describe how you are supporting this workflow with RT? I'm not clear, for example, if it makes sense to use separate queues for the different phases, or custom fields to indicate that a ticket has been selected for the next release, and if it's in development, QA, or pending release. Our plan is to also tightly couple RT with subversion. The goal is to not allow any subversion checkins that do not include an RT ticket number (with the flexibility to allow creation of new RT tickets upon checkin). The log message of the checking will be added to the ticket and the check in will also create a
[rt-users] An idea for RT
Jesse, list, I was thinking that it might be a really kool option to allow each RT installation to configure how all dates are displayed. Not everyone wants the time info and we all know that not everyone uses the same format, either mm/dd/ or MMM dayofweek , etc. If RT could allow us to configure it to default all date displays/search results, it might make it's visability more user-friendly. Just a thought. Kenn LBNL ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] An idea for RT
On Fri, Jul 25, 2008 at 11:45:07AM -0700, Kenneth Crocker wrote: Jesse, list, I was thinking that it might be a really kool option to allow each RT installation to configure how all dates are displayed. Not everyone wants the time info and we all know that not everyone uses the same format, either mm/dd/ or MMM dayofweek , etc. If RT could allow us to configure it to default all date displays/search results, it might make it's visability more user-friendly. Just a thought. You haven't upgraded to RT 3.8 yet, have you? :) Kenn LBNL -- ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] An idea for RT
You probably already know that limited a choice of formats is available
in 3.8
http://bestpractical.typepad.com/worst_impractical/2008/07/today-were-rele.html
Under User Preferences, Date and Time Format.
I'm seeing:
1. Tue Dec 25 21:59:12 1995
2. Tue, 25 Dec 1995 21:59:12 -0300
3. 1995-11-24 21:59:12
4. 1995-1125T21:5912Z
So perhaps there already is way to add more formats.
From RT_Config.pm:
=item C$DateTimeFormat
You can choose date and time format. See Output formatters
section in perldoc Flib/RT/Date.pm for more options. This option can
be overridden by users in their preferences.
Some examples:
CSet($DateTimeFormat, { Format = 'ISO', Seconds = 0 });
CSet($DateTimeFormat, 'RFC2822');
CSet($DateTimeFormat, { Format = 'RFC2822', Seconds = 0, DayOfWeek =
0 });
=cut
Set($DateTimeFormat, 'DefaultFormat');
Brian
On Fri, 2008-07-25 at 11:45 -0700, Kenneth Crocker wrote:
Jesse, list,
I was thinking that it might be a really kool option to allow each RT
installation to configure how all dates are displayed. Not everyone
wants the time info and we all know that not everyone uses the same
format, either mm/dd/ or MMM dayofweek , etc. If RT could
allow us to configure it to default all date displays/search results, it
might make it's visability more user-friendly. Just a thought.
Kenn
LBNL
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
[rt-users] Username at RT login not matching Ticket sent via e-mail
Hello All, As users send tickets via e-mail their tickets are Requester set to [EMAIL PROTECTED] but at login they are username and as username cannot see their e-mailed tickets within the RT website. Is there a way to set it so logging in users can see their e-mailed tickets? A scrip or config? I just was moved to running our RT so I'm still fishing through the config's and setup. Thanks, Jorge ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
