We ran for many years on a copy of RT 3.6.5 and I had a procedure that I could
run through whenever I needed to add a new user, group and queue to the system.
Around 10 months ago, we bumped to the 4.0 series and everything seemed to go
OK. Now - for the first time in this new installation - I
Is possible to steal a ticket using the API REST?
I’m writing a java program for reassign ticket.
I have no problem to change owner (with api rest) of tickets owned by ‘nobody’
or by me, but for tickets owned by other user different to me, i must steal it
first before reassing them to other
On Thu, Oct 10, 2013 at 08:52:33AM +0200, Sakhi Hadebe wrote:
I had some issues with upgrade and decided to reverse everything as it is a
production system.
What is not clear is that: Should I download the rt4.0.17 package and its
dependencies and install it manually?
Please keep
Yeah...a co-worker of mine got it working. Sorry, I can't be more clear on
what he did. He said it was a mixture of your suggestions and some other
things. Apache configurations are above my head...
But it's working now!
--
Max McGrath
Network Administrator
Carthage College
262-552-5512
On 10/9/13 11:48 PM, Jaye Mathisen wrote:
I had a nice install of 4.0.17 working and we decided to upgrade to 4.2
before deployment. 99.9% of things are working great.
Except for this:
[62873] [Thu Oct 10 03:30:02 2013] [info]: Repeating ticket 1
(/opt/rt4/sbin/rt-repeat-ticket:38)
[62873]
I have converted my scripts to use the queue number instead of the queue name
and this makes life much better as some of my end users insist on adjusting the
queue names from time to time.
Below is a copy of a template I have that works great but requires the queue
name, or at least I have not
Usually I do this by creating dedicated user for rest clients and adjusting
it's rights in RT.
Milan.
On 10.10.2013, at 11:54, andrea bessi bessi.and...@hotmail.it wrote:
Is possible to steal a ticket using the API REST?
I’m writing a java program for reassign ticket.
I have no problem to
Seems to be working fine.
Many Thanks.
J.
On 10/10/2013 8:23 AM, Jim Brandt wrote:
On 10/9/13 11:48 PM, Jaye Mathisen wrote:
I had a nice install of 4.0.17 working and we decided to upgrade to 4.2
before deployment. 99.9% of things are working great.
Except for this:
[62873] [Thu Oct 10