| Commit message (Collapse) | Author | Age | Lines |
|
|
|
| |
Fixes https://github.com/mysociety/alaveteli/issues/1563
|
|
|
|
|
|
|
|
|
| |
Sometimes pdftohtml will generate thousands of images when converting an
image embedded in a PDF. This causes a request spike when a user tries
to view the converted PDF as HTML.
See https://bugs.freedesktop.org/show_bug.cgi?id=77932 for the bug
report.
|
| |
|
|\ |
|
| | |
|
|\ \
| |/
|/| |
|
| |
| |
| |
| | |
Taken from https://github.com/mikel/mail/pull/602
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
TODO: We really should be testing the full output of RTF#body, but we currently
want to remain consistent with Adapters::PDF as many methods are shared between
the Adapters.
A more correct spec might be:
expected = %Q(<font size=3><font color="#000000">thisisthebody</font></font>)
adapter.body.should == expected
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
TODO: We really should be testing the full output of PDF#body, but
inconsistencies between pdftohtml prevent sensible means of doing this.
For example:
adapter.body.should == %Q(\n<A name=1></a>thisisthebody<br/>\n<hr>\n)
Fails because some versions (correctly!) use lower case tag names.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Extracts the attachment processing from FoiAttachment#body_to_html
AttachmentToHTML contains adapters which convert
- text/plain
- application/pdf
- application/rtf
Results are returned as an AttachmentHTML::HTML instance which contains
the raw HTML and other metadata about the conversion.
|
| | |
|
| | |
|
|\ \
| |/
|/|
| | |
'opennewzealand_github/feature/handle-undefined-conversion' into rails-3-develop
|
| | |
|
| | |
|
|\ \
| |/
|/| |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Update our session-stripping code.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a fix for issue #1232. Richard Taylor pointed
out that some PDF attachments had the non-standard content-type
document/pdf, and that these weren't being treated as PDFs.
(Ganesh Sittampalam discovered that all of these PDFs were
generated by a Lexmark X945e, according to the PDF metadata.)
This commit adds an extra case to normalise_content_type to map
document/pdf to application/pdf.
In fact, since the upgrade of the Mail gem in ccebe3c3d6d4dc5f81
the behaviour when handling the non-standard content-type
document/pdf was much better, but this commit also means that
you get the right icon for the attachment, and can be
cherry-picked onto older versions to fix #1232.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
feature/switch-to-asset-pipeline
Conflicts:
Gemfile.lock
app/assets/images/admin-theme/ui-bg_flat_0_aaaaaa_40x100.png
app/assets/images/admin-theme/ui-bg_flat_55_fbf9ee_40x100.png
app/assets/images/admin-theme/ui-bg_flat_65_ffffff_40x100.png
app/assets/images/admin-theme/ui-bg_flat_75_cccccc_40x100.png
app/assets/images/admin-theme/ui-bg_flat_75_dadada_40x100.png
app/assets/images/admin-theme/ui-bg_flat_75_e6e6e6_40x100.png
app/assets/images/admin-theme/ui-bg_flat_75_ffffff_40x100.png
app/assets/images/admin-theme/ui-bg_inset-soft_95_fef1ec_1x100.png
app/assets/images/admin-theme/ui-icons_222222_256x240.png
app/assets/images/admin-theme/ui-icons_2e83ff_256x240.png
app/assets/images/admin-theme/ui-icons_454545_256x240.png
app/assets/images/admin-theme/ui-icons_888888_256x240.png
app/assets/images/admin-theme/ui-icons_cd0a0a_256x240.png
app/assets/javascripts/admin.js
app/assets/javascripts/admin/jquery-ui.min.js
app/assets/javascripts/application.js
app/assets/javascripts/jquery-ui.min.js
app/assets/javascripts/jquery.flot.errorbars.min.js
app/assets/javascripts/jquery.flot.min.js
app/assets/javascripts/stats.js
app/assets/stylesheets/application.css
app/assets/stylesheets/fonts.scss
app/views/general/_stylesheet_includes.html.erb
app/views/layouts/admin.html.erb
app/views/layouts/default.html.erb
app/views/public_body/statistics.html.erb
config/application.rb
config/environments/development.rb
|
| | |
| | |
| | |
| | |
| | | |
The new name value doesn't escape a double quote within single quotes,
which seems more correct.
|
| | | |
|
| |/
|/|
| |
| | |
Update our session-stripping code.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code that extracted the theme name from each entry in THEME_URLS (in
order to require code from a directory whose leaf name is the theme
name) only supported git URLs that ended in '.git'. However, the
themes:install rake task usefully supports a wider range of git URLs -
for example, all of the following were supported:
/home/whoever/themes/blah-theme => blah-theme
/home/whoever/themes/blah-theme/ => blah-theme
git://wherever/blah-theme.git => blah-theme
ssh://wherever/blah-theme.git// => blah-theme
This commit factors out a theme_url_to_theme_name method,
adds tests for it, and uses that method in both:
lib/tasks/themes.rake
config/initializers/theme_loader.rb
... so that a wider range of theme URLs are consistently supported.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The statistics on the status of the requests to a particular
public body are too slow to calculate on-the-fly, so this
commit adds:
* Extra columns on public_bodies to store counts of
the successful, not held, and overdue request counts
for each public body.
* A rake task which should be run periodically to update
the overdue request count column.
If Javascript is not available, the summary statistics are
shown as tables. If Javascript is available, graphs are
drawn with Flot.
|
|\
| |
| |
| |
| |
| | |
Conflicts:
locale/he_IL/app.po
locale/nb_NO/app.po
|
| |
| |
| |
| | |
errors when parsing large mails with envelopes on memory limited systems.
|
|/ |
|
|
|
|
|
|
|
|
|
| |
This use of eval allows arbitrary remote code execution on
parsing of a maliciously formed email.
Two tests are updated to match the behaviour of the new
code to return the display name - these introduce extra
escaping, so should be innocous.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This seems to be the bug mentioned here:
http://po-ru.com/diary/fixing-invalid-utf-8-in-ruby-revisited/
That explains that some versions of Iconv don't ignore
invalid characters when converting to UTF-8 even with
//IGNORE if that invalid character happens to be at the end
of the string. In fact, as Matthew Somerville pointed out,
with some versions of iconv (e.g. 1.14 on Mac OS, apparently)
it's necessary to add and remove more than one space at the end,
in case the first character of the byte sequence indicates a
long sequence. We add and remove 4 to be on the safe side.
|
|
|
|
|
|
|
|
|
|
| |
The behaviour of the TMail backend's 'to' and 'cc' methods
where there was a malformed To: or Cc: line was to return
nil, whereas Mail returns a version of the string anyway.
We'd have to change quite a lot of code to deal with an
extra possible class of returned objects, so it's simplest
for the moment to monkey-patch Mail::Message's 'to' and 'cc'
methods to restore the old behaviour.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Mail gem deals with multipart messages that look as if
they should have 1 part but are missing the final MIME boundary,
by make the parts list empty and setting part.body to the
text of the email. Rather than throwing an exception in this
case, we just pretend that part is text/plain and return it, so
that the page doesn't error and we still have a chance of some
useful text being displayed.
Note that we haven't investigated yet the case of emails that
have more than one start boundary, but no final boundary.
Fixes #921
|
|
|
|
| |
no charset field.
|
|
|
|
|
|
|
| |
These cases are rare, and probably need to be resolved by
reporting issues against the Mail gem (although it's debatable
what the more correct or pragmatic behaviour should be in both
cases).
|
|
|
|
|
| |
At one point in development this email was misparsed, so I've
added this as test to check for regressions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Throughout the codebase it is simplest and most consistent
if we could assume that all text/* attachments are represented
by UTF-8 strings, and this was largely true with the TMail
backend which ensured that all returned text parts were in
UTF-8. We have to change the replacement Mail-backed to
similarly attempt to convert text parts to UTF-8. This commit
introduces two functions which are useful for this.
The normalize_string_to_utf8 function will try various
encodings, either suggested or guessed (with charlock_holmes)
to convert the passed string to UTF-8, and if it can't find a
suitable encoding will throw an exception.
Unfortunately, the current behaviour of the site is that
uninterpretable text/* attachments are still passed around and
mangled to UTF-8 just before display. To mimic this it's also
useful to have the convert_string_to_utf8_or_binary function,
which tries to convert the string to UTF-8 with
normalize_string_to_utf8, but if that's not possible just
returns the original string. (In Ruby 1.9, encoding will be
set to UTF-8 or ASCII-8BIT appropriately.)
|
| |
|
|
|
|
|
|
|
| |
This example email indicates the wrong charset and includes
a top bit set character despite Content-Transfer-Encoding: 7bit
- nonetheless, we should be able to convert it to UTF-8 and
interpret the character correctly.
|
|
|
|
|
|
|
|
|
| |
If there is a missing final MIME boundary, the behaviour
of Alaveteli with the TMail backend was to still parse
the attachment, but with the new code it currently throws
an exception. This commit adds a test that asserts that
the attachment should be parsed despite the email being
malformed in this way.
|
|
|
|
|
|
|
|
|
|
|
| |
There is currently a difference in behaviour in the parsing
of nested MIME multipart attachments between the Mail and
TMail based backends. This commit adds a test that will
pass if the behaviour is the same as the the old (TMail-based)
version, which I believe is correct according to RFC 1521.
The example email has a PNG attachment after the final MIME
boundary, and the RFC says that anything after the final
boundary ("the epilogue") should be ignored.
|