| Commit message (Collapse) | Author | Age | Lines |
| |
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
If someone reports an external request as needing administrator
attention, we should email the administrators about it.
Thanks for spotting this, @crowbot.
|
|/
|
|
| |
param of 1. Fixes #557.
|
|
|
|
| |
Closes #554.
|
| |
|
|
|
|
|
|
|
|
|
| |
Also make the InfoRequest#is_old_unclassified? method a little
more conservative, by returning false only is the is_external?
method returns true. This makes it subtly inconsistent with
InfoRequest.find_old_unclassified, but it is better I think to
be subtly inconsistent than to risk breaking things that used
to work.
|
|
|
|
|
| |
We certainly do not want to send reminder emails for such requests,
for example, since we do not know the email address to send them to.
|
|
|
|
|
|
|
| |
Therefore we ought not to display the warning “This message has not
yet been sent for an unknown reason” for such requests.
Closes #548.
|
|
|
|
| |
We do not send messages for external requests. See #548.
|
|\
| |
| |
| |
| |
| |
| | |
Conflicts:
app/controllers/admin_request_controller.rb
config/httpd.conf
spec/models/info_request_spec.rb
|
| |
| |
| |
| | |
visible to everyone, so can be served up from a file cache without authentication.
|
| | |
|
| | |
|
| |
| |
| |
| | |
cache the associated objects for an info request in the file cache which will be served up without authentication.
|
| |
| |
| |
| |
| |
| |
| |
| | |
We have a PDF document that appears to send pdftohtml into a loop
where it creates millions of tiny PDF files and consumes ever-increasing
amounts of memory.
(This document: http://www.whatdotheyknow.com/request/119267/response/296719/attach/5/Document%203.pdf)
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
locale/bs/app.po
locale/ca/app.po
locale/cs/app.po
locale/cy/app.po
locale/de/app.po
locale/es/app.po
locale/eu/app.po
locale/fr/app.po
locale/gl/app.po
locale/hu_HU/app.po
locale/id/app.po
locale/pt_BR/app.po
locale/sq/app.po
locale/sr@latin/app.po
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
should never have been pushed in the first place. Sorry!
Revert "Revert "Revert "In the API, when parsing posted responses, assume all multipart mail parts that are Tempfiles are attachments"""
This reverts commit 49ff1a1c0304cd292d3eae80dc0b91b2f83727b9.
|
| | |
| | |
| | |
| | |
| | |
| | | |
all multipart mail parts that are Tempfiles are attachments"""
This reverts commit 49ff1a1c0304cd292d3eae80dc0b91b2f83727b9.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We have a PDF document that appears to send pdftohtml into a loop
where it creates millions of tiny PDF files and consumes ever-increasing
amounts of memory.
(This document: http://www.whatdotheyknow.com/request/119267/response/296719/attach/5/Document%203.pdf)
|
| | |
| | |
| | |
| | |
| | |
| | | |
I think this whole thing is redundant anyway, since the locale is
set at the start of each request, but if we’re going to save/restore
this value then we might as well do so correctly.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The locale was not being set correctly for error pages, causing
some order-dependent test failures, e.g.:
script/spec spec/controllers/services_controller_spec.rb spec/integration/errors_spec.rb
was failing.
Many many many thanks to Louise Crow for tracking this one down!
|
| |
| |
| |
| |
| |
| | |
multipart mail parts that are Tempfiles are attachments""
This reverts commit d4a700da1760fc2ba09cf19613a995569e4965ea.
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
parts that are Tempfiles are attachments"
This change makes the tests fail, I think, and doesn’t have
(IMHO) a desperately strong rationale, so let’s try it without
for now.
This reverts commit 4490482cedf362390b25efe453232ac1b7dfce99.
|
| | |
| | |
| | |
| | | |
that are Tempfiles are attachments
|
| | | |
|
| | |
| | |
| | |
| | | |
something, even when there are no errors.
|
| | |
| | |
| | |
| | | |
"external request" changes (mainly that InfoRequests no longer necessarily have a User).
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
problem testing template results
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
doesn't have a PublicBody at the time its slug is being calculated.
|
| | |
| | |
| | |
| | | |
(including from themes). Fixes #524
|
| | |
| | |
| | |
| | | |
overriding in themes). Fixes #523
|
| |/
|/|
| |
| | |
CensorRules that aren't attached to a User or Request or Public Body (but don't expose this in the admin UI). Fixes #33
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We need not only new requests, but new outgoing correspondence
of any sort.
The idea is that this feed will contain any event that would have
triggered an email to be sent to the public body, so can be used
as an alternative, equivalent way to stay up-to-date with happenings
on WDTK (or the Alaveteli installation of choice).
|
|
|
|
| |
The <link> tags in the feed <entry>s ought to be fully-qualified URLs.
|