| Commit message (Collapse) | Author | Age | Lines |
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On WDTK, /body/all-authorities was using lots of memory - this
commit reduces that by (a) fetching the public bodies in batches,
rather than keeping them all in memory at one time and
(b) writing the CSV to a file and then returning it with
X-Sendfile (or equivalent), rather than returning the whole file
from memory with send_data.
There's a FIXME to do with the layout of download directories; if
that's changed, the example nginx config, etc. will need to be
updated too.
This commit also adds a basic test for reasonable CSV being
returned and switches from FasterCSV to CSV in order to fix this
NotImplementedError under Ruby 1.9:
Please switch to Ruby 1.9's standard CSV library.
It's FasterCSV plus support for Ruby 1.9's m17n encoding engine.
(The CSV version seems to still work fine under 1.8.7.)
|
|
|
|
|
|
|
|
|
|
| |
In the initial release of public body statistics to WhatDoTheyKnow
a public body only intended for testing ("mySociety Test Quango")
was included in the statistics. This commit causes public bodies
tagged with "test" to be excluded from the public body statistics
page.
Fixes #1115.
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
The WDTK volunteers pointed out that it's not fair to include
hidden requests in the denominator, since they're typically hidden
for a good reason (e.g. being vexatious, spam, etc.), and we have
no information about those that are awaiting_description (i.e.
unclassified) so they should be excluded as well.
|
|
|
|
|
|
| |
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).
|
|
|
|
| |
These are regenerated with "bundle exec annotate"
|
|
|
|
|
|
|
|
| |
For importing a very large number of public bodies, it's mostly likely
less frustrating to import them from the CSV file using this rake task
instead of using the form in the admin interface.
Fixes #1132
|
|\ |
|
| |
| |
| |
| |
| | |
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.
|
|\ \ |
|
| |/ |
|
|/
|
|
|
|
|
|
| |
In the rare circumstance that someone created a public body
whose name started with a lower case letter outside [a-z]
with Alaveteli running under Ruby 1.8, the letter would not be
upcased correctly before saving to the first_letter column.
This commit fixes that by using a Unicode-aware upcase function.
|
|
|
|
| |
Fixes #1104.
|
|\ |
|
| |
| |
| |
| | |
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.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
Add some tests that it's working on the outgoing message model.
|
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
app/views/request/_incoming_correspondence.html.erb
|
| | |
| | |
| | |
| | |
| | |
| | | |
At least some of the logic for incoming and outgoing message prominence
is going to be identical, so move it to a module they can both include
and use.
|
| | |
| | |
| | |
| | |
| | |
| | | |
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?
|
| | | |
|
| | |
| | |
| | |
| | | |
We're about to reuse them for the text view.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
This will cover changes in prominence to incoming messages.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
Move it into the Ability module.
|
| | | |
|
| | |
| | |
| | |
| | | |
A super user will be able to see all hidden things, not just requests.
|
| | |
| | |
| | |
| | |
| | | |
Add a convenience method for getting the 'response' event associated
with an incoming message.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add a migration to remove the unused column 'prominence' from
info_request_events, remove validation of prominence, remove unused
InfoRequestEvent.user_can_view? method. Remove references to
InfoRequestEvent.prominence.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|