-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi there,
a colleague here has asked me a question I’m not totally sure about.
He asked: is there any way to highlight a ticket that has received a
reply, in any way other than adding the “New” field?
What he’d like is roughly a highlighting background to the ticket in
the list.
Has anyone done anything similar?
Thanks,
Giuseppe
Giuseppe Sollazzo
Senior Systems Analyst
Computing Services
Information Services
St. George’s, University Of London
Cranmer Terrace
London SW17 0RE
Email: gsollazz@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://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPL+lsAAoJEAqigArPBfJXHtMIAI3LunoibB4atiEqnUkcBl+D
WylK4Lh6SwEIYnXzILjyehO8oWju1TcODR25DNPlJQy4vq6OGNEuIBo48+lteJcr
ZlKWHoKHY09vLYCgzRHvOKCLNpVHJT2CiGBNCOB/y4VzLVY7IPNp/P3XvLbb3N3C
SRUrRt3fEbzpkWMw2HyffJEDnBR8FF+8/EgI+yTJqns2PllUGGJ8k9lVCClcDjIz
lpfTcGBYSuNA7mt5tMT2iH3UPWZ9vhdsVqZCYPD0n0/dUu/iqbPlayR1bXw0j34/
nnlqBLAjybM81it1uorRKG0pN9lzkcT2xv7KuZziLWYoSdMVpB+Av5oc1WcQFxU=
=v/EV
-----END PGP SIGNATURE-----
a colleague here has asked me a question I’m not totally sure about.
He asked: is there any way to highlight a ticket that has received a
reply, in any way other than adding the “New” field?
What he’d like is roughly a highlighting background to the ticket in
the list.
Has anyone done anything similar?
You can use the UpdateStatus column. Changing the background would
require you to use a Callback with RT__Ticket’s ColumnMap.
I believe there are several examples of the ColumnMap Callback on the
wiki for highlighting a ticket with high priority that you could work
from.
-kevin
Hello all!
Prior to our 3.8.8 upgrade we were able to use /me | /selfservice as an
Alias to /SelfService in our rt.conf file. After upgrading I have been
unable to get rt.conf to honor /me as an Alias.
here is the meat of our rt.conf
... SSL stuff ...
Alias /me /SelfService
Alias /selfservice /SelfService
AllowOverride All
Options ExecCGI FollowSymLinks
SetHandler modperl
PerlResponseHandler Plack::Handler::Apache2
PerlSetVar psgi_app /opt/rt4/sbin/rt-server
AuthLDAPURL ldap://xyz.potsdam.edu/o=some_o?uid
AuthLDAPGroupAttribute memberUid
AuthLDAPGroupAttributeIsDN off
AuthName "Tracking System"
AuthType Basic
AuthBasicProvider ldap
use Plack::Handler::Apache2;
Plack::Handler::Apache2->preload("/opt/rt4/sbin/rt-server");
/SelfService works but /me results in ‘The page you requested could not be
found’
Granted this is not a RT issue, just wondering if anyone sees something
wrong or can help / point me in a direction to get this working.
-Ron
Prior to our 3.8.8 upgrade we were able to use /me | /selfservice as an
Alias to /SelfService in our rt.conf file. After upgrading I have been
unable to get rt.conf to honor /me as an Alias.
I know this isn’t exactly the answer to your question, but when users
log in to RT, they’ll be directed to SelfService if they are
Unprivileged users. Are you trying to push Privileged users off to
SelfService, and if so, why not just make them Unprivileged?
Also - your Apache error log is often more useful to debug these
things than the error presented in your browser.
-kevin
I know this isn’t exactly the answer to your question, but when users
log in to RT, they’ll be directed to SelfService if they are
Unprivileged users. Are you trying to push Privileged users off to
SelfService, and if so, why not just make them Unprivileged?
/SelfService works flawlessly, we just have a requirement to redirect /me
and /selfservice to /SelfService.
Also - your Apache error log is often more useful to debug these
things than the error presented in your browser.
I checked the logs first before posting, which tossed this cryptic entry
[Mon Feb 06 15:55:22 2012] [error] Your request path is ‘/me/’ and it
doesn’t match your Location(Match) ‘/opt/rt4/share/html/SelfService/’.
This should be due to the configuration error. See perldoc
Plack::Handler::Apache2 for details.
Looking at the perldoc does nothing but leave one even more bewildered.
From the code of Plack::Handler::Apache2
if ($location eq '/') {
# <Location /> could be handled as a 'root' case where we make
# everything PATH_INFO and empty SCRIPT_NAME as in the PSGI spec
$env->{SCRIPT_NAME} = '';
} elsif ($path_info =~ s{^($location)/?}{/}) {
$env->{SCRIPT_NAME} = $1 || '';
} else {
# Apache's <Location> is matched but here is not.
# This is something wrong. We can only respect original.
$r->server->log_error(
"Your request path is '$path_info' and it doesn't match your Location(Match) '$location'. " .
"This should be due to the configuration error. See perldoc Plack::Handler::Apache2 for details."
So the request is falling under the last option here. Plack is not liking the way you have your config written for aliasing. I would look at aliasing again in apache.
Alias /me/ "/opt/rt4/share/html/SelfService/
<Directory “/opt/rt4/share/html/SelfService/”>
…
…From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Ronald J Yacketta
Sent: Monday, February 06, 2012 4:38 PM
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] a tad OT,need assistance with aliasing /me to /SelfService
I know this isn’t exactly the answer to your question, but when users
log in to RT, they’ll be directed to SelfService if they are
Unprivileged users. Are you trying to push Privileged users off to
SelfService, and if so, why not just make them Unprivileged?
/SelfService works flawlessly, we just have a requirement to redirect /me and /selfservice to /SelfService.
Also - your Apache error log is often more useful to debug these
things than the error presented in your browser.
I checked the logs first before posting, which tossed this cryptic entry
[Mon Feb 06 15:55:22 2012] [error] Your request path is ‘/me/’ and it doesn’t match your Location(Match) ‘/opt/rt4/share/html/SelfService/’.
This should be due to the configuration error. See perldoc
Plack::Handler::Apache2 for details.
Looking at the perldoc does nothing but leave one even more bewildered.
-kevin
here is the meat of our rt.conf
... SSL stuff ...
Alias /me /SelfService
Alias /selfservice /SelfService
AllowOverride All
Options ExecCGI FollowSymLinks
SetHandler modperl
PerlResponseHandler Plack::Handler::Apache2
PerlSetVar psgi_app /opt/rt4/sbin/rt-server
AuthLDAPURL ldap://xyz.potsdam.edu/o=some_o?uid
AuthLDAPGroupAttribute memberUid
AuthLDAPGroupAttributeIsDN off
AuthName "Tracking System"
AuthType Basic
AuthBasicProvider ldap
use Plack::Handler::Apache2;
Plack::Handler::Apache2->preload("/opt/rt4/sbin/rt-server");
/SelfService works but /me results in ‘The page you requested could
not be found’
Granted this is not a RT issue, just wondering if anyone sees
something wrong or can help / point me in a direction to get this working.
-Ron
RT Training Sessions
(http://bestpractical.com/services/training.html)
RT Training Sessions (http://bestpractical.com/services/training.html)
- Boston - March 5 & 6, 2012
RT Training Sessions (http://bestpractical.com/services/training.html)
I know this isn’t exactly the answer to your question, but when users
log in to RT, they’ll be directed to SelfService if they are
Unprivileged users. Are you trying to push Privileged users off to
SelfService, and if so, why not just make them Unprivileged?
/SelfService works flawlessly, we just have a requirement to redirect /me
and /selfservice to /SelfService.
Also - your Apache error log is often more useful to debug these
things than the error presented in your browser.
I checked the logs first before posting, which tossed this cryptic entry
[Mon Feb 06 15:55:22 2012] [error] Your request path is ‘/me/’ and it
doesn’t match your Location(Match) ‘/opt/rt4/share/html/SelfService/’.
This should be due to the configuration error. See perldoc
Plack::Handler::Apache2 for details.
That was from a previous attempt before using fastcgi, I am not seeing any
errors in error_log or ssl_error_log. Seeing a bunch of http ‘200’ status
in access_log:
24.59.69.66 - - [06/Feb/2012:17:42:33 -0500] “GET /NoAuth/css/cloud.css
HTTP/1.1” 200 906 “https://rt.potsdam.edu/me” “Mozilla/5.0 (Windows NT
6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77
Safari/535.7”
24.59.69.66 - - [06/Feb/2012:17:42:33 -0500] “GET
/NoAuth/css/aileron-squished-16ded280fbc9be3ce3c3dcff881df9a7.css
HTTP/1.1” 200 75810 “https://rt.potsdam.edu/me” “Mozilla/5.0 (Windows NT
6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77
Safari/535.7”
24.59.69.66 - - [06/Feb/2012:17:42:33 -0500] “GET
/NoAuth/js/squished-6812ec8beec9403a8b720b6be4f3d8c9.js HTTP/1.1” 200
209347 “https://rt.potsdam.edu/me” “Mozilla/5.0 (Windows NT 6.1; WOW64)
AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7”
24.59.69.66 - - [06/Feb/2012:17:42:33 -0500] “GET
/NoAuth/css/web2/images/background-gradient.png HTTP/1.1” 200 394
“https://rt.potsdam.edu/me” “Mozilla/5.0 (Windows NT 6.1; WOW64)
AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7”
24.59.69.66 - - [06/Feb/2012:17:42:33 -0500] “GET /NoAuth/images/logo.jpg
HTTP/1.1” 200 6403 “https://rt.potsdam.edu/me” “Mozilla/5.0 (Windows NT
6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77
Safari/535.7”
24.59.69.66 - - [06/Feb/2012:17:42:33 -0500] “GET
/NoAuth/css/images/arrows-grey.png HTTP/1.1” 200 256
“https://rt.potsdam.edu/me” “Mozilla/5.0 (Windows NT 6.1; WOW64)
AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7”
24.59.69.66 - - [06/Feb/2012:17:42:33 -0500] “GET
/NoAuth/images//bplogo2.gif HTTP/1.1” 200 164 “https://rt.potsdam.edu/me”
“Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko)
Chrome/16.0.912.77 Safari/535.7”
24.59.69.66 - - [06/Feb/2012:17:42:33 -0500] “GET
/NoAuth/css/images/shadow.png HTTP/1.1” 200 1698
“https://rt.potsdam.edu/me” “Mozilla/5.0 (Windows NT 6.1; WOW64)
AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7”
24.59.69.66 - - [06/Feb/2012:17:42:33 -0500] “GET
/NoAuth/images/jquery_ui/ui-bg_flat_75_ffffff_40x100.png HTTP/1.1” 200 178
“https://rt.potsdam.edu/me” “Mozilla/5.0 (Windows NT 6.1; WOW64)
AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7”
24.59.69.66 - - [06/Feb/2012:17:42:34 -0500] “GET /NoAuth/css/print.css
HTTP/1.1” 200 973 “https://rt.potsdam.edu/me” “Mozilla/5.0 (Windows NT
6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77
Safari/535.7”
24.59.69.66 - - [06/Feb/2012:17:42:34 -0500] “GET
/NoAuth/images/favicon.png HTTP/1.1” 200 335 “-” “Mozilla/5.0 (Windows NT
6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77
Safari/535.7”
I know this isn’t exactly the answer to your question, but when users
log in to RT, they’ll be directed to SelfService if they are
Unprivileged users. Are you trying to push Privileged users off to
SelfService, and if so, why not just make them Unprivileged?
/SelfService works flawlessly, we just have a requirement to redirect /me
and /selfservice to /SelfService.
That doesn’t actually answer my question. If your Unprivileged user
logs into RT, RT will issue a redirect to /SelfService. There’s no need
to know about /me or /selfservice since the users just go to the top
level domain. I’m trying to understand your use case for /me and
/selfservice
Also - your Apache error log is often more useful to debug these
things than the error presented in your browser.
I checked the logs first before posting, which tossed this cryptic entry
[Mon Feb 06 15:55:22 2012] [error] Your request path is ‘/me/’ and it
doesn’t match your Location(Match) ‘/opt/rt4/share/html/SelfService/’.
This should be due to the configuration error. See perldoc
Plack::Handler::Apache2 for details.
Plack apparently doesn’t like being reached via something other than
the Location where it is configured (Plack is the library we use to
talk to Apache).
Try issuing a redirect rather than an Alias.
-kevin
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Kevin,
thanks, that’s a great suggestion!
Best regards,
GiuseppeOn 06/02/12 19:02, Kevin Falcone wrote:
On Mon, Feb 06, 2012 at 02:53:32PM +0000, Giuseppe Sollazzo wrote:
a colleague here has asked me a question I’m not totally sure
about.
He asked: is there any way to highlight a ticket that has
received a reply, in any way other than adding the “New” field?
What he’d like is roughly a highlighting background to the ticket
in the list.
Has anyone done anything similar?
You can use the UpdateStatus column. Changing the background
would require you to use a Callback with RT__Ticket’s ColumnMap.
I believe there are several examples of the ColumnMap Callback on
the wiki for highlighting a ticket with high priority that you
could work from.
-kevin
-------- RT Training Sessions
(http://bestpractical.com/services/training.html) * Boston ? March
5 & 6, 2012
Giuseppe Sollazzo
Senior Systems Analyst
Computing Services
Information Services
St. George’s, University Of London
Cranmer Terrace
London SW17 0RE
Email: gsollazz@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://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPMPQrAAoJEAqigArPBfJXi1wH/20d4jW/TKhI59iJANhyoXao
nja5u6ikSoI6E96+1wapb0q4zCrEiB5vuchnvzqwero+/TQ2E8HxLmftAc9cv6X5
BuaXuoZvA+ftVf7GV+a17fVxiyJSI8b8xuM2mfANrj/KZwSbGkQ1uLEbNm53Ei2d
vFF/D5MoR0G20qNASHOTALlK53aanxYq9i3QtaQX2dHGNBAKKF3gqFdVgRYrn9qq
EHcACZr6xbj+hPGtz50z9Q12BidGpR8Xi2p2G4UmybjMVfzENEmLMDXTPM75oBzE
xueF81qsBySJkuRnrCXhi9WVeArQOdyIvIcop+BPhhk0fAsI1VFLmAsyyoc7t1g=
=eUFU
-----END PGP SIGNATURE-----