RT could not load a valid user, and RT's configuration does not allow for the creation of a new user for your email

I need to allow external users to send requests to the general queue, I
have granted createticket, but they are still denied and I get this
message in the log :

RT could not load a valid user, and RT’s configuration does not allow
for the creation of a new user for your email.

Can someone point me in the direction of the setting that will allow me
to create a new user for the email.

I have searched the Wiki and found nothing.

Many thanks,

Neil.

Neil Marjoram
Systems Manager
Adastral Park Campus
University College London
Ross Building
Adastral Park
Martlesham Heath
Ipswich - Suffolk
IP5 3RE

Tel: 01473 663711
Fax: 01473 635199

Reclaim Your Inbox!

I need to allow external users to send requests to the general queue, I
have granted createticket, but they are still denied and I get this
message in the log :

Whom have you granted that right to?

Jesse,

Sorry, should have said, I granted the right to group ‘everyone’ on the
General queue.

Many thanks,

Neil.

Jesse Vincent wrote:

I need to allow external users to send requests to the general queue, I
have granted createticket, but they are still denied and I get this
message in the log :

Whom have you granted that right to?

Neil Marjoram
Systems Manager
Adastral Park Campus
University College London
Ross Building
Adastral Park
Martlesham Heath
Ipswich - Suffolk
IP5 3RE

Tel: 01473 663711
Fax: 01473 635199

Reclaim Your Inbox!

Jesse,

Sorry, should have said, I granted the right to group ‘everyone’ on the
General queue.

Hm. For kicks, try granting it to Unprivileged users?

Jesse,

No difference, I then added all rights to Everyone and Unprivileged just
to see, but no difference.

Many thanks,

Neil.

Jesse Vincent wrote:

Jesse,

Sorry, should have said, I granted the right to group ‘everyone’ on the
General queue.

Hm. For kicks, try granting it to Unprivileged users?

Many thanks,

Neil.

Jesse Vincent wrote:

I need to allow external users to send requests to the general queue, I
have granted createticket, but they are still denied and I get this
message in the log :

Whom have you granted that right to?


Neil Marjoram
Systems Manager
Adastral Park Campus
University College London
Ross Building
Adastral Park
Martlesham Heath
Ipswich - Suffolk
IP5 3RE

Tel: 01473 663711
Fax: 01473 635199

Reclaim Your Inbox!
http://www.mozilla.org/products/thunderbird

Neil Marjoram
Systems Manager
Adastral Park Campus
University College London
Ross Building
Adastral Park
Martlesham Heath
Ipswich - Suffolk
IP5 3RE

Tel: 01473 663711
Fax: 01473 635199

Reclaim Your Inbox!

Do you use third party external auth extensions?On 3/16/06, Neil Marjoram n.marjoram@adastral.ucl.ac.uk wrote:

Jesse,

No difference, I then added all rights to Everyone and Unprivileged just
to see, but no difference.

Many thanks,

Neil.

Jesse Vincent wrote:

On Thu, Mar 16, 2006 at 02:36:23PM +0000, Neil Marjoram wrote:

Jesse,

Sorry, should have said, I granted the right to group ‘everyone’ on the
General queue.

Hm. For kicks, try granting it to Unprivileged users?

Many thanks,

Neil.

Jesse Vincent wrote:

On Thu, Mar 16, 2006 at 02:25:58PM +0000, Neil Marjoram wrote:

I need to allow external users to send requests to the general queue, I
have granted createticket, but they are still denied and I get this
message in the log :

Whom have you granted that right to?


Neil Marjoram
Systems Manager
Adastral Park Campus
University College London
Ross Building
Adastral Park
Martlesham Heath
Ipswich - Suffolk
IP5 3RE

Tel: 01473 663711
Fax: 01473 635199

Reclaim Your Inbox!
http://www.mozilla.org/products/thunderbird


Neil Marjoram
Systems Manager
Adastral Park Campus
University College London
Ross Building
Adastral Park
Martlesham Heath
Ipswich - Suffolk
IP5 3RE

Tel: 01473 663711
Fax: 01473 635199

Reclaim Your Inbox!
http://www.mozilla.org/products/thunderbird


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

We’re hiring! Come hack Perl for Best Practical: http://bestpractical.com/about/jobs.html

Best regards, Ruslan.

I found in your previouse message note that you use LDAP overlay from
the wiki. Could you share your RT config options related to external
auth?
Most probably you need $WebFallbackToInternalAuth to be true or may be
it’s limitation of the this overlay. Jim?On 3/20/06, Ruslan Zakirov ruslan.zakirov@gmail.com wrote:

Do you use third party external auth extensions?

On 3/16/06, Neil Marjoram n.marjoram@adastral.ucl.ac.uk wrote:

