On new user creation, I’d like to automatically add the user to the 'correct’
group as determined by a custom field set on the create user page.
I can’t work out where the least invasive place to hook in is. Wrapping
RT::Interface::Web::_ProcessObjectCustomFieldUpdates() doesn’t feel that
clean.
Any thoughts?
Nicholas Clark
On new user creation, I’d like to automatically add the user to the
‘correct’
group as determined by a custom field set on the create user page.I can’t work out where the least invasive place to hook in is.
Wrapping
RT::Interface::Web::_ProcessObjectCustomFieldUpdates() doesn’t feel
that
clean.
Unfortunately, custom fields get set after the user is created.
Which is going to make any solution here…unclean. I wonder if it
would be better to have a custom groups dropdown that you can use to
pick a group for the user on creation.
-j
PGP.sig (186 Bytes)
On new user creation, I’d like to automatically add the user to the
‘correct’
group as determined by a custom field set on the create user page.I can’t work out where the least invasive place to hook in is.
Wrapping
RT::Interface::Web::_ProcessObjectCustomFieldUpdates() doesn’t feel
that
clean.Unfortunately, custom fields get set after the user is created.
Which is going to make any solution here…unclean. I wonder if it
would be better to have a custom groups dropdown that you can use to
pick a group for the user on creation.
That’s somewhat icky too, as I’m also relying on the value of the custom
field in quite a few other places to identify the company that the user
belongs to. (And get back to the group). So really both need to be set.
Nicholas Clark
Nicholas Clark wrote:> On Tue, Jul 17, 2007 at 01:01:09PM -0400, Jesse Vincent wrote:
On Jul 17, 2007, at 12:06 PM, Nicholas Clark wrote:
On new user creation, I’d like to automatically add the user to the
‘correct’
group as determined by a custom field set on the create user page.I can’t work out where the least invasive place to hook in is.
Wrapping
RT::Interface::Web::_ProcessObjectCustomFieldUpdates() doesn’t feel
that
clean.Unfortunately, custom fields get set after the user is created.
Which is going to make any solution here…unclean. I wonder if it
would be better to have a custom groups dropdown that you can use to
pick a group for the user on creation.That’s somewhat icky too, as I’m also relying on the value of the custom
field in quite a few other places to identify the company that the user
belongs to. (And get back to the group). So really both need to be set.Nicholas Clark
In our experience it is easier to just add columns to the User and or
Group tables than use Custom Fields. It is FAR cleaner and faster.
Joby Walker
C&C SSG, University of Washington
Nicholas Clark wrote:
That’s somewhat icky too, as I’m also relying on the value of the custom
field in quite a few other places to identify the company that the user
belongs to. (And get back to the group). So really both need to be set.Nicholas Clark
In our experience it is easier to just add columns to the User and or
Group tables than use Custom Fields. It is FAR cleaner and faster.
That would require me to start tweaking parts of the UI to allow editing.
So far using Custom Fields appears to be giving adequate performance, and
for what I’m doing feels cleaner than changing lib/RT/User.pm etc
And I still don’t think that it would solve this problem, as I would still
need to find a way to add a trigger on user creation that adds them to a
group, as I wish to continue using RT’s standard ACL system for controlling
ticket visibility.
Nicholas Clark
Nicholas Clark wrote:
Nicholas Clark wrote:
That’s somewhat icky too, as I’m also relying on the value of the custom
field in quite a few other places to identify the company that the user
belongs to. (And get back to the group). So really both need to be set.Nicholas Clark
In our experience it is easier to just add columns to the User and or
Group tables than use Custom Fields. It is FAR cleaner and faster.That would require me to start tweaking parts of the UI to allow editing.
So far using Custom Fields appears to be giving adequate performance, and
for what I’m doing feels cleaner than changing lib/RT/User.pm etcAnd I still don’t think that it would solve this problem, as I would still
need to find a way to add a trigger on user creation that adds them to a
group, as I wish to continue using RT’s standard ACL system for controlling
ticket visibility.
True, but putting the hooks in local/lib/RT/User_Local.pm is simple, and
then you can override RT::User->create to do exactly what you want.
Adding a few UI elements to the Admin interface isn’t hard either.
As for performance, it depends on the number of users/customfieldvalues
you have. With 70,000+ users that adds up to a lot of
objectcustomfieldvalues records, and every SQL query you can avoid is a
gain. If you have a small installation, then it may not matter.
Relying on the RT::Interface::Web methods is unreliable since it would
only impact changes that pass through those methods. It is more
reliable to modify the actual object you wish to affect.
Joby Walker
C&C SSG, University of Washington
As for performance, it depends on the number of users/customfieldvalues
you have. With 70,000+ users that adds up to a lot of
objectcustomfieldvalues records, and every SQL query you can avoid is a
gain. If you have a small installation, then it may not matter.
Good point.
I think we’re around 200 users currently, and not likely to go over 700.
(but access to get the numbers is at work, and I’m not)
I don’t think that raw performance is going to matter. Maintainability is
key for this. In particular I’m keen to minimise the amount of
changing/wrapping of RT code, to make it as simple as possible for someone
not-me to upgrade the RT version in the future, when I’m no longer around.
Nicholas Clark