Proposed: $RT::AutoCreatePrivileged

Hello!

I’m looking at account autocreation and have tripped over some
inconsistency with how autocreated accounts are granted privileged
status. Specifically, RT::User->LoadOrCreateFromEmail() assumes
unprivileged while RT::Interface::Web::WebExternalAutoInfo() assumes
privileged.

I’d propose a new config var, $RT::AutoCreatePrivileged, which is heeded
by both of those and anywhere else. I’ll happily offer a patch vs.
3.6.0pre0 (or pre1 =) if this sounds like a good idea.

Cheers!

–j
Jim Meyer, Geek at Large purp@acm.org

I recall that there is defualt hash for autocreated users data, may be
it’s not described in the config, but is used somewhere. We could
decribe it and use it everywhere. I think it’s more reasonable.On 4/4/06, Jim Meyer purp@acm.org wrote:

Hello!

I’m looking at account autocreation and have tripped over some
inconsistency with how autocreated accounts are granted privileged
status. Specifically, RT::User->LoadOrCreateFromEmail() assumes
unprivileged while RT::Interface::Web::WebExternalAutoInfo() assumes
privileged.

I’d propose a new config var, $RT::AutoCreatePrivileged, which is heeded
by both of those and anywhere else. I’ll happily offer a patch vs.
3.6.0pre0 (or pre1 =) if this sounds like a good idea.

Cheers!

–j

Jim Meyer, Geek at Large purp@acm.org


List info: The rt-devel Archives

Best Practical is hiring! Come hack Perl for us: Careers — Best Practical Solutions

Best regards, Ruslan.

Hello!On 4/3/06, Ruslan Zakirov ruslan.zakirov@gmail.com wrote:

On 4/4/06, Jim Meyer purp@acm.org wrote:

I’m looking at account autocreation and have tripped over some
inconsistency with how autocreated accounts are granted privileged
status. Specifically, RT::User->LoadOrCreateFromEmail() assumes
unprivileged while RT::Interface::Web::WebExternalAutoInfo() assumes
privileged.

I’d propose a new config var, $RT::AutoCreatePrivileged, which is heeded
by both of those and anywhere else. I’ll happily offer a patch vs.
3.6.0pre0 (or pre1 =) if this sounds like a good idea.

I recall that there is defualt hash for autocreated users data, may be
it’s not described in the config, but is used somewhere. We could
decribe it and use it everywhere. I think it’s more reasonable.

Funny you should mention the ambiguously-named $RT::AutoCreate:

Request Tracker Wiki

I just created that page today to document that exact config hashref.
It’s currently only used in the autohandler and only in the
WebExternal* bits.

I’d support using that mechanism. Can we make the name a bit more
explicit, say $RT::AutoCreateDefaultInfo? Also, it’d be really nice to
include a sample usage (commented out is fine) in RT_SiteConfig.pm as
distributed in order to make folks aware of it and its usage.

Again, I’ll happily offer patches.

Cheers!

–j
Jim Meyer, Geek at Large purp@acm.org

Hello!

I’m looking at account autocreation and have tripped over some
inconsistency with how autocreated accounts are granted privileged
status. Specifically, RT::User->LoadOrCreateFromEmail() assumes
unprivileged while RT::Interface::Web::WebExternalAutoInfo() assumes
privileged.

I’d propose a new config var, $RT::AutoCreatePrivileged, which is heeded
by both of those and anywhere else. I’ll happily offer a patch vs.
3.6.0pre0 (or pre1 =) if this sounds like a good idea.

I recall that there is defualt hash for autocreated users data, may be
it’s not described in the config, but is used somewhere. We could
decribe it and use it everywhere. I think it’s more reasonable.

Funny you should mention the ambiguously-named $RT::AutoCreate:
Yep, I think that’s it.

Request Tracker Wiki
There is also Request Tracker Wiki,
but I like you naming more, don’t delete the last one but note that
it’s the same.

I just created that page today to document that exact config hashref.
It’s currently only used in the autohandler and only in the
WebExternal* bits.

I’d support using that mechanism. Can we make the name a bit more
explicit, say $RT::AutoCreateDefaultInfo? Also, it’d be really nice to
include a sample usage (commented out is fine) in RT_SiteConfig.pm as
distributed in order to make folks aware of it and its usage.
It’s not documented and is not widely used, so I think we could rename
it. My suggestion for name is UserAutoCreateInfo, ‘Default’ is
meaningless because Config by default is storage of the defaults and
nobody stops you from overriding this defaults in extensions or other
code :slight_smile:

Again, I’ll happily offer patches.
Patches are allways wellcome when they improve things.

Cheers!

–j

Jim Meyer, Geek at Large purp@acm.org

Best regards, Ruslan.

Hello!

Request Tracker Wiki
There is also Request Tracker Wiki,

Whoops! I can’t see how I missed that one. Too big a hurry before
jetting to the south of France, I guess. ;p

but I like you naming more, don’t delete the last one but note that
it’s the same.

Okay, done. Also cleaned up SiteConfig, pulled in the info on
RTSiteConfig, and put a ref to RTSiteConfig on the SiteConfig page.

I’d support using [the $RT::AutoCreate hashref] mechanism.
Can we make the name a bit more
explicit, say $RT::AutoCreateDefaultInfo? Also, it’d be really nice to
include a sample usage (commented out is fine) in RT_SiteConfig.pm as
distributed in order to make folks aware of it and its usage.

It’s not documented and is not widely used, so I think we could rename
it. My suggestion for name is UserAutoCreateInfo, ‘Default’ is
meaningless because Config by default is storage of the defaults and
nobody stops you from overriding this defaults in extensions or other
code :slight_smile:

Fair enough. May I counterpropose “AutoCreateUserInfo” in that it’s
handy to have a pseudo-namespace for variables to help group them
conceptually?

Again, I’ll happily offer patches.
Patches are allways wellcome when they improve things.

Coming right up, then. =]

Cheers!

–j
Jim Meyer, Geek at Large purp@acm.org