[rt-devel] Getting Custom Fields for a User

[Ruslan Zakirov]

On Mon, Apr 16, 2012 at 23:29, Lee Wilson <leefm40 at yahoo.co.uk> wrote:
> Hi Ruslan,
>
> Thanks for that. Looking at the perldoc for User.pm doesn't give any mention
> of that but I guess it's inherited from Record.pm

Right. In theory CFs can be on any object in the system, so methods
are in Record.pm.

> Think I've sussed out the problem, I was trying to run this as a none
> privileged user but it didn't have access to SeeCustomFields based on the
> code in CustomFields->Next:
>
> return $self->Next unless $CF->CurrentUserHasRight('SeeCustomField');
>
> I tried granting the SeeCustomField and ModifyCustomField rights on the
> specific customer queue but that still didn't make the fields appear.

Queues has nothing to do with Users and your "customer queue" is just
logical agreement RT doesn't know about. So custom fields applied to
users' records can not inherit rights from queues, may be from groups,
but it's not implemented. More about rights below.

> In the end I granted those two rights onto the global unprivileged group
> which has made the fields appear but it seems a bit too open to me.
>
> Eventually I think applying those rights to the specific custom field has
> given what I needed.
>
> Would this generally be the right way to do it?

The most correct and safe way is to grant rights to groups for every
custom field. May be it's not flexible enough, but this the only way
that properly isolates access.

Some objects in RT announce rights and you can grant particular
principal (group/user/role) to have a right on an object. These
objects are Tickets, CustomFields, Queues, Groups... Nobody wants to
grant rights on every ticket, so there is concept of rights
inheritance when right is check on ticket, but is set on queue. Every
object inherits rights from system level.

All custom fields in RT use one right "SeeCustomField" that is checked
to decide whether user can see or not the field. This means that if
you grant this right on global level to a group then this group can
see ALL custom fields in the system. May be they can not see them in
UI by pointing and clicking, but low level code would hide them.
Extension or custom page may expose them and it wouldn't be its fault.

Rights inheritance for tickets is "simple". Every ticket is in one and
only one queue at a moment. You grant rights on queue level.

Rights inheritance for custom fields is complex. Different custom
fields have different inheritance chains. For custom fields that apply
to Users, it's system -> custom field, but for tickets' CFs it's
system -> queue -> custom field. Also, the same ticket custom field
can be applied to multiple queues. It's even more complicated under
the hood. So granting SeeCustomField to a group on queue level to give
users ability to see all CFs on tickets in this queue may be cool
feature, but it's too complex to implement right and it's considered
experimental with known issues.



-- 
Best regards, Ruslan.