Re: [rt-users] Mandatory Custom Field Privileges
On 07/09/2013 04:43 PM, Thomas Sibley wrote: On 07/09/2013 02:20 PM, Tim Wiley wrote: GroupA are workers in & effectively own Queue1. GroupA requested a number of custom fields for their queue that help facilitate better reporting on tickets. Because of the reporting nature of these custom fields, GroupA has requested that only they have the permissions required to set the values on these fields & that they are mandatory. Furthermore, these custom fields should be hidden from GroupB, the group that is allowed to submit tickets to the queue. Ideally, if GroupB can't see or modify the custom field, they shouldn't be told at ticket creation that the CFs are mandatory & the ticket should be created. Once a ticket lands in the hands of GroupA & they modify the ticket, the mandatory CFs with no values should then be verified & an error should be displayed, not allowing the modify until all mandatory CFs are filled out (because GroupA has permissions to see & modify the custom fields). I've looked all over for the special permissions recipe for this setup & I can't find anything. Am I the only one trying to use RT in this manner? Is there a way to do this that I'm missing? Do you need more information or clarification? I'll gladly supply it. You never said what you tried and what isn't working... Not letting one group of users see a set of CFs is possible with RT's rights, provided you haven't granted rights too widely at the global level. You may need to rejigger some of your rights first to be less global and more role/group/object specific. I think that might've been the key. I removed some more wide spread permissions on one of my mandatory fields & the error is gone. Let me play around with the others & I'll get back to you. The blanket permission was SeeCustomField granted to everyone on the CF level. I'm guessing that there's no good way to allow a user to see the field, but not modify it? Am I misunderstanding what SeeCustomField allows? It's possible, I was mistaken on SeeQueue a while back.
Re: [rt-users] Mandatory Custom Field Privileges
On 07/09/2013 02:20 PM, Tim Wiley wrote: > GroupA are workers in & effectively own Queue1. GroupA requested a > number of custom fields for their queue that help facilitate better > reporting on tickets. Because of the reporting nature of these custom > fields, GroupA has requested that only they have the permissions > required to set the values on these fields & that they are mandatory. > Furthermore, these custom fields should be hidden from GroupB, the group > that is allowed to submit tickets to the queue. Ideally, if GroupB > can't see or modify the custom field, they shouldn't be told at ticket > creation that the CFs are mandatory & the ticket should be created. Once > a ticket lands in the hands of GroupA & they modify the ticket, the > mandatory CFs with no values should then be verified & an error should > be displayed, not allowing the modify until all mandatory CFs are filled > out (because GroupA has permissions to see & modify the custom fields). > > I've looked all over for the special permissions recipe for this setup & > I can't find anything. Am I the only one trying to use RT in this > manner? Is there a way to do this that I'm missing? Do you need more > information or clarification? I'll gladly supply it. You never said what you tried and what isn't working... Not letting one group of users see a set of CFs is possible with RT's rights, provided you haven't granted rights too widely at the global level. You may need to rejigger some of your rights first to be less global and more role/group/object specific.
[rt-users] Mandatory Custom Field Privileges
GroupA are workers in & effectively own Queue1. GroupA requested a number of custom fields for their queue that help facilitate better reporting on tickets. Because of the reporting nature of these custom fields, GroupA has requested that only they have the permissions required to set the values on these fields & that they are mandatory. Furthermore, these custom fields should be hidden from GroupB, the group that is allowed to submit tickets to the queue. Ideally, if GroupB can't see or modify the custom field, they shouldn't be told at ticket creation that the CFs are mandatory & the ticket should be created. Once a ticket lands in the hands of GroupA & they modify the ticket, the mandatory CFs with no values should then be verified & an error should be displayed, not allowing the modify until all mandatory CFs are filled out (because GroupA has permissions to see & modify the custom fields). I've looked all over for the special permissions recipe for this setup & I can't find anything. Am I the only one trying to use RT in this manner? Is there a way to do this that I'm missing? Do you need more information or clarification? I'll gladly supply it.
Re: [rt-users] RT session cleanup - session table size
On Mon, Jul 08, 2013 at 08:05:32PM +0200, Alex Decalli wrote: >Thanks a lot Kevin. Frankly I have been working on this server for like 1 > week, this is RT3.8 >on Ubuntu 11.04 (terrible, I know), it has no GUI installed (no problem > for me), mysql 5.1 and >the administrator has left almost for 1 year, so no support for long time. > The auto logoff was >not set, we are planning to find all the problems, announce downtime (this > server is being >used globally) and make changes, I am planning to set the autologoff too. > But now, how can I >at least manually clean this session table? is there any way? (I am new to > this RT, so I am >really not sure how it works yet, I am studying it and I know that this > data on session table >is really useless for future) The SQL I mentioned was a bit of a hint. >> As for why nothing is deleted, if you log into your database (which >> database are you using?) you can run >> select min(LastUpdated) from sessions; >> to see what your data looks like. You can delete from sessions where LastUpdated is old, as long as you accept that RT does not *always* update the session for REST clients and some other users, so if someone has hardcoded a cookie rather than logging in and saving the cookie, there will be problems. -kevin pgpbfX88siDXk.pgp Description: PGP signature
Re: [rt-users] RT session cleanup - session table size
On Tue, Jul 09, 2013 at 03:23:53PM +0800, Craig Ringer wrote:
> On 07/09/2013 03:05 PM, Alex Decalli wrote:
> > I think there is no such table.
>
> There certainly is. From my PostgreSQL logs on the database that RT is
> using:
>
> UPDATE sessions SET a_session = $1 WHERE id = $2
>
> with a giant binary blob as $1"
>
> DETAIL: parameters: $1 = 'BQgDCQQRD1
>
> RT should really be using DBD::Pg's native bytea support on PostgreSQL,
> not base64-encoding binary for storing in the database, btw, something like:
>
> $rv = $sth->bind_param($param_num, $bind_value,
> { pg_type => DBD::Pg::PG_BYTEA });
RT uses Apache::Session which is what is storing things in the
session table in the database.
We document that you shouldn't bother backing up the session table.
Setting it to disappear on restart should be fine as long as your
users are ok with being logged out and your external processes aren't
storing session ids and trying to use them rather than logging in
(a surprisingly common failure case).
-kevin
pgpSWGEAB3QsL.pgp
Description: PGP signature
Re: [rt-users] Digitaly signed e-mails in RT?
On Tue, Jul 09, 2013 at 11:01:36AM +0200, Petr Grolmus wrote: > we would love to validate e-mails digitaly signed > by certificate and we need to visualize (e.g. by green > hook) that e-mail was successfuly verified. But not all > e-mails will be digitaly signed, just some of them. I tried to > find some plugins and/or extensions for this, but none > was useful. Is there any chance to verify signed incoming > e-mails and visualize it somehow in web interface of RT? > Or is this funcionality native in RT4? We use a little bit > older version -- 3.8.8-7+squeeze1 ;) RT 3.8 and 4.0 support GnuPG signatures. If you're looking for S/MIME support (you don't actually say, so I'm speculating) that should be natively supported in the 4.2 release. -kevin pgpmX3OMQri1I.pgp Description: PGP signature
[rt-users] Custom field appearance and single column ticket creation
When creating an RTIR "Investigations" ticket I'd like to modify the size of some of my custom fields and possibly having the "Basics" section with the custom fields in one column above the Launch a New Investigation section. I might also have to have more than one column *within* the Basics section so that the custom fields don't cause the entire page to be too long. I've read to make such modifications in files within /opt/rt4/local/plugins/RT-IR/html/Callbacks/RTIR/Ticket/Elements/EditCustomFields/ but I'm not sure I'm getting the hang of Mason markup. Am I at least on the right track? -- Landon Stewart
Re: [rt-users] RT session cleanup - session table size
On Tue, Jul 09, 2013 at 12:02:17PM +0800, Craig Ringer wrote: > On 07/07/2013 08:21 PM, Alex Decalli wrote: > > Hello everybody > > I want to cleanup my session table, it is already about 1 Gigabyte! I hit: > > > > me@myserver:~$ sudo rt-clean-sessions --debug --older 1M > > That reminds me - is there any reason RT would get upset if the sessions > table was suddenly empty after a restart? > > I'm wondering if it should be an UNLOGGED table on PostgreSQL 9.1 and > above, so it doesn't incur write-ahead logging overhead. If it doesn't > need to be crash-safe and it's OK to just have it truncated after a > crash recovery restart, that'd be ideal. > > Thoughts? > Hi Craig, Truncating the table does not cause any problems. Everyone will just need to login again. UNLOGGED is okay unless you want to be able to failover to a DB replica in which case you want them logged to have the backup DB updated. Regards, Ken
[rt-users] Digitaly signed e-mails in RT?
Hi there, we would love to validate e-mails digitaly signed by certificate and we need to visualize (e.g. by green hook) that e-mail was successfuly verified. But not all e-mails will be digitaly signed, just some of them. I tried to find some plugins and/or extensions for this, but none was useful. Is there any chance to verify signed incoming e-mails and visualize it somehow in web interface of RT? Or is this funcionality native in RT4? We use a little bit older version -- 3.8.8-7+squeeze1 ;) Thanks, Petr Grolmus
Re: [rt-users] RT session cleanup - session table size
On 07/09/2013 03:05 PM, Alex Decalli wrote:
> I think there is no such table.
There certainly is. From my PostgreSQL logs on the database that RT is
using:
UPDATE sessions SET a_session = $1 WHERE id = $2
with a giant binary blob as $1"
DETAIL: parameters: $1 = 'BQgDCQQRD1
RT should really be using DBD::Pg's native bytea support on PostgreSQL,
not base64-encoding binary for storing in the database, btw, something like:
$rv = $sth->bind_param($param_num, $bind_value,
{ pg_type => DBD::Pg::PG_BYTEA });
per http://search.cpan.org/~rudy/DBD-Pg/Pg.pm
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
