feedback_kit 0.4.0

In-app feedback boards, voting and a public roadmap for Flutter. Auth-agnostic: bring your own identity via a FeedbackIdentityProvider, or let the built-in anonymous device identity handle it. Pairs w [...]

0.4.0

Reports now say what they were filed from.

• Standard client attributes. Every new post carries platform, osVersion, appVersion, appBuild, deviceModel and the kit version, under names the Feedback service fixes for all its clients — so a team's inbox can compare a report from one app with a report from another. Set appVersion/appBuild (and optionally deviceModel) on FeedbackConfig; platform and OS version the kit reads itself.
• Your own attributes too. FeedbackConfig.contextAttributes carries up to ten app-specific values — an environment name, a feature flag, a user tier — without diluting the standard fields.
• Off switch. collectClientContext: false sends none of it.
• No more retyping your address. On a board with signed identities the submit form now offers the address the host product already vouched for instead of asking for one. FeedbackClient.viewer() reads it; submit(notifyMe: true) uses it. The tick is unchanged and still required — knowing someone's address is not permission to mail them, so nothing is sent unless they ask for it.

The kit reads only what dart:io can prove. appVersion, appBuild and deviceModel come from the host app because reading them needs package_info_plus and device_info_plus, and bundling those would put a second copy of plugins into apps that already ship their own — the same reason the image picker is a seam.

None of this is public: the service keeps the client context in the team's inbox and drops it from every public board view, because device, OS and build together identify the person who filed the report.

Needs the Feedback service from 2026-08-03 or later. Against an older one the field is ignored and posts are stored exactly as before.

0.3.0

Multiple choice, and submit forms that speak the reader's language.

• Multiple choice. A board field of type multiselect renders as a list of tick boxes and submits a list of values. Boxes rather than a multi-select dropdown because every option has to be reachable with one thumb, and the choices stay visible while the next one is made.
• Translated forms. A board's labels, categories and option wording now arrive already in the reader's language — the service resolves them against the same Accept-Language tag the kit already sends, so nothing here has to know which languages a board was translated into. SubmitFormField.optionLabels carries the wording next to the untranslated options; the values themselves stay canonical, so an answer means the same thing whatever language it was given in.

Both are additive: a board that uses neither renders exactly as before, and an unknown field type still degrades to a text field rather than crashing.

Needs the Feedback service from 2026-07-31 or later. Against an older one, optionLabels is simply absent and each option shows its own value — which is what it did before this release.

0.2.0

Screenshots, downvoting, and the app's own language.

• Language follows the operating system. FeedbackStrings ships full translations for 27 locales, and the client sends the resolved tag as Accept-Language on every request — so the in-app strings, the board payload and the status mails all land in the same language. FeedbackConfig.locale forces one when the host app has its own switch.
• Screenshots. FeedbackConfig.imagePicker is a seam, not a dependency: the kit never pulls in image_picker, because that would force its platform plugins and permission entries on every host app — most of which, like MyMovement, already have one. A three-line adapter is in the docs. Leave it null and the attach button simply does not appear.
• Downvoting. vote(postId, value: 1 | -1 | 0) replaces vote(postId, on: bool). FeedbackPost.voteCount is now the net score and may be negative where a board allows push-back; upvoteCount and downvoteCount carry the split. viewerHasVoted remains as a derived getter, so read-only callers keep compiling.
• Rich content. Attachments and emoji reactions render on the post and list views; FeedbackAttachment.urlFrom(baseUrl) turns the service's path into a URL.
• Custom submit forms. A board's own labels, categories and extra fields are rendered from its configuration — changing the form needs no app release. An unknown field type degrades to a text field rather than crashing.

Breaking

• vote(postId, on: bool) → vote(postId, value: int).
• VoteButton takes viewerVote/onVote instead of hasVoted/onPressed, plus a required strings.
• PostTile, FeedbackSubmitScreen, FeedbackPostScreen and FeedbackRoadmapScreen take a required strings. Callers using FeedbackBoardScreen — the documented entry point — are unaffected: it supplies them.

Fixed

• Attachment uploads went through a one-off HTTP client instead of the one passed to FeedbackClient, silently bypassing a host app's proxy, certificate pinning or request logging for uploads only.

0.1.1

• New FeedbackChangelogScreen, reachable from FeedbackBoardScreen whenever the board has its changelog enabled. The client and the ChangelogEntry model shipped in 0.1.0, but nothing rendered them — and the board screen's documentation claimed a changelog view that did not exist.
• Entries are sorted newest-first client-side and dated absolutely, with a relative hint only for the last week: a changelog is a record, and "vor 84 Tagen" rots in a screenshot.
• A board without a public changelog (the service answers 404) is presented as a configuration state, not as an error.

0.1.0

First release.

• FeedbackClient over the platform Feedback service's public API: board config, paged posts, post detail with comments, voting, commenting, roadmap, changelog.
• Two identity modes behind one seam. AnonymousDeviceIdentity generates and persists a device token with no backend involved; CallbackIdentityProvider carries a token your own backend signed with the board's key. The package never holds the signing key and never signs.
• One transparent refresh-and-retry on an expired token, so a user is not told their session lapsed mid-tap.
• Typed failures (FeedbackException.failure) so a signed-out visitor, a stale token and a rate limit can be told apart.
• Screens: FeedbackBoardScreen, FeedbackPostScreen, FeedbackSubmitScreen, FeedbackRoadmapScreen, plus PostTile / VoteButton / StatusChip for hosts that want their own layout.
• Optimistic voting that reverts on failure.
• Unknown status values from a newer service degrade to open instead of throwing.