| Commit message (Collapse) | Author | Age | Lines |
|
|
|
|
|
|
|
|
| |
Stops the RequestMailer trying to send a stopped_responses mail if the
To: address can’t be parsed from the incoming message.
ArgumentError:
An SMTP To address is required to send a message. Set the message
smtp_envelope_to, to, cc, or bcc address.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prevents loading of all outgoing messages related to the info request.
Before
OutgoingMessage Load (1.5ms) SELECT "outgoing_messages".* FROM
"outgoing_messages" WHERE "outgoing_messages"."info_request_id" = 137
ORDER BY created_at
After
OutgoingMessage Load (0.8ms) SELECT "outgoing_messages".* FROM
"outgoing_messages" WHERE "outgoing_messages"."info_request_id" = 137
ORDER BY created_at LIMIT 1
|
|
|
|
|
|
| |
Since https://github.com/mysociety/alaveteli/commit/80ad2d4c31075ffc994e8c48ea25e6e3c486c364
no themes have been loaded by tests unless explicitly specified, so I think it's safe to
remove the code added in https://github.com/mysociety/alaveteli/commit/3dfc53f6b82b3c5da79a4c710d45b859f61f4f5f
|
| |
|
| |
|
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Seems more logical to make this one method that figures out what to do
based on file type. Plus, incoming message does so many things, it
seemed like having these related methods be separate would make them
easier to read and understand. Also, email, mobile and login
substitution texts weren't being translated. Finally, I think passing
the censor rules and masks as arguments is a first step in some more
decoupling of models.
|
|/
|
|
| |
It's also used in the web interface and needs to be escaped there.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Filters; more 403s, fewer 500s; added logging; less duplication
|
|
|
|
| |
Picks these up in `rake notes` and adds semantic meaning
|
|\
| |
| |
| |
| |
| | |
Conflicts:
config/general.yml-example
spec/factories.rb
|
| |
| |
| |
| |
| | |
They're not finding by the existing object, they're finding an existing
object.
|
| |
| |
| |
| |
| | |
Create the batch and associate new requests with it, send the outgoing
messages, and redirect to a page for the new batch.
|
| |
| |
| |
| |
| | |
Re-annotate models. Index InfoRequestBatches by user - we'll display the
batches for a user when they view their own requests.
|
| | |
|
| |
| |
| |
| |
| |
| | |
A virtual attribute to use to customise some info request behaviours
when we are using one request as a template for creating multiple
requests.
|
|\ \
| | |
| | |
| | |
| | | |
Conflicts:
doc/CHANGES.md
|
| |/
| |
| |
| | |
Refactor a bit so it's easier to read.
|
|\ \ |
|
| |/
| |
| |
| | |
Make specs a bit more focused, remove view specs - they're not relevant to the new code in their current form and don't seem to merit updating.
|
|/
|
|
| |
Thanks to György Peng for pointing out this omission.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
We have changed the denominator of the proportion-based statistics
to only include requests that are both visible and not
'awaiting_description'. This would mean, however, that the numerator
could be larger than the denominator. This commit updates the
calculation of those statistics to also exclude any hidden or
unclassified requests.
|
|
|
|
|
|
| |
This counts only those info requests that have prominence 'normal'
(i.e. are not hidden) and are not 'awaiting_description' (i.e. that
they have had some basic status classification).
|
|
|
|
|
| |
Apart from anything else, we don't want translators to have to worry
about the special case text. See https://github.com/mysociety/whatdotheyknow-theme/commit/2078febca5181ce3b1a9c0fae0123ae5f6448718 for the corresponding change to whatdotheyknow-theme.
|
|\ |
|
| |
| |
| |
| | |
Fixes #1082.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
Gemfile
app/views/admin_request/edit_outgoing.html.erb
config/packages
doc/CHANGES.md
doc/INSTALL.md
spec/models/info_request_spec.rb
spec/models/public_body_spec.rb
|
| | |
| | |
| | |
| | |
| | | |
Make old_unclassified_params method consistent with
last_public_response_event and associated methods.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
get_last_response_event and get_last_outgoing_event are used in various
places to determine which events to link to, use in queries etc.
Restrict them to refer to the last publicly visible event of the
relevant type, and rename them to make that clear.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
Use send_file to send zips. Also adds 'all_can_view_all_correspondence?'
- is this request completely cachable, or do we need to cache different
versions for different levels of privilege?
|
| | | |
|
| | |
| | |
| | |
| | | |
Move it into the Ability module.
|
| | |
| | |
| | |
| | | |
A super user will be able to see all hidden things, not just requests.
|
| | | |
|
| | | |
|
| | | |
|
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On PublicBody, we don't need to update info_requests_count
because that's already done with :counter_cache. On the
other hand, info_requests_successful_count and
info_requests_not_held_count can't be updated easily with
counter_cache (since they need conditions to be attached).
Instead we update them in post_save and post_destroy,
as suggested here:
http://blog.douglasfshearer.com/post/17495285851/custom-counter-cache-with-conditions
This also adds tests to ensure that the
after_(save|destroy) callbacks are called and that they
modify the counts correctly.
|
| |
| |
| |
| |
| |
| | |
Add some notes on the logic and expectations around
InfoRequest.described_state and calculate_status and
InfoRequestEvent.described_state and calculated_state.
|