| Commit message (Collapse) | Author | Age | Lines |
|\
| |
| |
| |
| |
| | |
Conflicts:
config/general.yml-example
spec/factories.rb
|
| |
| |
| |
| |
| | |
Otherwise they get marked as fuzzy in .po files and lose their existing
translations.
|
| | |
|
| |
| |
| |
| | |
We're going to want to actually create and send the requests later.
|
| | |
|
| |
| |
| |
| | |
Add or remove all buttons, ajax search as you type.
|
| |
| |
| |
| |
| | |
Seems like you have to specify a limit with xapian. We'll probably want
to document the limit somewhere on this page.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| | |
This duplicates what's done in the new action, but I can't currently
think of a way of sharing functionality that doesn't seem overly complex
and/or risky.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
It doesn't make logical sense that they would. However I am preserving
the ability to make batch requests as a separate thing from not having a
daily limit - I think batch sending requires a (perhaps marginally)
bigger level of trust.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Add validation, preview as in single request creation. Add comments
noting further work to be done in this action.
|
| |
| |
| |
| | |
Reuse it for the batch request page.
|
| |
| |
| |
| |
| |
| | |
Give it basic access control, and add some conditionals to the 'new'
template around bits that use @info_request.public_body so that they
render something different if @batch is assigned.
|
| |
| |
| |
| | |
Should retain a list of selected public bodies across searches.
|
| | |
|
| | |
|
|\ \ |
|
| | |
| | |
| | |
| | | |
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.
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is involved with the construction of meaningful xapian queries with
respect to InfoRequestEvents. This commit also removes the
get_tags_from_params method, which presumably was targeted at
PublicBodies, but doesn't seem to actually be used anywhere.
XapianQueries is used to extend InfoRequestEvent in order to prevent
InfoRequestEvent becoming too unwieldy and to preserve the association
between these methods.
|
|/
|
| |
It is a better solution to forma sentenses in po file, therefore the substring in variable added to _() as a parameter.
|
|\
| |
| |
| |
| |
| |
| | |
rails-3-develop
Conflicts:
Gemfile.lock
|
| |
| |
| |
| |
| | |
In render calls, that's now deprecated in favour of using the :formats
option.
|
| | |
|
|/ |
|
|
|
|
|
|
| |
In fact, we do still need to set permissions.
This reverts commit 56ce526acdcb1b5493bc11f14b751b5c3f02f686.
|
|
|
|
| |
Fixes #1101.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| | |
As @mhl points out, this more clearly indicates that they may come back
at some point.
|
| |
| |
| |
| |
| | |
Either rails or the webserver will be sending it, we're not redirecting
anymore.
|
| |
| |
| |
| |
| | |
So that files attached to different messages with the same name and
url_part don't get overwritten.
|
| |
| |
| |
| |
| |
| |
| | |
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?
|
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
|