Jesse,

No difference, I then added all rights to Everyone and Unprivileged just
to see, but no difference.

Many thanks,

Neil.

Jesse Vincent wrote:

On Thu, Mar 16, 2006 at 02:36:23PM +0000, Neil Marjoram wrote:

Jesse,

Sorry, should have said, I granted the right to group ‘everyone’ on the
General queue.

Hm. For kicks, try granting it to Unprivileged users?

Many thanks,

Neil.

Jesse Vincent wrote:

On Thu, Mar 16, 2006 at 02:25:58PM +0000, Neil Marjoram wrote:

I need to allow external users to send requests to the general queue, I
have granted createticket, but they are still denied and I get this
message in the log :

Whom have you granted that right to?


Neil Marjoram
Systems Manager
Adastral Park Campus
University College London
Ross Building
Adastral Park
Martlesham Heath
Ipswich - Suffolk
IP5 3RE

Tel: 01473 663711
Fax: 01473 635199

Reclaim Your Inbox!
http://www.mozilla.org/products/thunderbird


Neil Marjoram
Systems Manager
Adastral Park Campus
University College London
Ross Building
Adastral Park
Martlesham Heath
Ipswich - Suffolk
IP5 3RE

Tel: 01473 663711
Fax: 01473 635199

Reclaim Your Inbox!
http://www.mozilla.org/products/thunderbird


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

We’re hiring! Come hack Perl for Best Practical: http://bestpractical.com/about/jobs.html


Best regards, Ruslan.

Best regards, Ruslan.

Hello!

Thanks for the noodge, Ruslan. I’d missed this one entirely.On Mon, 2006-03-20 at 12:38 +0300, Ruslan Zakirov wrote:

I found in your previouse message note that you use LDAP overlay from
the wiki. Could you share your RT config options related to external
auth?
Most probably you need $WebFallbackToInternalAuth to be true or may be
it’s limitation of the this overlay. Jim?

You shouldn’t need $WebFallbackToInternalAuth; the overlay supports
fallback by setting $AuthMethods as an array ref containing a list of
valid auth methods (thus far “LDAP” and “Internal” are valid).

To be sure I understand the thread correctly, it’s failing when you try
to add non-LDAP users via autocreation (either they mail in or you copy
them), correct?

I’ll start looking at this now.

Cheers!

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

Hello!

I think this is related to the LDAP overlay. I may have made a poor
assumption about what CanonicalizeUserInfo should return and why, or it
may be a bug in RT::User::Create(). I need guidance from the RT dev
folks as to what seems most correct.

If you’re desperate to get the LDAP overlay working, there’s a quick
hack at the end of this email but you have to promise to take it out
when we have a real solution. I’ll make fun of you if you don’t. =]

Things seem to break down when autocreating a new user who’s not in
LDAP. In this case, RT::User::Create() calls
RT::User::CanonicalizeUserInfo(), the latter being defined in the LDAP
overlay’s User_Local.pm. CanonicalizeUserInfo() returns true (1) if the
user is found in LDAP, otherwise it returns false (0). If it returns
false, RT::User::Create() returns failure with the message “Could not
set user info”.

As it stands, CanonicalizeUserInfo() must return true (1) at all times
in order to allow non-LDAP users to be created, even if it failed to do
anything; that doesn’t seem desirable.

One way to fix this would be to create a config variable to control
whether or not unrecognized users are created (e.g.
$RT::CreateUncanonicalizedUsers); then either RT::User::Create() or
CanonicalizeUserInfo() could heed that variable. Since RT::User::Create
() has this line:

unless ($self->CanonicalizeUserInfo(\%args)) {

…it gets my vote for change to this:

unless ($self->CanonicalizeUserInfo(\%args) || 
        $RT::CreateUncanonicalizedUsers) {

We could also do essentially the same thing in CanonicalizeUserInfo()'s
return statement, with this QUICK HACK*:

return($found || $RT::CreateUncanonicalizedUsers);

That seems less correct as it’s no longer a real return value, but
pragmatically speaking, it’s very easy to do.

Note that we could hijack $RT::SenderMustExistInExternalDatabase as the
config variable (and negate the logic suggested above), however that
seems tied to the whole WebExternalAuth bit which has always seemed
separate from the LDAP overlay. I’d be worried over adverse side
effects.

O Powers That Be, what say you?

–j

*QUICK HACK made explicit:

Put this line in your RT_SiteConfig.pm:

Set($CreateUncanonicalizedUsers, 1);

…and change the return line of CanonicalizeUserInfo() in User_Local.pm
from this:

return($found);

…to this:

return($found || $RT::CreateUncanonicalizedUsers);
Jim Meyer, Geek at Large purp@acm.org