Deployments for https://forwardapphq.com

Adds an MCP server at POST /mcp so an AI agent can turn posts from a public
Facebook group into donations on Forward.
The server never touches Facebook. The agent does the reading, with its own
browser session and its own membership of the groups; the endpoint only turns
"here is a post" into a record. That keeps scraping out of the application and
leaves the MCP surface small enough to stay stable.
Three properties are enforced structurally rather than by convention:

• Imports are drafts. A new `draft` state is invisible everywhere, because

every listing already goes through `active`, and the direct URL 404s for
anybody but its owner. Watch alerts are held back until `publish!`.

• Imports are credited to the original poster. `user_id` stays the importing

account - a row needs an owner, and that is who to ask about it - while the
donation is attributed to `source_author_name` and links to `source_url`.
Imports are not requestable, because the importer does not have the item;
visitors are sent to the original post instead. `create_donation` requires
both fields, so there is no way to use this endpoint to post something as
your own.

• Re-scanning a group is safe. `source_url` is unique at the database, and is

normalised to drop fbclid, mibextid and friends first, so the second import
of a post is refused rather than duplicated.
Two changes fall out of the ownership split. The donor-currency check is
skipped for imports, since `user` is the importer and their region says nothing
about the market the donation belongs to - somebody in Copenhagen curating a
Stockholm group is importing SEK donations, and that is correct. To keep the
invariant that check was protecting, `User#update_stats!` now counts only
donations the user posted themselves, so a curator is neither credited for
items they never had nor able to mix currencies into their totals. The region
and charity checks are untouched.
`list_charities` takes a region and returns only charities whose currency
matches it. The currency rule is the constraint an agent would otherwise trip
over on most calls, and answering it in the tool signature beats answering it
in an error message.
Image URLs arrive from a page an agent was told to go and read, so they are
attacker-influenced in the ordinary case. `RemoteImageFetcher` is https-only,
resolves the host and checks every address it resolves to, pins the connection
to the address it checked, and re-runs all of that per redirect hop.
Authentication is a bearer token rather than the session cookie, because the
caller is not a browser. Tokens are stored as HMAC digests, shown once, can be
named and renamed, and are rate limited per token.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
⬆️ Upgrade libraries

Currency becomes a property of the region a donation happens in rather than
something the donor picks per item.

• a region owns the currency; a charity accepts exactly one, which keeps its

total raised a single figure

• a donation copies its region's currency and validates it against the region,

the charity and the donor's own region

• the locale decides only how an amount is punctuated, never which currency


• the currency picker is gone from the donation form; `market_controller` keeps

the symbol and charity list in step with the selected region

• `currency_symbol` columns are dropped for a new `Currency` model, following

`Locale` as the single source of truth

• the admin dashboard's cross-market total is grouped by currency, not summed

Also makes `regions.donations_count` a true counter cache. An active-only
counter cannot work, since claiming or deleting a donation is an update and
never fires the create/destroy callbacks that maintain it. The regions index,
which labelled that number "available items", now queries for the active count.

• 🌐 Add multi-language support (da, sv, no, de, fr, es)

Localises the site into Danish, Swedish, Norwegian, German, French and
Spanish alongside English, using Rails' own i18n rather than a gem.
URLs
English keeps its existing unprefixed paths, so no URL moves and no
redirects are needed. The other languages are served from a `/da/...`
prefix via `scope "(:locale)"`. Admin, the API and sitemaps opt out.
Locale resolution
URL > signed-in user's profile > cookie > Accept-Language > English.
The URL always wins so a shared or crawled link renders the language it
was shared in. Visitors who prefer another language are redirected once
from an unprefixed path, keeping one canonical URL per language.
Routes without a `(:locale)` segment never redirect. This matters for
the OmniAuth callbacks, which live on fixed paths: redirecting them
discards the auth hash and breaks sign-in.
SEO
`<html lang>`, canonical, hreflang for all seven languages plus
x-default, og:locale and its alternates, and translated titles and
descriptions. The sitemap emits per-entry alternates rather than
duplicating rows per language.
Language selector
Footer dropdown reusing the existing dropdown controller. Saves to the
user's profile when signed in and to a cookie otherwise. Language is
also editable on the profile form.
Content
Navigation, forms, flash messages, emails and meta tags, plus the home,
search, about, press, help, FAQ and MobilePay pages. Emails render in
the recipient's saved language, including their links. Region names and
descriptions are translatable per locale from the admin.
Terms and privacy stay English-only for now and reach other locales
through the fallback; they are keyed and ready for a reviewed
translation.
Fixes found along the way

• charities#show declared format.rss with no template, so the request

500'd. Added the feed.

• `xml.language I18n.locale` passed a Symbol, which Builder reads as a

namespace prefix and emitted `<language:en/>`.

• FAQ answers moved into locale data still contained ERB, which

rendered as literal text. Links now use placeholders resolved in a
helper so they stay locale-correct.
Query efficiency
Fixed N+1s on donation cards (donor avatars, charity logos, regions),
charity logos on the home/MobilePay/country/region pages, comment
authors, leaderboard donors, and notifications in both the navbar and
the notifications page. The sitemap no longer loads each user's
donations separately. Covered by tests that fail if the count grows
with the number of records.
Adds one gem, rails-i18n, for Rails' own date, number and validation
strings in the new languages.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

• 💚 Fix CI: trailing newline and HTTP verb confusion

Both failures predate this branch and reproduce on develop, but they make
the build red, so they are fixed here.
Rubocop flagged a trailing blank line in admin/users_controller_test.rb.
Autocorrected; the file is otherwise untouched.
Brakeman flagged `request.get?` in Authentication#store_location: HEAD is
routed like GET, so a HEAD request skipped storing the return path.
It now treats the two alike.
The locale redirect had the same divergence, without being flagged. A
crawler checking an unprefixed URL with HEAD would have seen a different
answer than the GET that followed, so it redirects on HEAD as well.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
⬆️ Update version

Revamp the layout of the MobilePay charities page to include a full-page gradient background and enhanced visual elements. Implement an auto-scrolling feature for the charities list to improve user engagement. Update the home page to support seamless scrolling of charity cards and adjust the number of displayed charities for better performance. Additionally, refine the footer and navbar styles for a more cohesive design.

Implement a new action in the PagesController to list active charities using MobilePay. Update routes to include a path for this action and add a link in the footer for easy access. Enhance sitemap to include the new page for better SEO visibility.

Update the HTML tags in both admin and application layout files to include the lang attribute, improving accessibility and compliance with web standards.

Add functionality to analyze donation images using OpenAI Vision API,
including progress indicators and automatic form filling based on
analyzed data. Update dependencies and configuration for integration.

Revamp layout and styling for better visual appeal and user experience.

Implement search feature in the charities index to allow users to
filter charities by title or description.

Change image display to 'object-contain' for better visual consistency
across leaderboard and donation cards.