Reports and updates

When something in the app doesn't work, or when you're missing something you need, you have a direct line to the people who write the software. It isn't a conversation with support: it's a card that goes into the developers' work queue, and you can follow it right up to the day the fix lands in your app.

This page covers how to send a report, how to read its progress, and where to find the update that carries it.

Sending a report#

Top right, in the app's toolbar, there's a bug-shaped icon: Report a bug. It opens from any page.

1. Pick the type

   Bug if something doesn't work as it should, Feature request if it works but is missing. The choice changes the words we use to describe progress — there's nothing to diagnose on a feature request — and tells us how to read it.

2. Tell us what happened

   The box asks you three questions: what you were doing, what you expected, what happened instead. Answering all three saves a round of questions. The send button stays off until you've written a few words.

3. Attach something, if it helps

   Up to five files of 5 MB each: a screenshot, a PDF that came out wrong, a file that won't upload. A screenshot is often worth half a page of description.

The page you were on, the app version and the session recording are attached automatically: you don't have to tell us where you were or which version you're running.

My reports#

At the bottom of the sending window there's a My reports link: it takes you to the list of the ones you've sent. There's no menu entry, that link is the way in.

• The list is personal: you see yours, not your colleagues'.
• The filters at the top separate All, Open and Closed.
• Next to each title a label says whether it's a Bug or a Feature request.
• Some rows say Opened by the CrankPal team: we wrote it on your behalf, usually after a request you made to support.
• At the bottom of the page the sending form appears again, so you can send another without going back.

Where things stand#

Under each report there's a bar with seven stages. Each stage is captioned with its name: the ones reached are in colour, the ones still ahead are grey — so you read where we are and what's left in one go. Under the completed stages you get the date and time they were reached.

The stages are the same for everyone, but they're named according to the type:

Hover a stage and you get its full name and the exact moment it was reached. On older reports the testing date isn't measured but worked out from the release date: when that happens, the tooltip says so.

When the work stops#

Two situations aren't stages of the bar and can happen at any point.

• Waiting for your reply — the bar turns amber and stays where it is: the work is on hold, not undone. There's a question for you in the comments, and nothing moves until you answer.
• Reopened — the fix didn't hold, or you reopened it yourself. The report goes back into the queue.

There's also a third case, Closed: closed without a fix, because it duplicates another one or because we decided not to act on it. There the bar disappears altogether — a bar stuck at one fifth forever would be telling you something untrue. The reason is in the comments.

Replying and reopening#

Click the title, or Open details and comments: the comments the team wrote for you open up. These are the ones meant for the person who reported — internal technical notes stay out. Below them there's a box to reply.

If you write a comment on a report that is already resolved, before saving it the app asks what you want to do:

• Cancel — nothing is saved, your text stays where it is.
• Comment only — publishes the comment and leaves the report closed.
• Comment and reopen — puts it back into the queue along with your comment. That's the right choice if the problem has come back.

From the fix to the update#

When a report reaches Resolved, a line appears under the bar: Released with version X, in production since DD/MM/YYYY; on a feature request the same line reads Available from version X, released on …. That date is the day the update arrived in your app, not the day we prepared it: days can pass between the two, and the one that concerns you is the first.

What that update contains is in Settings›What's new; the version number at the bottom of the side menu opens the full list. There too the dates are arrival dates, and if several versions arrived together you get a single card with that day's changes: what matters is what changed for you, not how many times we published.

If you'd rather be told than go and look, Settings›Workshop has a Notify me when new releases come out switch: with every update it emails the workshop's administrators the changes and the current state of the reports you've sent. It's off by default — see Workshop profile and hours.

Common problems#