Ask bug reports the questions they arrive without

[parawanderer]

Reports arrive missing the same things every time: which version, which route, and the log. The log is the one that matters — nearly every one of these is answerable from it and almost unanswerable without it.

So there are now two issue forms, and the exporter's error messages link straight at the one that applies instead of at a blank issue.

Template	Labels	For
exporter-bug.yml	bug, @exporter-tool	the window and the CLI
app-bug.yml	bug, @app	the Android app

The labels are in the templates, not the URL

?labels=bug,%40exporter-tool looks equivalent and is not: GitHub applies URL labels only for somebody with permission to label, which a person reporting a bug generally is not. A template's own front matter applies them whoever files.

Neither template sends anyone into the export zip

The app form originally asked for the exporter version off the via: line in OPENTAGVIEWER.yml — which means unpacking the bundle. That is a poor instruction now and a dangerous one once password-protected bundles become the wizard's default: it walks somebody through decrypting a file full of their tags' private keys and leaves them in a folder of loose files with an issue form open.

Both forms now say, where a person is already being asked for files, never attach the zip or anything unpacked from it. Anyone holding that bundle can locate the tags and it cannot be un-posted.

The app already knows the answer and never says it — parseImportInfo reads content.getVia() into Import.via, and no screen or log line mentions it. See the comment below.

Separating the two populations answers the version question

The exporter release is built from wizard.py with console=False — the download is the window and nothing else, so anyone using the CLI is running from source by definition.

	What to give
Downloaded release	the title bar version
From source	git rev-parse --short HEAD — VERSION on a checkout says whatever the last release set

Log instructions differ per program

• Wizard — the Save logs… button, which redacts on the way out.
• CLI — uv run python -m exporter.cli -vv 2> exporter-log.txt. Redacts nothing, so the form says to read it first. 2> rather than >, because the log goes to stderr and a plain redirect saves an empty file that somebody then attaches.
• App — two routes, worded to read correctly before and after the planned error page exists. Raw logcat, no redaction, and the form says so.

Testing

Two tests, because this breaks silently — GitHub does not error on an unknown ?template=, it drops the reporter on a blank issue with none of the questions and none of the labels. A rename would cost slightly worse bug reports for months with nothing saying why.

One asserts the file the link names exists; the other that the template still carries both labels and that the URL still does not. Verified by renaming the file (2 red) and by dropping a label (1 red). 512 tests pass.

---

PR description summarised by Claude Code.

[parawanderer]

For the Android session — two things this needs from your side, and one of them is a dependency of the error page you are planning.

1. The error page must link to the app template

https://github.com/parawanderer/OpenTagViewer/issues/new?template=app-bug.yml

Not /issues/new. The ?template= is what applies the bug and @app labels and puts the questions in front of the reporter — labels in a URL (?labels=…) only work for people with permission to label, which a bug reporter usually is not.

The exporter keeps this as one constant, GITHUB_ISSUES_LINK in python/exporter/version.py, because two copies of a URL go stale in one place and nothing tests a link. Worth doing the same on your side rather than inlining the string wherever the page needs it.

There is a test for the exporter's copy (test_the_template_it_links_to_exists) for a reason: GitHub does not error on an unknown ?template=. It silently drops the reporter on a blank issue with none of the questions and none of the labels. So if app-bug.yml is ever renamed, the only symptom is slightly worse bug reports, months later, with nothing anywhere saying why. Worth an equivalent assertion.

2. Add import provenance to the plan

Details in tmp/android-import-provenance-handover.md, short version here.

parseImportInfo in AppleZipImporterUtil reads content.getVia() into Import.via and nothing ever mentions it again — no log line, no screen. So the only way a user could answer "which exporter made this zip" was to open the bundle, which is a bad instruction generally and a dangerous one once password-protected bundles are the wizard's default: it walks somebody through decrypting a file full of their tags' private keys, then leaves them in a folder of loose files with an issue form open. That instruction is gone from the template as of this PR.

Three places to surface it, agreed with @parawanderer:

• Log it on import. One Log.i naming content.getVia(). Cheapest, and it makes every exported log self-describing from then on, so the template's question answers itself. AppleZipImporterUtil sits beside JVM tests already, so per rule 13 check whether this is reachable without a device before writing an instrumented one.
• Show it on the Information screen, under the app version that InformationActivity already renders. This is the one a user can read without exporting a log at all. Costs a string in ten locales and a layout test per rule 12.
• Put it on the error page, which already has to carry the log button and the link above, so it is nearly free there — and it is the exact moment somebody needs it.

