Feature/labelary privacy notice#29
Merged
Merged
Conversation
ZPL labels can carry sensitive payloads (patient/serial/lot data); until now the preview silently sent the full ZPL to api.labelary.com without any user-facing acknowledgement. Adds: - store.thirdParty.labelary gate (build-time default via VITE_THIRD_PARTY_LABELARY env, runtime-overridable; persisted) - one-shot privacy notice on first preview open, persisted via labelaryNoticeAcknowledged - permanent footer link 'Preview via api.labelary.com' in the modal - disabled-state placeholder for when the gate is off (forward-looking for Tauri/Docker builds where preview will be off by default) - 6 new locale strings across all 32 locales The shape (per-service object) anticipates future services (BrowserPrint, …) without forcing a state migration.
Both the Preview button (ZPLOutput) and the Print menu item (AppShell) go through Labelary; gate them on thirdParty.labelary so the dead end 'preview disabled' state inside the modal is no longer reachable. Removes the disabled-state branch from LabelPreviewModal and drops the now-unused previewDisabled locale key from all 32 locales. The modal flow simplifies to two states: notice → fetch. When a settings UI lands later, toggling labelary back on restores the entry points without further code changes.
Print routes through Labelary like Preview does, but the Print menu item only checked the labelary gate, not the notice flag. A user who had never opened Preview could trigger printLabel() and ship the full ZPL to api.labelary.com without ever seeing the privacy disclosure. Hide Print until the notice has been acknowledged via Preview. After the first acknowledgement Print stays available permanently — the gate is only about the very first call.
The 'is Labelary callable?' check (gate on AND notice acknowledged) was inlined separately in AppShell and LabelPreview with slightly different spellings. Extract a canCallLabelary selector in the store as the single source of truth, so any future call site stays in lockstep automatically. ZPLOutput's Preview button intentionally keeps the simpler labelary-only check — Preview is the path to the notice, so it must be reachable before acknowledgement.
Persisting thirdParty would freeze the env-default value on first run: a build later flipped to VITE_THIRD_PARTY_LABELARY=false would still load the previously persisted true and silently re-enable the gate. Until a settings UI lets users explicitly opt in/out, the env is the only source of truth for the gate. labelaryNoticeAcknowledged stays persisted so the first-run dialog doesn't reappear after reload.
- thirdParty doc-comment claimed user choices persist; after the partialize fix the build env is authoritative on every load. Update the comment to match reality. - Add a why-comment on ZPLOutput's direct labelary check explaining why it intentionally diverges from the canCallLabelary selector used by other call sites: Preview is the path to the notice itself, so the button must remain reachable before acknowledgement.
There was a problem hiding this comment.
Code Review
This pull request introduces a privacy gate and acknowledgement mechanism for the Labelary third-party service. It adds state management to track user acknowledgement of a privacy notice, gates network calls for label previews and printing behind this acknowledgement, and provides build-time configuration for third-party service availability. Additionally, localized strings for the privacy notice have been added across all supported languages. There are no review comments to address, and I have no further feedback to provide.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.