SeeCustomField right applied on Queue vs on CF?

RT Users
1

Hi All,

My users can’t see customfield on search form. I’m aware that they
should first select a queue and submit, but even if they do it, they
can’t see the customfields. SuperUser can see them.

Also, when they create, modify or display a ticket they can see and
modify those custom fields, so the problem is only on the search form
(Search/Build.html).

My users are in a “team” group, and this group have “SeeCustomField” and
"ModifyCustomField" rights on the queue.

I had to give SeeCustomField and ModifyCustomField rights to the "team"
group on the custom field itself, just to be able to see it in the
search form.

Looks awkward to me, am I doing something wrong ?

I’m using RT3.8.7 on ubuntu 10.04.1.

Thanks,

daniel

2

My users can’t see customfield on search form. I’m aware that they
should first select a queue and submit, but even if they do it, they
can’t see the customfields. SuperUser can see them.

Also, when they create, modify or display a ticket they can see and
modify those custom fields, so the problem is only on the search form
(Search/Build.html).

My users are in a “team” group, and this group have “SeeCustomField” and
“ModifyCustomField” rights on the queue.

I had to give SeeCustomField and ModifyCustomField rights to the “team”
group on the custom field itself, just to be able to see it in the
search form.

Looks awkward to me, am I doing something wrong ?

I’m using RT3.8.7 on ubuntu 10.04.1.

There have been a bunch of bug fixes in this code since 3.8.7 was
released more than 2 years ago. If the same ACL problem shows up on
3.8.11 or the 4.0.5rc1 release candidate, please file a bug.

Thanks

-kevin

3

Daniel,

When you grant rights for a Custom Field to a group, then they have those
rights regardless of Queue.

When you grant rights to Custom Fields at the Queue level, you lose the
ability to segregate Custom Fields in that Queue.

What if you have some Custom Fields in a Queue that you DO NOT want
everyone to see.

If you grant “SeeCustomFields” to a group or role at the Queue level only,
they will see ALL Custom Fields.

Now you have lost the ability to hide some CF’s from that group.

Granting Rights to Custom Fields to groups only allows you to relate the
need to see these fields for just those that actually need to see them.

You have more flexibility.

Also, if you had granted those rights to the CF’s for the GROUP while in
the Config->CustomFields, then they WOULD have seen them when in Query.

Hope this helps.

KennOn Thu, Jan 26, 2012 at 10:19 AM, Daniel BLANC dabl@42kettles.net wrote:

Hi All,

My users can’t see customfield on search form. I’m aware that they
should first select a queue and submit, but even if they do it, they
can’t see the customfields. SuperUser can see them.

Also, when they create, modify or display a ticket they can see and
modify those custom fields, so the problem is only on the search form
(Search/Build.html).

My users are in a “team” group, and this group have “SeeCustomField” and
“ModifyCustomField” rights on the queue.

I had to give SeeCustomField and ModifyCustomField rights to the “team”
group on the custom field itself, just to be able to see it in the
search form.

Looks awkward to me, am I doing something wrong ?

I’m using RT3.8.7 on ubuntu 10.04.1.

Thanks,

–
daniel

RT Training Sessions (http://bestpractical.com/services/training.html)

  • Boston March 5 & 6, 2012
4

Kevin Falcone falcone@bestpractical.com writes:

There have been a bunch of bug fixes in this code since 3.8.7 was
released more than 2 years ago. If the same ACL problem shows up on
3.8.11 or the 4.0.5rc1 release candidate, please file a bug.

Thanks

-kevin

Ok I was thinking about migrating to RT4 anyway. I’ll file a bug if the
problem is still there.

Thanks,

daniel

5

Kenneth,

Yup that helps. That confirm my intuition that giving SeeCustomField
rights on the queue level should be enough for my usecase. As kevin
said, that looks like a bug in 3.8.7, I’ll try to migrate to RT4 and
file a bug if the issue is still there.

Thanks,

daniel