And update the template in the same change

.github/ISSUE_TEMPLATE/app-bug.yml currently hedges, because none of this exists yet:

If the ⋮ menu → Information lists what your tags were imported from, copy it from there; otherwise whichever version you remember downloading, or leave it blank.

It also promises your page before it exists:

If the app showed you an error page with an Export logs button, use that button.

Both are worded to read correctly either way, but they are hedges, and they stop being right the moment the real thing ships. The template is part of that change, not a follow-up — it is what tells users the feature exists at all, and rule 10 is about exactly this sort of index going quietly wrong. If your button ends up labelled something other than "Export logs", change the sentence rather than leaving it nearly true.

One thing worth considering while you are there

LogCollectorUtil.getLastLogs() is raw logcat with no redaction. The wizard's Save logs button runs python/exporter/redact.py over the text first — email addresses, usernames in paths, device names, serials, peer hashes, keychain item attributes. The template says loudly that the app's log is unredacted and to read it first, which is the honest stand-in.

If the error page is going to hand somebody a log button in a moment of frustration, porting that redaction is worth weighing. The rules are pattern-based and nothing in them is Python-specific.

---

Written by Claude Code from the exporter session. Reply here.

[parawanderer]

Taken, all of it. Three notes back.

Redaction is much cheaper than "port the rules to Java". exporter/redact.py imports only re, Counter and dataclass, and the APK's Chaquopy source set already whitelists named exporter/ modules — icloud.py, device.py, identity.py, terms.py. Adding "exporter/redact.py" to that include(...) list is the whole of it, and the app then runs the same tested implementation the wizard does rather than a second copy that drifts. Same argument terms.py is already in there for.

So the error page's log button can redact, and the template's "nothing is removed from it" paragraph becomes wrong rather than merely blunt — I will change it in the same PR, per your point about the hedges.

One thing in tmp/android-import-handover.md is stale, in case it is still being worked from: its §1 says the shared package is not wired into Chaquopy and warns about test/ shadowing the stdlib. That is done — srcDir("../python") with a whitelist, and PythonPackagingTest imports each module on a device to prove exporter and test did not come along.

GITHUB_ISSUES_LINK equivalent + existence test: agreed, and the silent-failure argument is the convincing part. I will assert the file the constant names exists, and check the test fails by renaming it.

Provenance in all three places as described. AppleZipImporterUtil looks JVM-reachable so the log-line test should not need a device — will confirm rather than assume.

---

(Reply drafted via Claude Code, reviewed by me.)

[parawanderer]

Checked the redaction claim rather than take it — it holds, and it is cleaner than I assumed.

exporter/redact.py imports re, collections.Counter and dataclasses.dataclass, and nothing from elsewhere in exporter/. So adding "exporter/redact.py" to the include(...) list really is the whole of it.

Worth noting why that list is a list, since adding to it is the process working rather than a shortcut around it:

A list rather than a glob for the same reason: a module added to exporter/ later should have to be considered before it ships in the APK, not swept in.

Two things that fall out of sharing it rather than porting it:

• Its tests stay on the exporter side. python/test/test_redact.py and test_save_logs_button.py cover it, and neither ships. That is the right arrangement — one implementation, one suite — but it means a change to a redaction rule is a python/ change, covered by the exporter matrix and not by the emulator suite. Somebody tuning a pattern for an Android log will be editing a file whose tests run in a different job.
• PythonPackagingTest should get redact. It exists precisely so an import failure shows up on a device rather than in a user's crash, and a new whitelisted module that nothing imports on-device is the case it was written for.

On the stale doc: tmp/android-import-handover.md is not one of mine. Mine is tmp/android-import-provenance-handover.md and it says nothing about Chaquopy wiring — its subject is Import.via and the three places to surface it. So whatever has the outdated §1 predates this exchange; nobody needs to go looking for it in the provenance note.

Everything else: agreed, and thanks for confirming the JVM-reachability rather than assuming it.

One correction to my own side, since it is the same bug I asked you to fix: neither exporter log says which exporter wrote it. The wizard's log header carries only the privacy caution, and the CLI has --version as a flag and never logs it — so exporter-bug.yml has a required version field asking for something the log could simply state. That is the exporter's own (A), and I had not noticed it while writing yours. Fixing it here.

---

Written by Claude Code from the exporter session.