Re: [rt-users] RT (4.0.18) search engine is leaking informations about unallowed tickets
Oh yes thanks. 2013/12/13 Kevin Falcone falc...@bestpractical.com On Fri, Dec 13, 2013 at 04:06:20PM +0100, benoit plessis wrote: I'm experiencing something weird with the latest 4.0.xx release, when some low privileges users search for tickets RT give away of unwanted informations. Example: the default dashboard search for unowned tickets display 70 tickets found in the title part, include a two-pages navigation, but only display 1 ticket, the only one the user is allowed to see. This also break the dashboard view, since the first ten tickets aren't accessible the view is empty. I'm not sure if it's a recent change or not since up to now all of our users had at least readonly access to all of the queues/tickets. http://bestpractical.com/docs/rt/latest/RT_Config.html#UseSQLForACLChecks Off on 4.0, on on 4.2. You sound like you want to turn it on. -kevin
[rt-users] RT (4.0.18) search engine is leaking informations about unallowed tickets
Hi, I'm experiencing something weird with the latest 4.0.xx release, when some low privileges users search for tickets RT give away of unwanted informations. Example: the default dashboard search for unowned tickets display 70 tickets found in the title part, include a two-pages navigation, but only display 1 ticket, the only one the user is allowed to see. This also break the dashboard view, since the first ten tickets aren't accessible the view is empty. I'm not sure if it's a recent change or not since up to now all of our users had at least readonly access to all of the queues/tickets. Is it a known problem ? Regards, benoit
[rt-users] Text Attachements within HTML mails
Hi,
We are experiencing some inconvenient with RT 3.8.8 and text attachements.
When a text only mail containing a text/plain attachment is replied
upon everything is fine and the attachment is not shown
in the reply message box, however, for text/html message the first
attached text/plain file is used, instead of the inlined text/plain
which is quite problematic when there is an 1Mb attached text file =
FF hang during a long time :(
Also there is a small patch so that big text attachements, marked as
attachemnt are not marked as
not shown because too large but as not shown because not inlined:
--- Ticket/Elements/ShowTransactionAttachments.org 2010-11-04
12:18:01.141242000 +0100
+++ Ticket/Elements/ShowTransactionAttachments 2010-11-04
12:18:16.057536000 +0100
@@ -154,7 +154,11 @@
# If it's text
if ( $message-ContentType =~ m{^(text|message)}i ) {
my $max_size = RT-Config-Get( 'MaxInlineBody',
$session{'CurrentUser'} );
-if ( $message-Filename
RT-Config-Get('SuppressInlineTextFiles', $session{'CurrentUser'} ) )
{
+if ( $disposition ne 'inline' ) {
+$m-out('p'. loc( 'Message body is not shown because
sender requested not to inline it.' ) .'/p');
+return;
+}
+elsif ( $message-Filename
RT-Config-Get('SuppressInlineTextFiles', $session{'CurrentUser'} ) )
{
$m-out('p'. loc( 'Text file is not shown because it is
disabled in preferences.' ) .'/p');
return;
}
@@ -162,10 +166,6 @@
$m-out('p'. loc( 'Message body not shown because it is
too large.' ) .'/p');
return;
}
-elsif ( $disposition ne 'inline' ) {
-$m-out('p'. loc( 'Message body is not shown because
sender requested not to inline it.' ) .'/p');
-return;
-}
if (
Re: [rt-users] Text Attachements within HTML mails
2010/11/4 benoit plessis plessis.ben...@gmail.com:
Hi,
We are experiencing some inconvenient with RT 3.8.8 and text attachements.
When a text only mail containing a text/plain attachment is replied
upon everything is fine and the attachment is not shown
in the reply message box, however, for text/html message the first
attached text/plain file is used, instead of the inlined text/plain
which is quite problematic when there is an 1Mb attached text file =
FF hang during a long time :(
Here is my current fix for this:
--- lib/RT/Transaction_Overlay.pm 2010-11-04 13:07:40.254934000 +0100
+++ local/lib/RT/Transaction_Overlay.pm 2010-11-04 13:02:06.572761000 +0100
@@ -415,6 +415,15 @@
elsif ( $Attachment-ContentType =~ '^multipart/' ) {
my $plain_parts = $Attachment-Children;
$plain_parts-ContentType( VALUE = $args{Type} );
+
+ my %args = (
+ VALUE = 'NULL',
+ OPERATOR= 'IS',
+ ENTRYAGGREGATOR = 'AND',
+ @_
+ );
+
+ $plain_parts-Limit ( %args, FIELD = 'Filename' );
$plain_parts-LimitNotEmpty;
# If we actully found a part, return its content
[rt-users] Setting up the FCKeditor
Two questions from my users: 1/ Is it possible to disable the context menu in the FCKEditor ? normally i just need to set fckconfig.browsercontextmenu to true but changing the fckconfig.js file doesn't seem to have any result 2/ Is it possible/will it be possible to inline images in the content block ? They were used to describe problems resolution using step by step screen capture like that: Here is the screenshot for this step: image1 And then you do that: image2 RT Training in Washington DC, USA on Oct 25 26 2010 Last one this year -- Learn how to get the most out of RT!
[rt-users] Attaching objects from RTFM article
Hi, Say you have a FAQ entry with a pdf file attached, would it be possible that the include of the rtfm article in the reply also include the pdf file, and not only his name ? regards RT Training in Washington DC, USA on Oct 25 26 2010 Last one this year -- Learn how to get the most out of RT!
Re: [rt-users] ACL Troubles with RTFM
2010/8/9 Kevin Falcone falc...@bestpractical.com: On Sat, Aug 07, 2010 at 01:10:27PM +0200, benoit plessis wrote: What happens if you go to Configuration - Custom Fields - custom field name - Group Rights? In this case, it's also working Have you applied the CF to the Classes (using the Applies To link from the Custom Field page)? Yes indeed, this was the way i used There were some bugs with that in 2.4.2 and 3.8.8, so if you haven't done that you may need to test out the 2.4.3rc1 release on Friday. So i'm screwed ? Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] ACL Troubles with RTFM
Hi, I'm trying to setup RTFM acl's for some groups and it seem that they are not enough. For example, in Config RTFM Global Group Rights i allow the following to a group of users: CreateArticle DeleteArticle ModifyArticle ModifyArticleTopics ModifyCustomField SeeClass SeeCustomField ShowArticle ShowArticleHistory However, even after login/logout, thoses users doesn't have access to the articles customfields, If then i had SeeCustomField to this group in the global RT configuration (Configuration Global Group Rights) then they are able to see and use articles contents, but not modify (need global ModifyCustomField for this to work). Is it normal ? Using RT 3.8.8 RTFM 2.4.2 Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Encoding Troubles with RT 3.8.8
To solve this one, for now i've done the following modification, since we are sending the modified headers, i changed the RT::Attachment_Overlay::ContentAsMIME to send the modified content: --- /opt/rt3/lib/RT/Attachment_Overlay.pm 2010-06-03 12:55:03.540297000 +0200 +++ /opt/rt3/local/lib/RT/Attachment_Overlay.pm 2010-08-07 13:57:47.411918000 +0200 @@ -426,7 +426,7 @@ use MIME::Body; $entity-bodyhandle( - MIME::Body::Scalar-new( $self-OriginalContent ) + MIME::Body::Scalar-new( $self-Content ) ); return $entity; Any advice ? 2010/8/4 benoit plessis plessis.ben...@gmail.com Hi, I've some problems with iso-8859-1/utf8 encoding of outbound mail with RT. Exemple: Email received in 'iso-8859-1', is correctly displayed in UTF-8 within RT, when showing 'Full Header' we have on top: content-type: text/plain; charset=utf-8 and on bottom: X-RT-Original-Encoding: ISO-8859-1 If we forward this email to a new address, the forwarded message include the same headers, however the message body is in quoted printable encoding of a iso-8859-1 message: ==Extract of forwarded email: == This is a forward of ticket #260 =_1280925536-13250-3 Content-Type: message/rfc822 Content-Disposition: attachment Content-Transfer-Encoding: binary Content-Description: forwarded message Content-Type: multipart/mixed; boundary=--=_1280925536-13250-2 Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.427 (Entity 5.427) This is a multi-part message in MIME format... =_1280925536-13250-2 MIME-Version: 1.0 X-RT-Queue: Support Content-Type: text/plain; charset=utf-8 X-RT-Original-Encoding: ISO-8859-1 Content-Length: 1116 Bonjour, Je fais suite =E0 notre entretien t=E9l=E9phonique. ==Extract of forwarded email: = Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] Encoding Troubles with RT 3.8.8
Hi,
I've some problems with iso-8859-1/utf8 encoding of outbound mail with RT.
Exemple: Email received in 'iso-8859-1', is correctly displayed in
UTF-8 within RT,
when showing 'Full Header' we have on top:
content-type: text/plain; charset=utf-8
and on bottom:
X-RT-Original-Encoding: ISO-8859-1
If we forward this email to a new address, the forwarded message
include the same headers, however the message body is in quoted
printable encoding of a iso-8859-1 message:
==Extract of forwarded email: ==
This is a forward of ticket #260
=_1280925536-13250-3
Content-Type: message/rfc822
Content-Disposition: attachment
Content-Transfer-Encoding: binary
Content-Description: forwarded message
Content-Type: multipart/mixed; boundary=--=_1280925536-13250-2
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
This is a multi-part message in MIME format...
=_1280925536-13250-2
MIME-Version: 1.0
X-RT-Queue: Support
Content-Type: text/plain; charset=utf-8
X-RT-Original-Encoding: ISO-8859-1
Content-Length: 1116
Bonjour,
Je fais suite =E0 notre entretien t=E9l=E9phonique.
==Extract of forwarded email: ==
Also, there is a similar problem when using html mail/template,
accentuated chars are converted to iso-8859-1 chars for the
text/plain version of the mail with is send with an utf8 headers.
The text/html part contain the html-entity codes so there is no problem.
When not using html templates entities are correctly converted using
utf8 charset.
For this part, in _DowngradeFromHTML there is two thing:
* forced 'utf8' mime charset, why not using EmailOutputEncoding
* use of HTML::FormatText which can only generate latin1 text
my $charset = RT-Config-Get('EmailOutputEncoding');
my $new_entity = $orig_entity-dup; # this will fail badly if we go
away from InCore parsing
$new_entity-head-mime_attr( Content-Type = 'text/plain' );
$new_entity-head-mime_attr( Content-Type.charset = $charset );
$orig_entity-head-mime_attr( Content-Type = 'text/html' );
$orig_entity-head-mime_attr( Content-Type.charset = $charset );
$orig_entity-make_multipart('alternative', Force = 1);
require HTML::FormatText;
require HTML::TreeBuilder;
require Encode;
my $tree = HTML::TreeBuilder-new_from_content(
$new_entity-bodyhandle-as_string
);
$new_entity-bodyhandle(MIME::Body::InCore-new(
\(
Encode::encode($charset,
Encode::decode(iso-8859-1,
scalar HTML::FormatText-new(
leftmargin = 0,
rightmargin = 78,
)-format( $tree )
)
)
)
);
$tree-delete;
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
[rt-users] Encoding Troubles with RT 3.8.8
Hi, I've some problems with iso-8859-1/utf8 encoding of outbound mail with RT. Exemple: Email received in 'iso-8859-1', is correctly displayed in UTF-8 within RT, when showing 'Full Header' we have on top: content-type: text/plain; charset=utf-8 and on bottom: X-RT-Original-Encoding: ISO-8859-1 If we forward this email to a new address, the forwarded message include the same headers, however the message body is in quoted printable encoding of a iso-8859-1 message: ==Extract of forwarded email: == This is a forward of ticket #260 =_1280925536-13250-3 Content-Type: message/rfc822 Content-Disposition: attachment Content-Transfer-Encoding: binary Content-Description: forwarded message Content-Type: multipart/mixed; boundary=--=_1280925536-13250-2 Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.427 (Entity 5.427) This is a multi-part message in MIME format... =_1280925536-13250-2 MIME-Version: 1.0 X-RT-Queue: Support Content-Type: text/plain; charset=utf-8 X-RT-Original-Encoding: ISO-8859-1 Content-Length: 1116 Bonjour, Je fais suite =E0 notre entretien t=E9l=E9phonique. ==Extract of forwarded email: == Also, there is a similar problem when using html mail/template, accentuated chars are converted to iso-8859-1 chars for the text/plain version of the mail with is send with an utf8 headers. The text/html part contain the html-entity codes so there is no problem. When not using html templates entities are correctly converted using utf8 charset. Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Encoding Troubles with RT 3.8.8
2010/8/4 benoit plessis plessis.ben...@gmail.com:
Hi,
I've some problems with iso-8859-1/utf8 encoding of outbound mail with RT.
.
Also, there is a similar problem when using html mail/template,
accentuated chars are converted to iso-8859-1 chars for the
text/plain version of the mail with is send with an utf8 headers.
The text/html part contain the html-entity codes so there is no problem.
When not using html templates entities are correctly converted using
utf8 charset.
For this part, in _DowngradeFromHTML there is two thing:
* forced 'utf8' mime charset, why not using EmailOutputEncoding
* use of HTML::FormatText which can only generate latin1 text
my $charset = RT-Config-Get('EmailOutputEncoding');
my $new_entity = $orig_entity-dup; # this will fail badly if we
go away from InCore parsing
$new_entity-head-mime_attr( Content-Type = 'text/plain' );
$new_entity-head-mime_attr( Content-Type.charset = $charset );
$orig_entity-head-mime_attr( Content-Type = 'text/html' );
$orig_entity-head-mime_attr( Content-Type.charset = $charset );
$orig_entity-make_multipart('alternative', Force = 1);
require HTML::FormatText;
require HTML::TreeBuilder;
require Encode;
my $tree = HTML::TreeBuilder-new_from_content(
$new_entity-bodyhandle-as_string
);
$new_entity-bodyhandle(MIME::Body::InCore-new(
\(
Encode::from_to(scalar HTML::FormatText-new(
leftmargin = 0,
rightmargin = 78,
)-format( $tree ),
'iso-8859-1' = $charset
)
)
));
$tree-delete;
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
