| 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.
|
| | |
|
| |
| |
| |
| | |
This is the most rudimentary possible way to give them access to the batch request urls, pending #1239
|
| |
| |
| |
| | |
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 it updatable via the user admin page.
|
|\ \ |
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
Conflicts:
doc/CHANGES.md
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
For cases where we don't want to make the change suggested. There
doesn't seem to be any obvious default text to use in the response to
the person who requested the change.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Also add editable text for an email to be sent to the person requesting
the change.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously it accepted a user, but for this usage we won't necessarily
have one.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
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.
|
| |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
|\ \ \ \
| | |/ /
| |/| | |
|
| |\ \ \
| | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
Gemfile.lock
app/views/layouts/default.html.erb
config/application.rb
public/admin/stylesheets/admin.css
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Move HTML to view from controller, use same elements for other country
popup and everypage - partly so they don't display on top of each other
anymore. Don't position them over existing content, position them at the
top of the page. Use consistent styling, and keep the javascript
unobtrusive.
|
| | | |
| | | |
| | | | |
It is a better solution to forma sentenses in po file, therefore the substring in variable added to _() as a parameter.
|
|/ / / |
|
|\ \ \ |
|
| | |/
| |/| |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Under Ruby 1.8.7, you can parse a CSV file with the
following code (Example A):
require 'csv'
CSV.parse('foo.csv') do |row|
puts "got row: #{row.inspect}"
end
Rather confusingly, under Ruby 1.8.7, CSV.parse can also
take a string representation of the contents of the file
as its parameter, so this also works (Example B):
require 'csv'
CSV.parse("1,hello,red\n2,goodbye,green") do |row|
puts "got row: #{row.inspect}"
end
However under Ruby 1.9.3, CSV.parse only expects a string
representation of the contents of the CSV file, so only
Example B works; Example B fails silently (interpreting
the filename as a single cell CSV file, typically).
The import:import_csv rake task unfortunately relied on
both A and B working. This commit fixes this by adding
PublicBody.import_csv_from_file, and refactoring
PublicBody.import_csv to use the newly added class method,
and adds a test to check for any regression in this
behaviour.
(This means that the usage of import_csv in the admin public
body controller's import_csv action could now be changed
to use PublicBody.import_csv_from_file directly from the
uploaded file, which would be more efficient and cope
with larger files without using lots of memory.)
Fixes #1229
|
|\ \
| |/
|/|
| |
| |
| |
| | |
rails-3-develop
Conflicts:
Gemfile.lock
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
feature/switch-to-asset-pipeline
Conflicts:
Gemfile.lock
app/assets/images/admin-theme/ui-bg_flat_0_aaaaaa_40x100.png
app/assets/images/admin-theme/ui-bg_flat_55_fbf9ee_40x100.png
app/assets/images/admin-theme/ui-bg_flat_65_ffffff_40x100.png
app/assets/images/admin-theme/ui-bg_flat_75_cccccc_40x100.png
app/assets/images/admin-theme/ui-bg_flat_75_dadada_40x100.png
app/assets/images/admin-theme/ui-bg_flat_75_e6e6e6_40x100.png
app/assets/images/admin-theme/ui-bg_flat_75_ffffff_40x100.png
app/assets/images/admin-theme/ui-bg_inset-soft_95_fef1ec_1x100.png
app/assets/images/admin-theme/ui-icons_222222_256x240.png
app/assets/images/admin-theme/ui-icons_2e83ff_256x240.png
app/assets/images/admin-theme/ui-icons_454545_256x240.png
app/assets/images/admin-theme/ui-icons_888888_256x240.png
app/assets/images/admin-theme/ui-icons_cd0a0a_256x240.png
app/assets/javascripts/admin.js
app/assets/javascripts/admin/jquery-ui.min.js
app/assets/javascripts/application.js
app/assets/javascripts/jquery-ui.min.js
app/assets/javascripts/jquery.flot.errorbars.min.js
app/assets/javascripts/jquery.flot.min.js
app/assets/javascripts/stats.js
app/assets/stylesheets/application.css
app/assets/stylesheets/fonts.scss
app/views/general/_stylesheet_includes.html.erb
app/views/layouts/admin.html.erb
app/views/layouts/default.html.erb
app/views/public_body/statistics.html.erb
config/application.rb
config/environments/development.rb
|
| | |
| | |
| | |
| | |
| | |
| | | |
ActionMailer now checks for a 'to' address on sending mail, so supply
one so that we can check exception notification mail sending. Also check
that we have one before trying to call the exception notification code.
|
| | |
| | |
| | |
| | |
| | | |
In render calls, that's now deprecated in favour of using the :formats
option.
|