Hi List,
I really need a solution for it. we are using
http://URL/REST/1.0/NoAuth/mail-gateway to create tickets but it is
returning error, not
ok - Could not load a valid user in browser and log having :
[error]: Could not record email: Could not load a valid user
Hi,
You followed this procedures, find in wiki?
http://wiki.bestpractical.com/index.cgi?ItsFinallyInstalledNowWhat
This was solved by granting CreateTicket and ReplyToTicket to the group
Everyone. This is done via Configuration - Queues - (queue name) - Group
Rights in the web interface
That looks suspiciously like the problem I'd been talking to you
about before, Todd.
On Apr 25, 2007, at 11:27 PM, Philip Kime wrote:
I know I asked this before but I've been swamped and lost track of
there the discussion got to.
RT 3.6.3, Mysql 5.0.27. The main ticket search page is
as far as I can see estimation of rows is very wrong I do think it's
mysql bug, I suggest you rebuild all indexes and run analyze on
tables.
On 4/26/07, Jesse Vincent [EMAIL PROTECTED] wrote:
That looks suspiciously like the problem I'd been talking to you about
before, Todd.
On Apr 25, 2007,
On Apr 25, 2007, at 3:03 PM, Vivek Khera wrote:
On Apr 24, 2007, at 8:44 PM, Ham MI-ID, Torsten Brumm wrote:
Yes we had it also, special after on on longer time of pt no pot
usage (?!?) We fixed it dirty by nightly reboots. Later we
switched to mod_fcgid.
We use mod_fcgi but we still
On 4/26/07, Fernando Fugita [EMAIL PROTECTED] wrote:
You followed this procedures, find in wiki?
http://wiki.bestpractical.com/index.cgi?ItsFinallyInstalledNowWhat
Actually I updated RT 3.4.5 to RT 3.6.3. In old RT, everyone didnt
have right to create ticket and it was working fine. After
Jesse Vincent wrote:
On Apr 24, 2007, at 8:12 PM, Justin Zygmont wrote:
I have this strange and unexplainable problem with RT 3.4.6 on RHEL4.
For some reason when using RT for any length of time, I get a
mason_handler process taking up all 2 GB of ram on the server, and
driving the load
Found my problem. Turns out I had an old DBIx::SearchBuilder installed in a
different dir (from an old Perl install), and somehow it was being used
instead of the new one. I deleted the old DBIx, cleaned the Mason cache,
restarted httpd, and all's well now with Reminders.
hope that helps
Hi All,
My RT setup is v3.6.3 with all global scrips disabled. The queue I'm
working in has a scrip that fires when Status eq 'resolved' and the action
is to Notify Requestors with a boilerplate e-mail telling the requestor
that it was resolved and who resolved the ticket.
I have a ticket,
This is an AT question, but it touches RT as well, since the same problem,
how to read links between tickets, exists in RT.
It is a very, very, very easy problem for an expert (at least I think so),
but for a non expert like me it is baffling. I am struggling with it for
some time.
Let us
At Thursday 4/26/2007 03:31 PM, Jason Fenner wrote:
I am trying to iterate over the names of groups with this code piece:
use RT::Groups;
my $groups = new RT::Groups($user);
$groups-LimitToUserDefinedGroups();
print $groups-Count . \n;
while (my $group =
Stephen Turner wrote:
At Thursday 4/26/2007 03:31 PM, Jason Fenner wrote:
I am trying to iterate over the names of groups with this code piece:
use RT::Groups;
my $groups = new RT::Groups($user);
$groups-LimitToUserDefinedGroups();
print $groups-Count . \n;
A couple of questions on custom fields
- I would like to be able to define some help text for custom fields to
give more details. Is there a way of making either a pop-up hover text
or a link when the custom field description is clicked on to give the
users more of a hint of the meaning of
Hi,
I`d like to solve this situation:
A Requestor send an email to one queue.
Two watchers receive the corresponding email.
When one of the watchers answers the email I'd like him to be the owner of
the ticket if he is an AdminCC
what is the AdminCC id?
$self-TicketObj-QueueObj-AdminCc-id
Try
---
my $Ticket = $self-TicketObj;
my $Transaction = $self-TransactionObj;
my $CreatorId = $Transaction-CreatorObj-Id;
my $Queue = $Ticket-QueueObj;
my $val = $Transaction-Type eq 'Correspond' $Queue-IsAdminCc($CreatorId);
$Ticket-SetOwner($CreatorId) if $val;
return 1;
Thank you!
But, as I understand, this makes the requestor=creator to be the owner, do
it?
I´d like the first watcher who answers the email to be the owner...
thanks for answering!!!
Try
---
my $Ticket = $self-TicketObj;
my $Transaction = $self-TransactionObj;
my
The problem seems to be caused by the ORDER BY clause. If I remove this,
it's very fast.
PK
From: Jesse Vincent [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 26, 2007 6:00 AM
To: Todd Chapman
Cc: Philip Kime; RT Users
Subject: Re: [rt-users] Slow ticket
All,
I'm having some LDAP woes with RT. I've followed the instructions from
- New Installs - This is a new installation of rt-3.6.3
Here are the instructions I've followed:
Installation is very straightforward if you haven't installed any
previous LDAP auth/info implementations and don't
here is the test to see if there isn't an owner and if the current actor
is an adminCC.
# if the owner isn't Nobody don't worry about it.
return 0 unless ($self-TicketObj-OwnerObj-Name eq Nobody);
# load the current user as a principal
my $actor = RT::Principal-new( $RT::SystemUser );
I could have it wrong, but it is working for me. Here's how I understand it:
When the e-mail comes in, $self-TransactionObj-CreatorObj-Id is the user
id of the e-mail sender (because the sender's e-mail created the
transaction).
my $CreatorId = $self-TransactionObj-CreatorObj-Id;
$val =
Ok, the issue is that MYSQL 5 won't use the index on main.Name by
default (possible keys list PRIMARY only, which is useless for this
ORDER BY clause), which it really needs to do with an ORDER BY clause
for main.Name (or main.RealName as in my example as I have modified the
display code). It is
Philip, please try the following query and send us times and EXPLAIN:
SELECT STRAIGHT_JOIN DISTINCT main.* FROM
ACL ACL_4,
Groups Groups_3,
CachedGroupMembers CachedGroupMembers_2,
Principals Principals_1,
Users main
WHERE ((ACL_4.PrincipalType = Groups_3.Type))
AND
You're clearly a better DBA than me :-) Yes, that Join orering is very
nice and executes in about 0.8 seconds as opposed to 45-90 seconds.
Explain is:
*** 1. row ***
id: 1
select_type: SIMPLE
table: ACL_4
type: range
23 matches
Mail list logo
