Ten thousand changes ought to be enough for any normal mapping activity.
Automatic edits and imports are controlled by scripts anyway so it doesn't
make a difference to them as they just have to adapt the limit.
The reason for my suggestion is that large changesets are becoming
increasingly difficult to handle due to frequent timeouts when trying
to load and process them.
The changeset size limit is returned by the API in the "capabilities" request
so client software that honours that information will automatically pick up
the new limit.
Closes#1259
The greeting includes the recipient's user name (as for the message notification mail), which should increase the recipient's trust that the message isn't spam. Greetings were reused from each language's respective locale flie.
Several notifications are about a message having been sent from one user to another via OSM. I've moved the code for the HTML table that holds the actual user message, with the avatar and the body text, to its own partial template, so that it can be reused. I've updated a second notifier message to the new template, diary_comment_notification.
Rather than including HTML markup in the locale file (which also has the inconvenience of requiring both a plain-text and an HTML duplicate of the same string), move the markup to the template. Also added a helper to reduce clutter in the template slightly.
Make the file paths to image assets more compact. I investigated using `image_path` but could only get it to return the path for a public URL, which is different and also includes the asset pipeline digest.
Got rid of that big ugly base64 blob which was only a temporary crutch anyway. Added a png file instead. Use File.read rather than File.open for a 66% reduction in verbosity.
If a deadlock occurs then the transaction will be retried so we
need to make sure that the object will still be dirty so that it
will be saved again during the retry but that the version won't
be incremented a second time.
This technique was already used in app/models/changeset.rb
This suppresses the error messages when parsing invalid XML, but
the exceptions are still raised, as tested in test_from_xml_double_lat
in test/models/node_test.rb
Only treat auth_success as a possible login attempt if we're not
in the middle of validating a new user, or a change to a user.
Also validate the uniqueness of external auth credentials at the
rails level rather than just at the database level, and make sure
any errors are properly reported.
Fixes#1265
Implement our own matching algorithm rather than trying to
patch the http_accept_language one and make sure everything is
using it in a consistent way.
Fixes#1125
