Have you tried something like this:
rt-shredder --plugin 'Attachments=limit,1000;files_only,1;file,smime.p7s'
That should delete only attachments with the name you mentioned, and will
limit it to 1000 attachments which you can adjust.
On Tue, Jul 28, 2015 at 8:52 AM, Zoey Schutt
Hello everyone,
I just upgraded from 4.0.6 to 4.2.3 using the Debian packages. During the
database upgrade, I received a few errors:
Processing 4.1.1
Now populating database schema.
[12453] [Wed May 21 03:19:36 2014] [critical]: DBD::Pg::st execute failed:
ERROR: cannot drop sequence
On Wed, May 21, 2014 at 1:22 PM, Kevin Falcone falc...@bestpractical.comwrote:
On Wed, May 21, 2014 at 11:33:20AM -0400, Nathan Baker wrote:
Hello everyone,
I just upgraded from 4.0.6 to 4.2.3 using the Debian packages. During
the
database upgrade, I received a few errors:
I'm
to leave it and consider it to be normal/clean.
Thanks,
Nate
On Wed, May 21, 2014 at 4:23 PM, Nathan Baker bak...@gmail.com wrote:
On Wed, May 21, 2014 at 1:22 PM, Kevin Falcone
falc...@bestpractical.comwrote:
On Wed, May 21, 2014 at 11:33:20AM -0400, Nathan Baker wrote:
Hello everyone,
I
://perl.apache.org/docs/1.0/guide/debug.html
http://perl.apache.org/docs/2.0/user/troubleshooting/troubleshooting.html
-Nate
On Wed, Jan 15, 2014 at 11:21 AM, Kevin Falcone
falc...@bestpractical.comwrote:
On Tue, Jan 14, 2014 at 01:43:59PM -0500, Nathan Baker wrote:
(gracefully finishing). Those
Hello everyone,
I currently have an instance of RT 4.0.17 running that we're using for
processing incoming faxes. The faxes come in as attachments, and I have
some customizations to allow our staff to process these attachments (PDFs)
faster.
Everything seems to work great for a while, and the
Tom,
We got rid of the On Correspond Open Tickets Scrip to avoid tickets being
reopened because of those type of responses. Is that an option for you, or
would you like your tickets to re-open?
-Nate
On Fri, Jan 10, 2014 at 1:33 PM, Tom Leslein tlesl...@arsalon.net wrote:
I am trying to
Hello Everyone,
We recently noticed that if you change the subject of a ticket while you
are resolving it, the change does not take effect. I've noticed this for
RT 4.0.6 and 4.0.17, although I haven't been able to try it on 4.2.x yet.
Can anyone confirm if this is a bug or if it's something
That makes sense. I might try to create a Scrip to update the ticket
subject, since it would be very convenient for this particular application.
Thanks!
On Thu, Jan 9, 2014 at 4:16 PM, Tim Wiley t...@marchex.com wrote:
On 01/09/2014 01:10 PM, Nathan Baker wrote:
Hello Everyone,
We
Ruslan,
I agree with your recommendation in general for most installations,
especially ones larger than ours. I don't think increasing the
KeepAliveTimeout is necessary anymore now that I fixed the swapping issue,
because the initial page load does not take a long time anymore. However,
for our
Thanks Kenn, I checked and didn't see any permissions globally set for
everyone, except the Create Ticket right is set for Everyone on each of our
queues.
I made a few more changes though and am considering the problem fixed at
this point. I found that the system was doing a lot of memory
I'm going to try and separate this thread since my issue doesn't seem to be
related to the Search page or the SelectOwner field. Using the Mason
Profiler did give me some info though, it looks like it might be due to
some custom fields:
=Mason= localhost -
/Ticket/Elements/ShowCustomFields {{{
, 2012 at 11:37 AM, Ruslan Zakirov r...@bestpractical.comwrote:
On Wed, May 30, 2012 at 6:37 PM, Nathan Baker bak...@gmail.com wrote:
I'm going to try and separate this thread since my issue doesn't seem to
be
related to the Search page or the SelectOwner field. Using the Mason
Profiler did
, 2012 at 12:09 PM, Ruslan Zakirov r...@bestpractical.comwrote:
On Wed, May 30, 2012 at 7:53 PM, Nathan Baker bak...@gmail.com wrote:
Ruslan,
I actually started the other thread, so my details are in the first post.
That thread was sort of hijacked (no big deal) and getting messy, so I
at 10:15 PM, Nathan Baker bak...@gmail.com wrote:
Ruslan,
I wasn't aware that sessions had to be cleared, but now that you
mentioned
it I looked and there were almost 10k sessions in our table. I cleared
that
out and it does not seem to be slow in that section anymore. I've also
Okay...just an update. This is definitely directly tied to the Apache
KeepAliveTimeout setting. The default was 15 seconds for my installation,
and if I change it to 10 seconds or 60 seconds that is exactly how long of
a wait is required to make it slow again.
So from here it looks like the
Hello Everyone,
We've upgraded from RT 3.8.8 with MySQL to RT 4.0.5 (debian package) with
Postgresql, and are having some performance issues with the web interface.
I've searched the list archives and Google, and haven't been able to find
the issue. I'm hoping someone can help point me in the
at 12:32 AM, Nathan Baker bak...@gmail.com wrote:
Hello Everyone,
We've upgraded from RT 3.8.8 with MySQL to RT 4.0.5 (debian package) with
Postgresql, and are having some performance issues with the web
interface.
I've searched the list archives and Google, and haven't been able to
find
18 matches
Mail list logo
