| Commit message (Collapse) | Author | Age | Lines |
... | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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?
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This was disabled for hidden requests as the download was by redirect,
allowing people who have not been authenticated to conceivably access
the download. We'll be moving to send_file instead, so can restore it.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This should be handled by assign_variables_for_show_template. Otherwise,
the make_request_summary_file method shouldn't depend on instance
variables
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Adds a spec for what we want to see - no message text in
correspondence.txt, and no attachments. Refactors the
simple_correspondence templates to make it clearer that these are doing
the same job as the html.erb ones, for text.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Each part is a separate sentence, and we're going to reuse some of them
in the text view.
Conflicts:
spec/integration/view_request_spec.rb
|
| | | |
| | | |
| | | |
| | | | |
We're about to reuse them for the text view.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
app/views/request/_incoming_correspondence.html.erb
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Render the show template within the current thread rather than making
another request - we're going to need to use the current session in
order to know what do include in the zip file, now that we have more
fine-grained visibility of messages. Also, this will mean we can use
this functionality in single threaded contexts, and test it more easily.
Don't display profile photos as this would require another process, and
hide other icons so we don't need to include them. Use render_to_string
as a more standard way of rendering templates to a string for further
manipulation.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
So we can reuse them when rendering the show template to a file. Lots of
the sidebar prep isn't going to be needed for that view, so make that
optional in the template.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Split into those that come from request params and those that come from
the model
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This will happen if the prominence has been changed in the admin
interface but no reason has been filled in.
Conflicts:
app/views/request/_incoming_correspondence.html.erb
|
| | | |
| | | |
| | | |
| | | | |
This will cover changes in prominence to incoming messages.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
From the request admin page.
|
| | | |
| | | |
| | | |
| | | | |
The order is the same as the default association.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
We'll use this for saving the changes to the prominence of an incoming
message in a relatively RESTful url structure.
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Make specs that depend on multiple controllers and models interacting
integration specs.
|
| | | |
| | | |
| | | |
| | | | |
Eventually this should use standard RESTful routing.
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
app/views/request/_incoming_correspondence.html.erb
Conflicts:
spec/integration/view_request_spec.rb
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
Different messages for normal user, requester and admin user.
|
| | | |
| | | |
| | | |
| | | | |
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.
|
|\ \ \ \ |
|
| | | | | |
|
| |_|_|/
|/| | |
| | | |
| | | |
| | | | |
The labels on the public body statistics graphs weren't marked as
being translatable. Fixes #1079.
|
|\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
app/controllers/public_body_controller.rb
config/general.yml-example
lib/configuration.rb
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This introduces some raw SQL statement for the fallback case, but we
can't see an easy way to avoid that in this case.
This commit also adds some tests that assert the sorting and
non-duplication properties of the listing.
Thanks to Louise Crow for working out the SQL expression for
falling back to the default locale.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The locale returned from locale_from_params may be dash-separated,
(the I18n module convention) whereas those in the
public_body_translations table are underscore-separated. The
AdminPublicBodyController was looking for dash-separated locales in
that table, so ensure that dashes are substituted for underscores
before using them in a query.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As the code stood, the list method in PublicBodyController would only
return results that had translations of the public body in the default
locale. This has a variety of problems if you're viewing pages in the
non-default locale - for example, the "first letter" links wouldn't
bring up the public bodies that began with that letter in the current
locale, only those that began with it in the default locale.
Ideally, every public body would be translated into every available
locale for the site, but there are cases where deployers wish to have
public body listings also include those from the default locale, in
case there are untralsated public bodies:
https://groups.google.com/d/msg/alaveteli-dev/zUY_USaAMAM/M7KTQ9RC5YUJ
This commit makes the default behaviour to look for public body
listings only in the current locale, but if the new configuration
option PUBLIC_BODY_LIST_FALLBACK_TO_DEFAULT_LOCALE is set, then public
body listings will be looked for in both the current locale and the
default locale.
Fixes #1000
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In the list method of PublicBodyController, capitalize
the SQL keywords consistenly and don't include extraneous
whitespace in the strings. (On the former point,
previously only some were - the convention is a matter of
some debate, but in this case the you editor's not doing
to do syntax highlighting of SQL so having the keywords
capitalized helps its readibility, I think.)
I wouldn't normally do this kind of cosmetic tidying up,
since it affects the tidiness of diffs and merges, but in
this case I'm going to change all these lines in the
next commit anyway, so that reasoning doesn't apply.
|
| | | | |
|