We have losts of custom fields. I got tired of setting and
updating rights on these CFs, especially when the rights were
always the same as the ticket (or asset).
I came up with the following patch which allow you to set
a CF to inherit See/Show and Modify from the object it
is a CF of.
Looking for comments, such as:
1 This is a good idea and implementation.
2 This is a good idea but rotten implementation.
3 This is a stupid idea, what we need is a better way to
modify the rights on a bunch of CFs in bulk.
I myself am leaning toward 3, but I implemented 1 just for fun.
The patch is attached.
-Todd
inherit_cf.patch (7.16 KB)
Todd Chapman wrote:
We have losts of custom fields. I got tired of setting and
updating rights on these CFs, especially when the rights were
always the same as the ticket (or asset).
I came up with the following patch which allow you to set
a CF to inherit See/Show and Modify from the object it
is a CF of.
Looking for comments, such as:
1 This is a good idea and implementation.
2 This is a good idea but rotten implementation.
3 This is a stupid idea, what we need is a better way to
modify the rights on a bunch of CFs in bulk.
I myself am leaning toward 3, but I implemented 1 just for fun.
So what’s wrong with simply giving your users the (global)
SeeCustomField right?
If they can’t see the ticket (or asset) they should not be able to see
the fields. What am I missing?
Rolf
Todd Chapman wrote:
We have losts of custom fields. I got tired of setting and
updating rights on these CFs, especially when the rights were
always the same as the ticket (or asset).
I came up with the following patch which allow you to set
a CF to inherit See/Show and Modify from the object it
is a CF of.
Looking for comments, such as:
1 This is a good idea and implementation.
2 This is a good idea but rotten implementation.
3 This is a stupid idea, what we need is a better way to
modify the rights on a bunch of CFs in bulk.
I myself am leaning toward 3, but I implemented 1 just for fun.
So what’s wrong with simply giving your users the (global)
SeeCustomField right?
If they can’t see the ticket (or asset) they should not be able to see
the fields. What am I missing?
Rolf
That is an interesting idea. I have been operating under the
assumption that CF rights should be as restrictive as possible.
What you are suggesting is that access to the CF is really
governed by the more restrictive of CF rights or Ticket rights.
In Asset Tracker you don’t need Modify on an object to modify
the CFs. The CFs protect them selves. This allows for users
who shouldn’t be able to modify basic asset information but
need to modify one or more CFs. For example our guy in charge
of disaster recovery has one field he needs to modify but
is not allowed to change anything else.
-Todd
Todd Chapman wrote:>On Wed, Jun 08, 2005 at 09:37:32PM +0200, Rolf Grossmann wrote:
Todd Chapman wrote:
We have losts of custom fields. I got tired of setting and
updating rights on these CFs, especially when the rights were
always the same as the ticket (or asset).
I came up with the following patch which allow you to set
a CF to inherit See/Show and Modify from the object it
is a CF of.
Looking for comments, such as:
1 This is a good idea and implementation.
2 This is a good idea but rotten implementation.
3 This is a stupid idea, what we need is a better way to
modify the rights on a bunch of CFs in bulk.
I myself am leaning toward 3, but I implemented 1 just for fun.
So what’s wrong with simply giving your users the (global)
SeeCustomField right?
If they can’t see the ticket (or asset) they should not be able to see
the fields. What am I missing?
Rolf
That is an interesting idea. I have been operating under the
assumption that CF rights should be as restrictive as possible.
What you are suggesting is that access to the CF is really
governed by the more restrictive of CF rights or Ticket rights.
Ok, now I know what I was missing. I was only thinking about See/Show
rights, where that is the case. For modify, you’re right, you do not
need the ModifyTicket right.
So, the InheritSee right would be unnecessary, while the InheritModify
sounds like a good idea. I can’t quite discern from looking at the
patch, what the *-Magic versions would do. Care to explain?
Rolf
Ok, now I know what I was missing. I was only thinking about See/Show
rights, where that is the case. For modify, you’re right, you do not
need the ModifyTicket right.
So, the InheritSee right would be unnecessary, while the InheritModify
sounds like a good idea. I can’t quite discern from looking at the
patch, what the *-Magic versions would do. Care to explain?
Rolf
RT uses “magic” hidden fiels all over the place to indicate that
a form element existed but was not selected. Grep the RT html
for magic.
-Todd