Re: [rt-users] RT Content-Type default to text/html
On Mon, Mar 21, 2011 at 12:29:11PM -0400, Narayanaswamy, Nagaraj wrote: >Based on setting the content-type to text/html, looks like RT would send > it as multi-part >message with both text and HTML as attachments. It sends as multipart/alternative so your MUA chooses which one to display. RT doesn't support sending HTML only email. You should provide more specifics about what your templates look like, sample RT email, your RT version, more information about how Outlook mishandles it, etc etc. -kevin > > > [1]https://github.com/bestpractical/rt/blob/rt-3.8.7/docs/templates.pod#Special_Headers > > > >I was wondering if there is a way to always have the default email as > HTML, and does not go >out as multi-part email. Basically the email can be viewed directly in > Outlook and other email >clients supporting HTML rather than asking users to open attachments > explicitly. pgpdhNPNwUUSG.pgp Description: PGP signature
[rt-users] RT Content-Type default to text/html
Hello, Based on setting the content-type to text/html, looks like RT would send it as multi-part message with both text and HTML as attachments. https://github.com/bestpractical/rt/blob/rt-3.8.7/docs/templates.pod#Special_Headers I was wondering if there is a way to always have the default email as HTML, and does not go out as multi-part email. Basically the email can be viewed directly in Outlook and other email clients supporting HTML rather than asking users to open attachments explicitly. Thanks,
Re: [rt-users] CF appears after update even without SeeCustomField rights
On 2/9/2011 2:46 PM, David Good wrote: > On 2/9/2011 8:29 AM, Kevin Falcone wrote: >> On Tue, Feb 08, 2011 at 10:31:25AM -0800, David Good wrote: >>> I've found an issue in two separate 3.8.8 installations. Both have one >>> or more CustomFields that are not supposed to be visible to most users. >>> The CF is managed entirely by Scrips to contain extra information not >>> needed by users. In one installation, it contains the Cost Center of >>> the Requestor. In the other, there's a flag used to enable suppression >>> of notifications when a ticket is resolved and another flag used to mark >>> a ticket as 'urgent'. >>> >>> When using the web interface (i.e. via the 'Basics' or 'Jumbo' tab), the >>> CF doesn't appear intially but after an update is made to any item and >>> saved, the CustomField appear. >> David >> >> I'd be interested to know if you can reproduce this on a test box >> running the 3.8.9 release candidate >> >> -kevin > I don't have a test box handy, but I'll see if I can get one setup. > I finally was able to upgrade one of the affected instances to 3.8.9 and can confirm that my problem has been fixed.
Re: [rt-users] Some advice on initial config
Okay, that makes sense. So I thought a different approach might be in order. Instead of having ExtertnalAuth create the privileged RT support users I'd have it create and authenticate all users as none unprivileged and manually set the support users to the correct group. The first problem I've encountered is that ExternalAuth doesn't seem to recognise the 'Domain Users' group in AD. It works fine if I explicitly add the user to the 'RT User' users group I set up from the wiki howto doc but not if I either set the 'Domain Users' group in the ExternalAuth RT_SiteConfig.pm or if I add it as a member of the 'RT Users' group. Anybody know why that might be as adding them individually to 'RT User' will be a pain. Thx for any feedback. -np -- Tradar Limited is a limited company registered in England and Wales. Registered number: 3431380. Registered office: 11 Conway Street, London. W1T 6BL -Original Message- From: rt-users-boun...@lists.bestpractical.com [mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Thomas Sibley Sent: 18 March 2011 16:48 To: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Some advice on initial config On 18 Mar 2011 12:31, Nick Porter wrote: > > > Hello. I've been Googling and wiki reading and following the sterling advice > of others but I have to admit I'm stuck and could do with some help. > > I'm on Debain Squeeze, Apache2 and RT3.8 with MySQL > > I've got it the web interface up and even managed to get emails to flow from > our exchange server into the general queue so I have the basics. > > My problem is with the users. I've managed to get the ExternalAuth plugin to > talk to AD/ldap and create privileged user but I'm having problem setting RT > up so that the folks submitting emails/tickets to it can log in and see the > queue and theirs/others tickets. > > An email will arrive and create a ticket and create a user with *NOPASSWORD* > but for the life of me I can't seem to be able to login with that user. Even > is if users has the 'Let this user acess RT' check set. These are internal unprivileged users that aren't authenticating through ExternalAuth and you've configured external auth to fall through to internal users? If so, they need a password to login. Thomas > Any pointers as to what I should be looking for or what common pitfall I'm > encountering? > > Thx. > -- > np > > > > > -- > Tradar Limited is a limited company registered in England and Wales. > Registered number: 3431380. > Registered office: 11 Conway Street, London. W1T 6BL > >
Re: [rt-users] apache 100% cpu usage
I tried to examine your idea about big search. I did some of them (i.e. 128000 results) but httpd process only peaked (still not 100%) and in a few seconds get back to the normal state. It seems search with large result could not be the exact source if this problem Best Regards From: rt-users-boun...@lists.bestpractical.com [mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Payam Poursaied Sent: Sunday, March 20, 2011 8:55 PM To: 'Ruslan Zakirov' Cc: rt-users@lists.bestpractical.com Subject: Re: [rt-users] apache 100% cpu usage Hi Ruslan Thank you for your response. There isn’t any end! Even after a week! All modules are updated to the latest available port in FreeBSD You gave me a good point to check, but still I am curious to know how such problems could be debugged. Do you have any idea on this issue ? Best Regards From: Ruslan Zakirov [mailto:ruslan.zaki...@gmail.com] Sent: Sunday, March 20, 2011 7:39 PM To: Payam Poursaied Cc: rt-users@lists.bestpractical.com Subject: Re: [rt-users] apache 100% cpu usage I see storable perl module there, so it's sessions handling. Look at updates for the module. Try to wait to see if it ends. If it ends then may be It's result of a big search that stored in the session. Newer versions of RT don't store big search results in sessions, only limited amount of records. Check sessions table for big records. Regards, Ruslan. From phone. 20.03.2011 11:19 пользователь "Payam Poursaied" написал: > > Hi all > We are using rt3.8.8 and we faced with a problem using apache 1.3.42 on > FreeBSD 8.0-RELEASE. > The problem is that httpd processes frequently reach 100% CPU usage and stay > at this level of CPU usage. > This is a sample of top output. > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 77051 www 1 118 0 208M 86080K CPU4 4 87.6H 100.00% httpd > 9403 www 1 118 0 215M 93340K CPU2 2 65.0H 100.00% httpd > 78430 www 1 118 0 226M 100M CPU0 0 58:57 100.00% httpd > 95332 www 1 50 0 205M 83624K sbwait 12 0:02 4.49% httpd > 89664 www 1 46 0 210M 88144K sbwait 11 0:05 2.59% httpd > 95331 www 1 46 0 205M 83464K sbwait 12 0:01 1.66% httpd > > I think there might be a bug that caused something like endless loop but I > am newbie to gdb and debugging and I could not find any relevant point to > get into it. > I tried to compile apache in debug mode and then wait to see a suspicious > process and then attached GDB66 to that cpu intensive httpd process to find > out what is going on. > But I could not go further more. > > I have also consulted with apache-freebsd mailing list but there wasn't any > success. > > Could anyone help me to drill down this problem? > > Best Regards > Payam Poursaied > > Using "next" says: > (gdb) next > Cannot find bounds of current function > And here below is output of "where" command in gdb66. > (gdb) where > #0 0x00080093a73b in ?? () from /lib/libc.so.7 > #1 0x00080093d505 in ?? () from /lib/libc.so.7 > #2 0x0008009401bc in ?? () from /lib/libc.so.7 > #3 0x000800942ec4 in malloc () from /lib/libc.so.7 > #4 0x000803079946 in Perl_safesysmalloc () from > /usr/local/lib/perl5/5.10.1/mach/CORE/libperl.so > #5 0x00080308cee0 in Perl_av_extend () from > /usr/local/lib/perl5/5.10.1/mach/CORE/libperl.so > #6 0x00080308dabe in Perl_av_store () from > /usr/local/lib/perl5/5.10.1/mach/CORE/libperl.so > #7 0x00080750de53 in retrieve_byte () from > /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Storable/Storable.so > #8 0x00080750c66b in retrieve () from > /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Storable/Storable.so > #9 0x0008075113b8 in retrieve_hash () from > /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Storable/Storable.so > #10 0x00080750c66b in retrieve () from > /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Storable/Storable.so > #11 0x00080750ce29 in retrieve_ref () from > /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Storable/Storable.so > #12 0x00080750c66b in retrieve () from > /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Storable/Storable.so > #13 0x0008075113b8 in retrieve_hash () from > /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Storable/Storable.so > #14 0x00080750c66b in retrieve () from > /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Storable/Storable.so > #15 0x00080751298c in retrieve_blessed () from > /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Storable/Storable.so > #16 0x00080750c66b in retrieve () from > /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Storable/Storable.so > #17 0x00080750ce29 in retrieve_ref () from > /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Storable/Storable.so > #18 0x00080750c66b in retrieve () from > /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Storable/Storable.so > #19 0x0008075113b8 in retrieve_hash () from > /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Storable/Storable.so > #20 0x00080750c66b i