Hello,
we’re running request tracker 4.0.7-4~bpo60 on debian stable. I have setup approvals for one queue, which works fine, except the the most recently added user.
For this user, no approval notification mails are sent, and the approval ticket stays in state new. For the other, they are notified, and the approval ticket changes to open automatically.
The only difference I see is that the special user is not in any groups, in contrast to those were it works.
I would appreciate any hints, especially were to start debugging.
TIA,
Joerg
The information in this e-mail is confidential and may be legally privileged. If you have received this e-mail in error, please reply to its sender indicating “received in error” in the subject line, then delete the e-mail and destroy any copies of it. If you are not its intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on this e-mail, is prohibited and may be unlawful. Internet communications are not considered secure. Information might be intercepted, amended, lost, destroyed, arrive late or incomplete, or might contain viruses. Catella will not accept any liability with respect to the contents of this email and its attachments.
http://www.catella.lu/
Hello,
my problems has been solve by studying some source code.
The approval process could benefit from an example with explanations 
Bye,
JoergOn 28.02.2013 12:38, Joerg.Dorchain@catella.lu wrote:
Hello,
we’re running request tracker 4.0.7-4~bpo60 on debian stable. I have
setup approvals for one queue, which works fine, except the the most
recently added user.
For this user, no approval notification mails are sent, and the approval
ticket stays in state new. For the other, they are notified, and the
approval ticket changes to open automatically.
The only difference I see is that the special user is not in any groups,
in contrast to those were it works.
I would appreciate any hints, especially were to start debugging.
TIA,
Joerg
/
The information in this e-mail is confidential and may be legally
privileged. If you have received this e-mail in error, please reply to
its sender indicating “received in error” in the subject line, then
delete the e-mail and destroy any copies of it. If you are not its
intended recipient, any disclosure, copying, distribution or any action
taken or omitted to be taken in reliance on this e-mail, is prohibited
and may be unlawful. Internet communications are not considered secure.
Information might be intercepted, amended, lost, destroyed, arrive late
or incomplete, or might contain viruses. Catella will not accept any
liability with respect to the contents of this email and its attachments.
/
/http://www.catella.lu//
Catella Bank S.A. IT
Parc d�Activit�s - CAP 2
38 rue Pafebruch
L-8308 Capellen
Telephone: + 352 27 754 497
Hello,
my problems has been solve by studying some source code.
The approval process could benefit from an example with explanations
did you read this:
Easter-eggs Sp�cialiste GNU/Linux
44-46 rue de l’Ouest - 75014 Paris - France - M�tro Gait�
Phone: +33 (0) 1 43 35 00 37 - Fax: +33 (0) 1 43 35 00 76
mailto:elacour@easter-eggs.com - http://www.easter-eggs.com
Hello,
my problems has been solve by studying some source code.
The approval process could benefit from an example with explanations
did you read this:
- docs/customizing/approvals.pod
This doc is available online now at:
http://bestpractical.com/rt/docs/latest/customizing/approvals.html
Hello,
my problems has been solve by studying some source code.
The approval process could benefit from an example with explanations
did you read this:
- docs/customizing/approvals.pod
No.
Yes.
Actually, /usr/share/request-tracker4/lib/RT/Approval/Rule/* was most
insightful on how dependencies and referers work.
Then I came across
RT – Request Tracker | Jeremy Winder,
wich together with the rest explain how to setup arbitrarily complex
approval logic.
Bye,
Joerg