RT::Client::REST

RT Users
1

Hi Folks;

RT-3.6.1
apache2/mod_perl2

I am looking for pointers to use RT::Client::REST in particular how to populate/update custom fields,any one used this for 3.6.1 (Dmitri ??);

Thanks;
Roy

2

I am looking for pointers to use RT::Client::REST in particular how to
populate/update custom fields,any one used this for 3.6.1
(Dmitri ??);

Gosh, it’s been a while since I touched this :slight_smile:

RT::Client::REST::Object (and, therefore,
RT::Client::REST::Object::Ticket) has method ‘cf’ which should work. If
it does not, file a bug and I’ll take care of it.

  • Dmitri.
3

Got it working a treat, but I need to be able to disable accounts and
re-enable them, is this possible with RT::Client::REST?

If not, how would one do it?

Thanks,

Michelle

4

Got it working a treat, but I need to be able to disable accounts and
re-enable them, is this possible with RT::Client::REST?

If we look at next page 1, it is not possible. I tried to several
actions in a custom program for working with users, and I was not able
to do.

If not, how would one do it?

You could do using MySQL queries.

Best regards,

Alberto Villanueva
Industria

ALTRAN

C/Campezo, 1, Edificio 1, Planta 4
28022 Madrid, Spain
Tel : + 34 91 550 41 00
Fax: + 34 91 415 61 53

www.altran.es

Antes de imprimir este mensaje, aseg�rate de que es necesario. Proteger
el medio ambiente est� tambi�n en tu mano.

En cumplimiento de la Ley Org�nica 15/1999, con fecha 13 de diciembre,
de Protecci�n de Datos de Car�cter Personal, y la Ley 34/2002, con fecha
11 de julio, de Servicios de la Sociedad de la Informaci�n y de comercio
electr�nico, le comunicamos que su direcci�n de correo electr�nico forma
parte de un fichero del que es responsable Altran Espa�a, y que
garantiza la confidencialidad y seguridad de sus datos. Tiene usted
derecho al acceso, rectificaci�n y cancelaci�n de sus datos en los
t�rminos establecidos en la Ley Org�nica 15/1999 de Protecci�n de Datos
de Car�cter Personal y dem�s normativa concordante, dirigi�ndose a
nuestra direcci�n anteriormente se�alada o por medio de correo
electr�nico: comunicacion@altran.es mailto:comunicacion@altran.es.

AVISO LEGAL: Este mensaje, junto con cualquier fichero adjunto, est�
dirigido a su destinatario y es confidencial. Cualquier distribuci�n,
uso o reproducci�n sin consentimiento del remitente est� estrictamente
prohibido. Si ha recibido este mensaje por error, por favor proceda a
ponerlo en conocimiento del remitente por e-mail y a borrarlo de su
sistema sin realizar copias.

5

Alberto Villanueva wrote:

Got it working a treat, but I need to be able to disable accounts and
re-enable them, is this possible with RT::Client::REST?

If we look at next page [1], it is not possible. I tried to several
actions in a custom program for working with users, and I was not able
to do.

If not, how would one do it?

You could do using MySQL queries.

I was trying to avoid talking to the RT DB directly - the other option
is to change the name to name.disabled (or some random string) as I am
tracking the numeric ID, so that would be a solution. I guess the other
option is to disable the internal auth and use my DB for auth (which
it’s already doing, I just haven’t disabled the internal one.)

For information only, I’m running a separate DB which provides
authentication into other systems, and RT will use it and fall back to
it’s own. I’m currently merging the 2 so that the account creation and
update in my DB will replicate the changes to the old RT installation
and have a ‘verify email’ before making active function in my DB. I
wanted to disable the account in RT if they changed their email until
such time as they verified it.

Michelle

6

Alberto Villanueva wrote:

Got it working a treat, but I need to be able to disable accounts and
re-enable them, is this possible with RT::Client::REST?

If we look at next page [1], it is not possible. I tried to several
actions in a custom program for working with users, and I was not able
to do.

If not, how would one do it?

You could do using MySQL queries.

I was trying to avoid talking to the RT DB directly - the other option
is to change the name to name.disabled (or some random string) as I am
tracking the numeric ID, so that would be a solution. I guess the other
option is to disable the internal auth and use my DB for auth (which
it’s already doing, I just haven’t disabled the internal one.)

For information only, I’m running a separate DB which provides
authentication into other systems, and RT will use it and fall back to
it’s own. I’m currently merging the 2 so that the account creation and
update in my DB will replicate the changes to the old RT installation
and have a ‘verify email’ before making active function in my DB. I
wanted to disable the account in RT if they changed their email until
such time as they verified it.

You can certainly use the RT perl API to disable/enable users.
RT-Authen-ExternalAuth can also manage passwords/enable|disable users
from an external sql db, but it only checks when a user tries to log
in.

-kevin