jchapman/Immich-Bridge
Watch
1
0
Fork
You've already forked Immich-Bridge
 0
Code Issues 5 Pull requests 1 Projects Releases Packages 1 Wiki Activity Actions

Simplify migration workflow with collapsible stages and re-run analysis #25

New issue
Closed
opened 2026-10-31 17:06:06 +00:00 by jchapman · 13 comments
jchapman commented 2026-10-31 17:06:06 +00:00
Owner
Copy link

Problem

The deployed pilot migration page is still too busy. Completed upload controls, analysis controls/results, preview controls/results, import controls and email options compete in a long wall of information. Some options remain visible when the corresponding operation cannot even be started. A successfully completed analysis also has no usable way to run again against the retained ZIPs.

The preparation/onboarding flow already guides users through a sequence. Apply the same clarity to Upload → Analyze → Preview → Import, while keeping the stages and their saved information on one page. This should be a coordinated UI pass, not a collection of unrelated layout changes.

Requested changes

1. Add “Re-Run analysis”

  • Allow an owner to explicitly run analysis again after a successful analysis, using the collection's existing uploaded ZIPs. Large exports must not need to be uploaded again just to regenerate results after an application update.
  • Make the action available from the analysis section, including when the setup controls are collapsed.
  • Show the new run's status/progress and then its newly generated results. Do not silently return the previous completed job as though a new run started.
  • Respect existing ownership and active-operation protections. Do not overlap conflicting work, delete the collection/uploads, or automatically start a preview or write import.
  • Verify the backend retry/reset path as part of this work; a UI-only button is insufficient if the existing completed-job behavior still prevents a fresh analysis.

2. Show notification choices only when relevant

  • Show “Email me when my analysis is ready to review” with the applicable analysis launch/re-run or active-analysis controls.
  • Show “Email me when my preview is ready to approve” with the applicable preview controls.
  • Apply the same rule to the actual import's completion-email option.
  • Hide these opt-in controls once the corresponding operation is complete or when there is no relevant operation the user can start or manage. In particular, do not leave the analysis opt-in visible beside an old completed report when there is no way to run analysis.
  • Keep consent scoped to the specific operation. Collapsing sections or advancing stages must not create consent or carry an opt-in into another stage/new run.

3. Rebalance and collapse the upload section

  • On desktop, change Export Files : Upload Status to approximately 35% : 65% so the export files area is no longer squashed.
  • Preserve the current mobile arrangement; it is working well.
  • Once all expected uploads succeed, default the entire upload area to a collapsed state with a compact completion summary and a clear show/hide control.
  • Expanding the section must restore access to the received files/status without clearing upload state, detaching files or requiring reselection/reupload of completed ZIPs.

4. Separate the workflow into collapsible sections

Analysis, preview and import should not be one oversized container. Give setup/kickoff controls, saved results and the active operation clear boundaries and independently collapsible sections. For example:

  • Upload files and status.
  • Analysis setup/re-run controls.
  • Analysis results.
  • Preview setup.
  • Preview results.
  • Import setup and progress/results.

The exact visual treatment can be refined together, but each stage must be independently understandable and reopenable. Keep the data on the same page rather than moving it behind separate screens.

5. Progressively collapse completed or previous stages

  • After analysis runs, collapse its kickoff options and emphasize its results. Keep an obvious route back to the analysis controls so the user can re-run it.
  • Give analysis results their own collapsible section.
  • When a preview starts, collapse the analysis sections and emphasize the current preview/status.
  • When a preview completes, collapse its kickoff options and show preview results in their own section.
  • When import begins, collapse preview results and emphasize the active import/status.
  • Continue the same pattern through completion: previous information remains available, but it should not occupy the full page by default.
  • Users must be able to reopen prior sections without losing their place, selected options, uploaded files, results or history. Keep active progress, Stop controls and actionable errors discoverable as sections collapse.

Acceptance criteria

  • A previously completed collection can be analyzed again using its retained ZIPs, with a genuinely new run and refreshed analysis results, without reuploading the export.
  • Notification opt-ins appear only with the relevant available/active operation and disappear as actionable options when that operation is complete or unavailable.
  • Desktop Export Files/Upload Status use approximately 35%/65%; the existing mobile arrangement remains usable.
  • Successful uploads collapse into a compact summary and can be expanded again without losing files or progress.
  • Analysis setup/results, preview setup/results and import controls/progress have clear section boundaries and show/hide controls.
  • Stage transitions collapse earlier/completed sections according to the pattern above, keeping the current work clear and avoiding a wall of text.
  • Reopening sections preserves all existing collection state, results/history and operation settings; collapse/expand does not submit work or change notification consent.
  • Desktop and mobile walkthroughs cover an existing completed analysis, a re-run, preview completion, import startup, and recovery/error states. Validate staged-file reuse with fixtures without requiring a real large-library upload for every test.

Scope

Create a single coherent migration-workflow UI improvement. Keep the unmerged malware/security infrastructure work separate. This issue records the requested changes; it does not authorize changes to the live pilot's data or start any analysis, preview, import or deployment.

## Problem The deployed pilot migration page is still too busy. Completed upload controls, analysis controls/results, preview controls/results, import controls and email options compete in a long wall of information. Some options remain visible when the corresponding operation cannot even be started. A successfully completed analysis also has no usable way to run again against the retained ZIPs. The preparation/onboarding flow already guides users through a sequence. Apply the same clarity to **Upload → Analyze → Preview → Import**, while keeping the stages and their saved information on one page. This should be a coordinated UI pass, not a collection of unrelated layout changes. ## Requested changes ### 1. Add “Re-Run analysis” - Allow an owner to explicitly run analysis again after a successful analysis, using the collection's existing uploaded ZIPs. Large exports must not need to be uploaded again just to regenerate results after an application update. - Make the action available from the analysis section, including when the setup controls are collapsed. - Show the new run's status/progress and then its newly generated results. Do not silently return the previous completed job as though a new run started. - Respect existing ownership and active-operation protections. Do not overlap conflicting work, delete the collection/uploads, or automatically start a preview or write import. - Verify the backend retry/reset path as part of this work; a UI-only button is insufficient if the existing completed-job behavior still prevents a fresh analysis. ### 2. Show notification choices only when relevant - Show “Email me when my analysis is ready to review” with the applicable analysis launch/re-run or active-analysis controls. - Show “Email me when my preview is ready to approve” with the applicable preview controls. - Apply the same rule to the actual import's completion-email option. - Hide these opt-in controls once the corresponding operation is complete or when there is no relevant operation the user can start or manage. In particular, do not leave the analysis opt-in visible beside an old completed report when there is no way to run analysis. - Keep consent scoped to the specific operation. Collapsing sections or advancing stages must not create consent or carry an opt-in into another stage/new run. ### 3. Rebalance and collapse the upload section - On desktop, change **Export Files : Upload Status** to approximately **35% : 65%** so the export files area is no longer squashed. - Preserve the current mobile arrangement; it is working well. - Once all expected uploads succeed, default the entire upload area to a collapsed state with a compact completion summary and a clear show/hide control. - Expanding the section must restore access to the received files/status without clearing upload state, detaching files or requiring reselection/reupload of completed ZIPs. ### 4. Separate the workflow into collapsible sections Analysis, preview and import should not be one oversized container. Give setup/kickoff controls, saved results and the active operation clear boundaries and independently collapsible sections. For example: - Upload files and status. - Analysis setup/re-run controls. - Analysis results. - Preview setup. - Preview results. - Import setup and progress/results. The exact visual treatment can be refined together, but each stage must be independently understandable and reopenable. Keep the data on the same page rather than moving it behind separate screens. ### 5. Progressively collapse completed or previous stages - After analysis runs, collapse its kickoff options and emphasize its results. Keep an obvious route back to the analysis controls so the user can re-run it. - Give analysis results their own collapsible section. - When a preview starts, collapse the analysis sections and emphasize the current preview/status. - When a preview completes, collapse its kickoff options and show preview results in their own section. - When import begins, collapse preview results and emphasize the active import/status. - Continue the same pattern through completion: previous information remains available, but it should not occupy the full page by default. - Users must be able to reopen prior sections without losing their place, selected options, uploaded files, results or history. Keep active progress, Stop controls and actionable errors discoverable as sections collapse. ## Acceptance criteria - [ ] A previously completed collection can be analyzed again using its retained ZIPs, with a genuinely new run and refreshed analysis results, without reuploading the export. - [ ] Notification opt-ins appear only with the relevant available/active operation and disappear as actionable options when that operation is complete or unavailable. - [ ] Desktop Export Files/Upload Status use approximately 35%/65%; the existing mobile arrangement remains usable. - [ ] Successful uploads collapse into a compact summary and can be expanded again without losing files or progress. - [ ] Analysis setup/results, preview setup/results and import controls/progress have clear section boundaries and show/hide controls. - [ ] Stage transitions collapse earlier/completed sections according to the pattern above, keeping the current work clear and avoiding a wall of text. - [ ] Reopening sections preserves all existing collection state, results/history and operation settings; collapse/expand does not submit work or change notification consent. - [ ] Desktop and mobile walkthroughs cover an existing completed analysis, a re-run, preview completion, import startup, and recovery/error states. Validate staged-file reuse with fixtures without requiring a real large-library upload for every test. ## Scope Create a single coherent migration-workflow UI improvement. Keep the unmerged malware/security infrastructure work separate. This issue records the requested changes; it does not authorize changes to the live pilot's data or start any analysis, preview, import or deployment.
jchapman commented 2026-10-31 17:12:43 +00:00
Author
Owner
Copy link

Starting #25 after reading #14 and all its comments, and the full #25 scope (no existing comments). Working directly on main in a fresh checkout; the #12/PR #19 WIP branch and checkout remain untouched. Scope: independently collapsible upload/analysis/preview/import stages, stage-aware notification choices, preserved settings/state, desktop 35/65 upload layout, and an explicit protected backend analysis re-run using retained ZIPs. Validation will use disposable fixtures and desktop/mobile browser coverage plus focused backend checks. No pilot data, real analysis/import, deployment, restart or active-task interruption is planned.

Starting #25 after reading #14 and all its comments, and the full #25 scope (no existing comments). Working directly on main in a fresh checkout; the #12/PR #19 WIP branch and checkout remain untouched. Scope: independently collapsible upload/analysis/preview/import stages, stage-aware notification choices, preserved settings/state, desktop 35/65 upload layout, and an explicit protected backend analysis re-run using retained ZIPs. Validation will use disposable fixtures and desktop/mobile browser coverage plus focused backend checks. No pilot data, real analysis/import, deployment, restart or active-task interruption is planned.
jchapman commented 2026-10-31 17:22:54 +00:00
Author
Owner
Copy link

Implementation checkpoint on main: the existing completed-job route silently returned the old analysis, and the report query cache used only the collection ID. The new explicit re-run request checks the prior operation identity, creates fresh operation/timing state, clears old report/verification data, snapshots earlier notification outcomes, and reuses retained ZIPs. Admission shares the preview/import lock and the existing retention guard; concurrent duplicate re-runs, active preview/write conflicts, deletion admission, missing inputs and queue failures have regressions. No import is started by re-analysis. Independent sections keep mounted file/draft state; active progress/Stop stays visible, and terminal notification panels have no opt-in checkbox. Desktop 35/65 initially exposed narrow-rail clipping with expanded help; a scrollable rail and reserved list space fixed it, with the complete mobile/touch/keyboard suite passing. Backend/vet/race and workflow/activity/email/advanced browser checks pass locally; final disposable stack verification and handoff are in progress. Existing lockfile audit findings remain separate; no dependency or release-gate changes. No pilot data/service or #12/PR #19 source was touched.

Implementation checkpoint on main: the existing completed-job route silently returned the old analysis, and the report query cache used only the collection ID. The new explicit re-run request checks the prior operation identity, creates fresh operation/timing state, clears old report/verification data, snapshots earlier notification outcomes, and reuses retained ZIPs. Admission shares the preview/import lock and the existing retention guard; concurrent duplicate re-runs, active preview/write conflicts, deletion admission, missing inputs and queue failures have regressions. No import is started by re-analysis. Independent sections keep mounted file/draft state; active progress/Stop stays visible, and terminal notification panels have no opt-in checkbox. Desktop 35/65 initially exposed narrow-rail clipping with expanded help; a scrollable rail and reserved list space fixed it, with the complete mobile/touch/keyboard suite passing. Backend/vet/race and workflow/activity/email/advanced browser checks pass locally; final disposable stack verification and handoff are in progress. Existing lockfile audit findings remain separate; no dependency or release-gate changes. No pilot data/service or #12/PR #19 source was touched.
jchapman commented 2026-10-31 17:52:15 +00:00
Author
Owner
Copy link

Implemented and published directly on main at 7663404f7a, based on main 0a47f4f. The owner requested the next build label 0.1.1-pilot.1, explicitly a prerelease pilot, not 1.0. No #12/PR #19 source, branch, checkout, scanner image or scan was modified or used.

Changes:

  • Explicit Re-Run analysis remains available in the collapsed analysis heading. It uses retained ZIPs, checks the previous operation identity, rejects conflicting preview/import/cleanup work and concurrent stale requests, resets run timing/status/report/receipts, and generates a genuinely fresh worker result. Ordinary duplicate starts remain idempotent. Earlier notification outcomes are preserved transactionally; consent is not copied. Re-analysis does not start preview/import or change Immich.
  • Separate mounted Upload, Analysis setup/results, Preview setup/results and Import setup/results sections progressively collapse previous work. Reopening preserves received files/selection, draft import settings, reports/history and consent; worker stage changes do not re-collapse a section the user reopened. Active progress, confirmed Stop controls and request errors stay outside hidden setup sections. Historical results can be opened alongside current work.
  • Completed uploads default to a compact summary. Desktop file/status layout is 35/65; the narrow desktop rail remains scrollable with reserved file-list space, and the established mobile order is preserved.
  • Notification checkboxes appear only for the active operation. Completed results retain delivery feedback without actionable opt-in controls; new operations start without consent. Unavailable write-import controls are explained rather than offered for approval.
  • Documentation describes re-runs, stage transitions, validation and the pilot build label. The new browser suite is included in CI.

Checks actually passed locally:

  • Full backend tests and vet with the pinned importer; API/notification/analysis/import/deletion/authorization/diagnostics race gate and runner/auth/configuration/notification races. Final analysis timing/reset changes also passed the focused analysis race tests against the final source. Retained two-ZIP fixtures execute real verification/analysis, check refreshed cross-ZIP results and unchanged original ZIP bytes, with no automatic import.
  • UI lint/build and Docker Node 24 runtime build. Workflow tests at 1280/390/320px cover completed analysis, re-run, fresh results, preview completion, write startup, active Stop with historical results, preserved settings/consent, unavailable/rejected requests and offline/reconnect. Existing activity, email and advanced-import browser suites passed; the full 3/16-ZIP touch/keyboard/resize suite passed at 320/390/760/761/1280px.
  • The final-image disposable container/browser walkthrough passed: authentication/non-root execution, upload admission, replacement/resume/SHA-256 integrity, actual queue/SQLite reports, pause/stop/reselection, analysis, synthetic preview/private diagnostics, deletion/quota behavior and encrypted settings/restart. All disposable containers/networks/volumes were removed; no real Immich instance was contacted.
  • Nine CI policy tests, source/document/workflow contracts, diff checks, staged secret scan and redacted full-history scan passed.

Limits and next handoff:

  • Source is published on main. Registry images have not been published and the pilot has not been deployed/restarted. Native final-main CI currently has 13 pending contexts; no native dual-architecture or aggregate release-gate success is claimed.
  • The unchanged npm lockfile currently reports 13 audit advisories (12 moderate, one high). Dependency versions and security baselines/gates were not changed or waived. The existing bundle-size advisory remains. Physical-device, provider/relay and real-library/performance checks remain separate.
  • Companion infrastructure build/deployment preparation is published. It selects this exact reviewed main SHA, documents version 0.1.1-pilot.1 with unchanged importer 0.32.0-bridge.4, and will export a three-image immutable-digest environment fragment after successful native publication. Its 11 pilot, nine workflow and six lifecycle tests, Ansible syntax/lint, synthetic Compose/missing-digest checks and staged secret scan passed. No native build or rollout was dispatched, and the current encrypted deployment environment was retained.
  • Next: review the main changes, complete native validation and publish the named pilot build, then copy the three reviewed output digests into the existing encrypted deployment environment and coordinate an idle deployment plus pilot checks. This issue remains open for owner review; implementation, source publication, image publication and deployment are deliberately recorded as separate states.
Implemented and published directly on main at 7663404f7a66a4da49cb1304a449d4781be45cc2, based on main 0a47f4f. The owner requested the next build label **0.1.1-pilot.1**, explicitly a prerelease pilot, not 1.0. No #12/PR #19 source, branch, checkout, scanner image or scan was modified or used. Changes: - Explicit Re-Run analysis remains available in the collapsed analysis heading. It uses retained ZIPs, checks the previous operation identity, rejects conflicting preview/import/cleanup work and concurrent stale requests, resets run timing/status/report/receipts, and generates a genuinely fresh worker result. Ordinary duplicate starts remain idempotent. Earlier notification outcomes are preserved transactionally; consent is not copied. Re-analysis does not start preview/import or change Immich. - Separate mounted Upload, Analysis setup/results, Preview setup/results and Import setup/results sections progressively collapse previous work. Reopening preserves received files/selection, draft import settings, reports/history and consent; worker stage changes do not re-collapse a section the user reopened. Active progress, confirmed Stop controls and request errors stay outside hidden setup sections. Historical results can be opened alongside current work. - Completed uploads default to a compact summary. Desktop file/status layout is 35/65; the narrow desktop rail remains scrollable with reserved file-list space, and the established mobile order is preserved. - Notification checkboxes appear only for the active operation. Completed results retain delivery feedback without actionable opt-in controls; new operations start without consent. Unavailable write-import controls are explained rather than offered for approval. - Documentation describes re-runs, stage transitions, validation and the pilot build label. The new browser suite is included in CI. Checks actually passed locally: - Full backend tests and vet with the pinned importer; API/notification/analysis/import/deletion/authorization/diagnostics race gate and runner/auth/configuration/notification races. Final analysis timing/reset changes also passed the focused analysis race tests against the final source. Retained two-ZIP fixtures execute real verification/analysis, check refreshed cross-ZIP results and unchanged original ZIP bytes, with no automatic import. - UI lint/build and Docker Node 24 runtime build. Workflow tests at 1280/390/320px cover completed analysis, re-run, fresh results, preview completion, write startup, active Stop with historical results, preserved settings/consent, unavailable/rejected requests and offline/reconnect. Existing activity, email and advanced-import browser suites passed; the full 3/16-ZIP touch/keyboard/resize suite passed at 320/390/760/761/1280px. - The final-image disposable container/browser walkthrough passed: authentication/non-root execution, upload admission, replacement/resume/SHA-256 integrity, actual queue/SQLite reports, pause/stop/reselection, analysis, synthetic preview/private diagnostics, deletion/quota behavior and encrypted settings/restart. All disposable containers/networks/volumes were removed; no real Immich instance was contacted. - Nine CI policy tests, source/document/workflow contracts, diff checks, staged secret scan and redacted full-history scan passed. Limits and next handoff: - Source is published on main. Registry images have not been published and the pilot has not been deployed/restarted. Native final-main CI currently has 13 pending contexts; no native dual-architecture or aggregate release-gate success is claimed. - The unchanged npm lockfile currently reports 13 audit advisories (12 moderate, one high). Dependency versions and security baselines/gates were not changed or waived. The existing bundle-size advisory remains. Physical-device, provider/relay and real-library/performance checks remain separate. - Companion infrastructure build/deployment preparation is published. It selects this exact reviewed main SHA, documents version 0.1.1-pilot.1 with unchanged importer 0.32.0-bridge.4, and will export a three-image immutable-digest environment fragment after successful native publication. Its 11 pilot, nine workflow and six lifecycle tests, Ansible syntax/lint, synthetic Compose/missing-digest checks and staged secret scan passed. No native build or rollout was dispatched, and the current encrypted deployment environment was retained. - Next: review the main changes, complete native validation and publish the named pilot build, then copy the three reviewed output digests into the existing encrypted deployment environment and coordinate an idle deployment plus pilot checks. This issue remains open for owner review; implementation, source publication, image publication and deployment are deliberately recorded as separate states.
jchapman commented 2026-10-31 18:05:46 +00:00
Author
Owner
Copy link

Owner-requested publication update: pilot 0.1.1-pilot.1 is now published for Linux ARM64 from main 7663404f7a, with unchanged importer 0.32.0-bridge.4. The native pipeline passed backend/race, runner-race, browser-upload-client and actual-importer targets, built/published app + runner + processor, verified runtime/license material, and published matching Bridge/importer source with checksums. Independent registry inspection confirms the exact version, source SHA and ARM64 architecture on all three images; reported and registry digests agree. Companion deployment image pins are updated and configuration validation passed, with every other encrypted setting preserved. This supersedes the earlier image-publication-pending status only. No live deployment, service restart, real import or #12/PR #19 modification occurred. This remains a prerelease pilot; full dual-architecture/image release gates and installed-provider/library checks remain separate.

Owner-requested publication update: pilot **0.1.1-pilot.1** is now published for Linux ARM64 from main 7663404f7a66a4da49cb1304a449d4781be45cc2, with unchanged importer 0.32.0-bridge.4. The native pipeline passed backend/race, runner-race, browser-upload-client and actual-importer targets, built/published app + runner + processor, verified runtime/license material, and published matching Bridge/importer source with checksums. Independent registry inspection confirms the exact version, source SHA and ARM64 architecture on all three images; reported and registry digests agree. Companion deployment image pins are updated and configuration validation passed, with every other encrypted setting preserved. This supersedes the earlier image-publication-pending status only. No live deployment, service restart, real import or #12/PR #19 modification occurred. This remains a prerelease pilot; full dual-architecture/image release gates and installed-provider/library checks remain separate.
jchapman commented 2026-10-31 18:11:24 +00:00
Author
Owner
Copy link

Owner explicitly authorized deployment after the latest companion infrastructure validation completed. That exact validation passed, and the deployment of pilot 0.1.1-pilot.1 to the authorized pilot target has now succeeded using the three reviewed immutable image pins. Independent post-deployment public HTTPS checks return 200 Ready, and the served application bundle contains Re-Run analysis, Analysis setup and Preview results from main 7663404f7a. The registered mount-guarded lifecycle completed without failed/unreachable tasks. No owner analysis, preview or import was started for verification, and no #12/PR #19 work was touched. This supersedes the earlier deployment-pending status only. Native ARM64 pilot publication/deployment is complete; full dual-architecture/image release gates, dependency audit follow-up and authenticated real-provider/relay/library walkthroughs remain separate. No 1.0 release or full-library success is claimed.

Owner explicitly authorized deployment after the latest companion infrastructure validation completed. That exact validation passed, and the deployment of pilot **0.1.1-pilot.1** to the authorized pilot target has now succeeded using the three reviewed immutable image pins. Independent post-deployment public HTTPS checks return 200 Ready, and the served application bundle contains Re-Run analysis, Analysis setup and Preview results from main 7663404f7a66a4da49cb1304a449d4781be45cc2. The registered mount-guarded lifecycle completed without failed/unreachable tasks. No owner analysis, preview or import was started for verification, and no #12/PR #19 work was touched. This supersedes the earlier deployment-pending status only. Native ARM64 pilot publication/deployment is complete; full dual-architecture/image release gates, dependency audit follow-up and authenticated real-provider/relay/library walkthroughs remain separate. No 1.0 release or full-library success is claimed.
jchapman commented 2026-10-31 19:14:44 +00:00
Author
Owner
Copy link

Issues found from the latest build:

  1. The "Email me when my analysis is ready to review" is not clickable
    2. This may be because the SSO connection is not registering an email address? I have no way to see what the actual username and email address is inside the admin console. We need to verify if this is blocked by UI or blocked by no email. If it's because of no email, 2 changes need made:
    3. Expose the SSO provided information through the admin UI, not just the ability to make a user an admin or disable the account. Without being able to see the information, there's no way to validate if the information came through correctly.
    4. Enable the ability for the SSO connection to update the username/email of a user after it has been created. The test user was created before updates were made so it's still listed as "SSO user"
  2. The collapsible sections didn't seem to make it over to mobile. While the analysis was running, all the rest of the sections below it were still open.
  3. Text and spacing is quite....rough....throughout the page, with buttons not having space above/below when at the bottom of sections, paragraphs not getting enough space and different sized texts seemingly with no reason. Section headings should stand out, not be the same size as the text without being overpowering.
  4. The verbiage used when a process is running is a bit odd - bring up each "in progress" text during the next build so I can provide the text that would make more sense.
  5. In the analysis, the use of the word "candidate" feels way too technical and is very AI/System Admin verbiage
  6. It may be worthwhile to create groups that can be fully collapsed to continue to help organize the page and not have it continue to be busy. If we do this, having some sort of navigation at the top to show where in the process you current are and jump to that section would be helpful, so a secondary workflow stepper of some sort? - analyze this before implementation
    10. Collections
    11. Upload
    12. Analysis
    13. Import Preview
    14. Import
  7. If a user steps back a step, immediately close all further steps. Example: Re-Run analysis would automatically close the preview or import steps and would not re-open until the user is ready to actually do those, in order
  8. Add a Next Step: [Stage] button to each "Next: " section so it requires user input to open the next section while closing the one you're on. Again, making this more of a step-by-step flow.
Issues found from the latest build: 1. The "Email me when my analysis is ready to review" is not clickable 2. This may be because the SSO connection is not registering an email address? I have no way to see what the actual username and email address is inside the admin console. We need to verify if this is blocked by UI or blocked by no email. If it's because of no email, 2 changes need made: 3. Expose the SSO provided information through the admin UI, not just the ability to make a user an admin or disable the account. Without being able to see the information, there's no way to validate if the information came through correctly. 4. Enable the ability for the SSO connection to update the username/email of a user after it has been created. The test user was created before updates were made so it's still listed as "SSO user" 5. The collapsible sections didn't seem to make it over to mobile. While the analysis was running, all the rest of the sections below it were still open. 6. Text and spacing is quite....rough....throughout the page, with buttons not having space above/below when at the bottom of sections, paragraphs not getting enough space and different sized texts seemingly with no reason. Section headings should stand out, not be the same size as the text without being overpowering. 7. The verbiage used when a process is running is a bit odd - bring up each "in progress" text during the next build so I can provide the text that would make more sense. 8. In the analysis, the use of the word "candidate" feels way too technical and is very AI/System Admin verbiage 9. It may be worthwhile to create groups that can be fully collapsed to continue to help organize the page and not have it continue to be busy. If we do this, having some sort of navigation at the top to show where in the process you current are and jump to that section would be helpful, so a secondary workflow stepper of some sort? - analyze this before implementation 10. Collections 11. Upload 12. Analysis 13. Import Preview 14. Import 15. If a user steps back a step, immediately close all further steps. Example: Re-Run analysis would automatically close the preview or import steps and would not re-open until the user is ready to actually do those, in order 16. Add a Next Step: [Stage] button to each "Next: " section so it requires user input to open the next section while closing the one you're on. Again, making this more of a step-by-step flow.
jchapman commented 2026-10-31 19:28:38 +00:00
Author
Owner
Copy link

Starting the owner-approved follow-up to comment 611. Scope: diagnose disabled task-email consent; expose bounded SSO profile/verification/refresh information in administration and correct existing-account refresh; introduce centrally controlled Collections → Upload → Analysis → Import Preview → Import groups with explicit Next Step progression/backward collapse; preserve active Stop/status and saved state; normalize spacing/headings and simplify preliminary metadata language. Active-task background guidance will use the owner-provided exact text. Validation will cover legacy SSO users, notification denial reasons, historical links/re-analysis, backward navigation, refresh/reconnect and desktop/mobile fixtures. Working from main, keeping #12/PR #19 separate. No live analysis/import or deployment is started by this implementation.

Starting the owner-approved follow-up to comment 611. Scope: diagnose disabled task-email consent; expose bounded SSO profile/verification/refresh information in administration and correct existing-account refresh; introduce centrally controlled Collections → Upload → Analysis → Import Preview → Import groups with explicit Next Step progression/backward collapse; preserve active Stop/status and saved state; normalize spacing/headings and simplify preliminary metadata language. Active-task background guidance will use the owner-provided exact text. Validation will cover legacy SSO users, notification denial reasons, historical links/re-analysis, backward navigation, refresh/reconnect and desktop/mobile fixtures. Working from main, keeping #12/PR #19 separate. No live analysis/import or deployment is started by this implementation.
jchapman commented 2026-10-31 19:59:10 +00:00
Author
Owner
Copy link

Implemented and published the owner-approved follow-up to comment 611 on main: cc91065266214916b9b11b46c7ae17010278d6c0. Issue #12 and WIP PR #19 remain separate and untouched.

Changes:

  • One controller now governs Collections → Upload → Analysis → Import Preview → Import on desktop and mobile. Explicit Next Step buttons advance without starting work; going back closes later groups. Re-running analysis keeps preview/import closed until manually advanced, including after historical links, reload and reconnect. Mounted groups preserve file selection, draft options, history and per-operation consent. Active analysis/preview/import status and Stop controls remain reachable outside hidden group bodies.
  • Consistent group headings, paragraph/control spacing and responsive workflow navigation; preliminary analysis now says possible metadata matches/no matching metadata/multiple possible matches without changing matching semantics.
  • Active tasks use the exact approved paragraph: “This task will continue in the background. You can close this page and return later. If you enabled email notifications, we’ll let you know when it’s finished.” Timing/heartbeat/restart limitations are under Task timing and connection details; stale-status alerts and Stop remain visible.
  • Disabled task-email choices now show an accessible reason and guidance for a missing verified SSO email. Terminal tasks retain delivery outcomes without empty opt-in panels.
  • Administration exposes bounded provider username/name/email/verification, notification eligibility, issuer, source, last profile refresh and safe diagnostic status. Refresh user information also updates an already-open user detail. A fresh SSO sign-in refreshes the existing account; its issuer+subject identity, roles and collections are preserved. Optional UserInfo fallback is HTTPS-only, nonredirecting, deadline/body bounded and subject matched. Explicit signed unverified email cannot be upgraded by conflicting UserInfo. Tokens/raw claim documents are not retained or exposed.

Read-only deployed diagnosis confirmed the affected SSO profile had no eligible verified notification email and retained the fallback display name; the SMTP host was configured. This establishes an account-data eligibility blocker, not an inbox-delivery result or proof that the provider never sends email. A real fresh provider sign-in after a future rollout is still required to verify the provider's current claims. The diagnostic session was revoked; no live task/settings were changed.

Validation passed locally on Linux AMD64 Docker/desktop browser tooling: complete backend tests and Go vet with the real pinned importer; focused API/auth/configuration/notification/runner race checks; UI lint/build; SSO profile, activity, email, advanced-options and mobile-file-list browser suites; guided-flow regression at 1280/390/320px; complete disposable container/browser walkthrough with real queue/SQLite, container-replacement upload recovery/SHA-256, full-set analysis, history/results, administration, logout and encrypted-settings restart; nine policy/contract tests and source/document checks; redacted staged/full-history secret scans. The smoke walkthrough was updated to use collapsed-group navigation and disambiguate the additional notification status region. Disposable stack containers/networks/volumes were removed.

Security/release limits: refreshed gosec policy passes with 29 existing findings and no new findings or baseline expansion. govulncheck is blocked by new module-only GO-2026-6860 and GO-2026-6866 advisories against unchanged x/net v0.61.0 pins (fixed in v0.62.0); it reports no affected package/function trace for them. The retained npm audit reports 13 advisories (12 moderate, one high) in the unchanged lockfile. Existing release gates/baselines have not been waived or weakened. Local checks do not establish native ARM64 release clearance, physical-device behavior, real-provider email/inbox delivery or large-library performance.

Other current running-state text, retained for owner wording review:

  • Analysis stages: “Waiting for worker”, “Checking ZIP integrity”, “Matching photos and metadata”.
  • Preview/import verification: “Rechecking ZIP integrity”; running labels: “Running read-only preview”, “Importing into Immich”.
  • Group summaries: “Analysis is running.”, “Preview is running.”, “Import is running.” Analysis setup: “Analysis is running — follow its progress below.” Request state: “Requesting a new analysis…”.
  • Stop: “Stopping…”, “A stop has been requested. You can close this page and return to check the confirmed result.” and “Waiting for worker exit and cleanup confirmation. Completion may win a late stop request.”
  • Unknown status: “Waiting for confirmed status” and “Checking the saved server status. Closing this page does not cancel server work.”

State: source published; this follow-up has NOT been image-published or deployed. The existing 0.1.1-pilot.1 installation/digests remain unchanged and must not be relabeled with different contents. Next: resolve dependency release blockers and choose a new pilot build identity, then coordinate any requested build/rollout and verify fresh real SSO sign-in plus owner email consent. #25 stays open for the remaining release/deployed verification.

Implemented and published the owner-approved follow-up to comment 611 on main: [cc91065266214916b9b11b46c7ae17010278d6c0](https://git.sharedroot.net/jchapman/Immich-Bridge/commit/cc91065266214916b9b11b46c7ae17010278d6c0). Issue #12 and WIP PR #19 remain separate and untouched. Changes: - One controller now governs Collections → Upload → Analysis → Import Preview → Import on desktop and mobile. Explicit Next Step buttons advance without starting work; going back closes later groups. Re-running analysis keeps preview/import closed until manually advanced, including after historical links, reload and reconnect. Mounted groups preserve file selection, draft options, history and per-operation consent. Active analysis/preview/import status and Stop controls remain reachable outside hidden group bodies. - Consistent group headings, paragraph/control spacing and responsive workflow navigation; preliminary analysis now says possible metadata matches/no matching metadata/multiple possible matches without changing matching semantics. - Active tasks use the exact approved paragraph: “This task will continue in the background. You can close this page and return later. If you enabled email notifications, we’ll let you know when it’s finished.” Timing/heartbeat/restart limitations are under Task timing and connection details; stale-status alerts and Stop remain visible. - Disabled task-email choices now show an accessible reason and guidance for a missing verified SSO email. Terminal tasks retain delivery outcomes without empty opt-in panels. - Administration exposes bounded provider username/name/email/verification, notification eligibility, issuer, source, last profile refresh and safe diagnostic status. Refresh user information also updates an already-open user detail. A fresh SSO sign-in refreshes the existing account; its issuer+subject identity, roles and collections are preserved. Optional UserInfo fallback is HTTPS-only, nonredirecting, deadline/body bounded and subject matched. Explicit signed unverified email cannot be upgraded by conflicting UserInfo. Tokens/raw claim documents are not retained or exposed. Read-only deployed diagnosis confirmed the affected SSO profile had no eligible verified notification email and retained the fallback display name; the SMTP host was configured. This establishes an account-data eligibility blocker, not an inbox-delivery result or proof that the provider never sends email. A real fresh provider sign-in after a future rollout is still required to verify the provider's current claims. The diagnostic session was revoked; no live task/settings were changed. Validation passed locally on Linux AMD64 Docker/desktop browser tooling: complete backend tests and Go vet with the real pinned importer; focused API/auth/configuration/notification/runner race checks; UI lint/build; SSO profile, activity, email, advanced-options and mobile-file-list browser suites; guided-flow regression at 1280/390/320px; complete disposable container/browser walkthrough with real queue/SQLite, container-replacement upload recovery/SHA-256, full-set analysis, history/results, administration, logout and encrypted-settings restart; nine policy/contract tests and source/document checks; redacted staged/full-history secret scans. The smoke walkthrough was updated to use collapsed-group navigation and disambiguate the additional notification status region. Disposable stack containers/networks/volumes were removed. Security/release limits: refreshed gosec policy passes with 29 existing findings and no new findings or baseline expansion. govulncheck is blocked by new module-only GO-2026-6860 and GO-2026-6866 advisories against unchanged x/net v0.61.0 pins (fixed in v0.62.0); it reports no affected package/function trace for them. The retained npm audit reports 13 advisories (12 moderate, one high) in the unchanged lockfile. Existing release gates/baselines have not been waived or weakened. Local checks do not establish native ARM64 release clearance, physical-device behavior, real-provider email/inbox delivery or large-library performance. Other current running-state text, retained for owner wording review: - Analysis stages: “Waiting for worker”, “Checking ZIP integrity”, “Matching photos and metadata”. - Preview/import verification: “Rechecking ZIP integrity”; running labels: “Running read-only preview”, “Importing into Immich”. - Group summaries: “Analysis is running.”, “Preview is running.”, “Import is running.” Analysis setup: “Analysis is running — follow its progress below.” Request state: “Requesting a new analysis…”. - Stop: “Stopping…”, “A stop has been requested. You can close this page and return to check the confirmed result.” and “Waiting for worker exit and cleanup confirmation. Completion may win a late stop request.” - Unknown status: “Waiting for confirmed status” and “Checking the saved server status. Closing this page does not cancel server work.” State: source published; this follow-up has NOT been image-published or deployed. The existing 0.1.1-pilot.1 installation/digests remain unchanged and must not be relabeled with different contents. Next: resolve dependency release blockers and choose a new pilot build identity, then coordinate any requested build/rollout and verify fresh real SSO sign-in plus owner email consent. #25 stays open for the remaining release/deployed verification.
jchapman commented 2026-10-31 20:04:41 +00:00
Author
Owner
Copy link

Starting the owner-requested dependency-advisory remediation before the next pilot build. Scope: refresh advisory data, update affected Go/npm dependencies with the smallest compatible changes, verify actual importer/runtime dependency exposure, and run dependency/security plus relevant backend/browser checks. Existing gates remain in force; no baseline expansion, #12/WIP integration, release-image publication or live deployment is part of this remediation.

Starting the owner-requested dependency-advisory remediation before the next pilot build. Scope: refresh advisory data, update affected Go/npm dependencies with the smallest compatible changes, verify actual importer/runtime dependency exposure, and run dependency/security plus relevant backend/browser checks. Existing gates remain in force; no baseline expansion, #12/WIP integration, release-image publication or live deployment is part of this remediation.
jchapman commented 2026-10-31 20:41:23 +00:00
Author
Owner
Copy link

Dependency remediation is published on main in a279a1bd77c0f600f705856077b6a6312457b87b, following the guided-workflow commit cc91065. The owner has now requested a native 0.1.2-pilot.1 build, digest-pinned SOPS/Compose update and APP-02 rollout after validation.

Fixed pins: x/net v0.62.0, go-jose/v4 v4.1.6, Echo/v4 v4.16.3, follow-redirects 1.16.2 and minimatch 11.0.1. Fresh npm audit reports zero advisories. The minimatch override is development tooling only; TS/TSX lint selection, actual rule errors and generated-asset exclusions were checked. A loopback cross-realm redirect test confirms synthetic credentials are stripped. Go JOSE's upstream 4096-bit JWK RSA bound is retained.

The fresh image database additionally identified the JOSE/Echo advisories that were absent from govulncheck, plus unfixed Debian CVE-2026-84243. All three images explicitly default to the C locale and empty LANGUAGE; actual Docker isolation checks confirm processor defaults even with hostile controller locale values. The Debian tracker has no fixed package. Two exact libc-bin/libc6 2.41-12+deb13u4 records are therefore reviewed as OPEN, not patched, with rationale/limits in the committed Debian triage record. This is a scoped change from the initial no-baseline-expansion approach because the refreshed image inventory revealed a new unfixed distribution advisory. No source/Go-advisory exception was added or policy logic relaxed; a newly available fix or unknown package version still blocks policy. Existing unused OpenPGP module-only exception remains unchanged.

Final local validation: full backend/vet and focused API/auth/configuration/notification/runner races pass; actual Docker isolation/locale inspection passes; UI clean install/lint/build and focused browser checks pass; guided workflow passes at 1280/390/320px; complete disposable container/browser walkthrough and production-mode HTTPS/proxy/origin/cookie/upload/readiness/recovery checks pass. One backend attempt exceeded its existing 120-second package limit under concurrent load; the unchanged-limit retry and final test build pass. The terminal-email browser fixture was corrected to use a real terminal delivery state and now checks OFF panels disappear. Nine source contracts/policy tests and staged/full-history secret scans pass. Fresh gosec retains 29 reviewed findings across 43 production files without new findings; source/importer vulnerability policies and all three runtime image policies pass, preserving raw findings and reviewed open items.

The infrastructure native build is being updated to enforce the selected source's pinned source/importer/final-image advisory policies before publication and to retain exact checked image identities. Deployment is also getting a read-only saved-task idle check immediately before restart. No release image or rollout is claimed yet; source remains separate from build/deployment. #12/PR #19 are untouched. Further build/digest/deployment evidence will follow here after the authorized workflow completes.

Dependency remediation is published on main in [a279a1bd77c0f600f705856077b6a6312457b87b](https://git.sharedroot.net/jchapman/Immich-Bridge/commit/a279a1bd77c0f600f705856077b6a6312457b87b), following the guided-workflow commit cc91065. The owner has now requested a native 0.1.2-pilot.1 build, digest-pinned SOPS/Compose update and APP-02 rollout after validation. Fixed pins: x/net v0.62.0, go-jose/v4 v4.1.6, Echo/v4 v4.16.3, follow-redirects 1.16.2 and minimatch 11.0.1. Fresh npm audit reports zero advisories. The minimatch override is development tooling only; TS/TSX lint selection, actual rule errors and generated-asset exclusions were checked. A loopback cross-realm redirect test confirms synthetic credentials are stripped. Go JOSE's upstream 4096-bit JWK RSA bound is retained. The fresh image database additionally identified the JOSE/Echo advisories that were absent from govulncheck, plus unfixed Debian CVE-2026-84243. All three images explicitly default to the C locale and empty LANGUAGE; actual Docker isolation checks confirm processor defaults even with hostile controller locale values. The Debian tracker has no fixed package. Two exact libc-bin/libc6 2.41-12+deb13u4 records are therefore reviewed as OPEN, not patched, with rationale/limits in the committed Debian triage record. This is a scoped change from the initial no-baseline-expansion approach because the refreshed image inventory revealed a new unfixed distribution advisory. No source/Go-advisory exception was added or policy logic relaxed; a newly available fix or unknown package version still blocks policy. Existing unused OpenPGP module-only exception remains unchanged. Final local validation: full backend/vet and focused API/auth/configuration/notification/runner races pass; actual Docker isolation/locale inspection passes; UI clean install/lint/build and focused browser checks pass; guided workflow passes at 1280/390/320px; complete disposable container/browser walkthrough and production-mode HTTPS/proxy/origin/cookie/upload/readiness/recovery checks pass. One backend attempt exceeded its existing 120-second package limit under concurrent load; the unchanged-limit retry and final test build pass. The terminal-email browser fixture was corrected to use a real terminal delivery state and now checks OFF panels disappear. Nine source contracts/policy tests and staged/full-history secret scans pass. Fresh gosec retains 29 reviewed findings across 43 production files without new findings; source/importer vulnerability policies and all three runtime image policies pass, preserving raw findings and reviewed open items. The infrastructure native build is being updated to enforce the selected source's pinned source/importer/final-image advisory policies before publication and to retain exact checked image identities. Deployment is also getting a read-only saved-task idle check immediately before restart. No release image or rollout is claimed yet; source remains separate from build/deployment. #12/PR #19 are untouched. Further build/digest/deployment evidence will follow here after the authorized workflow completes.
jchapman commented 2026-10-31 21:25:23 +00:00
Author
Owner
Copy link

0.1.2-pilot.1 is published and deployed to APP-02 at the owner's explicit request.

  • Application source: a279a1bd77c0f600f705856077b6a6312457b87b, including the cc91065 guided-workflow/SSO follow-up and dependency remediation described in comment 632. Importer remains 0.32.0-bridge.4; #12/PR #19 are untouched.
  • Infrastructure build/security/idle guards: 6c03ba07446f692b07aa857c0e5cf22e731e888e.
  • Native ARM64 build #257 passed backend/race/upload-client/actual-importer targets, matching-source checks, and fresh pinned Go/npm/importer/all-three-image advisory policies BEFORE publication. Native security reports and checked image identities are retained with build 310-1. Anonymous independent registry reads verified the exact version, source revision, Linux ARM64 platform, C-locale defaults, immutable digest/config content and public source/checksums.
  • Compose/example/SOPS pins and documentation: a7a3f877fb1fb5c64fb951712b9516638eb6bcdb. Only the three image values changed in the decrypted SOPS settings; every other value, including the stable credential encryption key, was compared and preserved. Effective Compose rendering verifies the three digests, the runner's processor reference and the registered local state path. Pilot/lifecycle/workflow/public-tree tests pass; syntax/lint and redacted secret checks pass.
  • Preview #259 passed with the expected two configuration changes. Apply #260 passed for the exact same a7a3f87 revision. The read-only saved-task idle guard passed immediately before the registered lifecycle restart; the play recap has zero failures/unreachable hosts. No analysis/import was started or cancelled by this rollout.

Published immutable image digests:

  • app: sha256:81f8413ea92350b5eb820c085417752dd04fb914dd8c5ab8c593d8e0078487b4
  • runner: sha256:defb00ec2cbcdac6d11eeb33cea920051e6503037075286341366aabbb4294f4
  • processor: sha256:6a267c8eefdc77183b80ab6e72e971ec333528b937d1eae5a7725604b68f02a3

Post-rollout checks: public HTTPS readiness is 200 Ready; the served bundle is index-qmyTMtxO.js and contains the new stepper/background guidance. Both local recovery and SSO availability are confirmed. Recovery-admin sign-in, retained SSO accounts, new provider-diagnostic DTO fields and applied saved settings were verified read-only, then the diagnostic session was revoked. The configured provider's public RSA keys fit the patched JOSE bound (2048 bits). These are not a fresh owner SSO callback or inbox-delivery test.

Next owner check: sign out and sign in THROUGH SSO to refresh the legacy account's provider claims, then inspect username/email/verification and last refresh in administration and choose per-task email consent if available. Existing sessions intentionally do not fetch new provider claims. Physical-device behavior, actual relay/inbox outcomes, representative library/performance acceptance and full dual-architecture release gates remain separate. Reviewed unfixed distribution findings, including the new scoped glibc disposition, remain open; no claim of zero scanner findings, blanket waiver or true 1.0 readiness is made. The already published 0.1.1-pilot.1 and 0.1.2-pilot.1 versions must not be reused. #25 stays open for the remaining owner verification and wording review.

0.1.2-pilot.1 is published and deployed to APP-02 at the owner's explicit request. - Application source: [a279a1bd77c0f600f705856077b6a6312457b87b](https://git.sharedroot.net/jchapman/Immich-Bridge/commit/a279a1bd77c0f600f705856077b6a6312457b87b), including the cc91065 guided-workflow/SSO follow-up and dependency remediation described in comment 632. Importer remains 0.32.0-bridge.4; #12/PR #19 are untouched. - Infrastructure build/security/idle guards: [6c03ba07446f692b07aa857c0e5cf22e731e888e](https://git.sharedroot.net/jchapman/sharedroot-infrastructure/commit/6c03ba07446f692b07aa857c0e5cf22e731e888e). - [Native ARM64 build #257](https://git.sharedroot.net/jchapman/sharedroot-infrastructure/actions/runs/257) passed backend/race/upload-client/actual-importer targets, matching-source checks, and fresh pinned Go/npm/importer/all-three-image advisory policies BEFORE publication. Native security reports and checked image identities are retained with build 310-1. Anonymous independent registry reads verified the exact version, source revision, Linux ARM64 platform, C-locale defaults, immutable digest/config content and public source/checksums. - Compose/example/SOPS pins and documentation: [a7a3f877fb1fb5c64fb951712b9516638eb6bcdb](https://git.sharedroot.net/jchapman/sharedroot-infrastructure/commit/a7a3f877fb1fb5c64fb951712b9516638eb6bcdb). Only the three image values changed in the decrypted SOPS settings; every other value, including the stable credential encryption key, was compared and preserved. Effective Compose rendering verifies the three digests, the runner's processor reference and the registered local state path. Pilot/lifecycle/workflow/public-tree tests pass; syntax/lint and redacted secret checks pass. - [Preview #259](https://git.sharedroot.net/jchapman/sharedroot-infrastructure/actions/runs/259) passed with the expected two configuration changes. [Apply #260](https://git.sharedroot.net/jchapman/sharedroot-infrastructure/actions/runs/260) passed for the exact same a7a3f87 revision. The read-only saved-task idle guard passed immediately before the registered lifecycle restart; the play recap has zero failures/unreachable hosts. No analysis/import was started or cancelled by this rollout. Published immutable image digests: - app: sha256:81f8413ea92350b5eb820c085417752dd04fb914dd8c5ab8c593d8e0078487b4 - runner: sha256:defb00ec2cbcdac6d11eeb33cea920051e6503037075286341366aabbb4294f4 - processor: sha256:6a267c8eefdc77183b80ab6e72e971ec333528b937d1eae5a7725604b68f02a3 Post-rollout checks: public HTTPS readiness is 200 Ready; the served bundle is index-qmyTMtxO.js and contains the new stepper/background guidance. Both local recovery and SSO availability are confirmed. Recovery-admin sign-in, retained SSO accounts, new provider-diagnostic DTO fields and applied saved settings were verified read-only, then the diagnostic session was revoked. The configured provider's public RSA keys fit the patched JOSE bound (2048 bits). These are not a fresh owner SSO callback or inbox-delivery test. Next owner check: sign out and sign in THROUGH SSO to refresh the legacy account's provider claims, then inspect username/email/verification and last refresh in administration and choose per-task email consent if available. Existing sessions intentionally do not fetch new provider claims. Physical-device behavior, actual relay/inbox outcomes, representative library/performance acceptance and full dual-architecture release gates remain separate. Reviewed unfixed distribution findings, including the new scoped glibc disposition, remain open; no claim of zero scanner findings, blanket waiver or true 1.0 readiness is made. The already published 0.1.1-pilot.1 and 0.1.2-pilot.1 versions must not be reused. #25 stays open for the remaining owner verification and wording review.
jchapman commented 2026-10-31 21:26:29 +00:00
Author
Owner
Copy link

Owner verification after the 0.1.2-pilot.1 rollout: signing out and back in through SSO now displays the expected name, and the analysis email checkbox is interactive. This confirms the fresh-login profile-refresh and notification-eligibility checkpoints from comment 641. The owner is waiting for the current analysis to finish to check the notification. Completion-email sending/relay acceptance/inbox delivery are not yet verified; #25 remains open for that outcome and the remaining owner review. No additional task, test email or deployment was started.

Owner verification after the 0.1.2-pilot.1 rollout: signing out and back in through SSO now displays the expected name, and the analysis email checkbox is interactive. This confirms the fresh-login profile-refresh and notification-eligibility checkpoints from comment 641. The owner is waiting for the current analysis to finish to check the notification. Completion-email sending/relay acceptance/inbox delivery are not yet verified; #25 remains open for that outcome and the remaining owner review. No additional task, test email or deployment was started.
jchapman commented 2026-10-31 21:59:49 +00:00
Author
Owner
Copy link

Owner validation is complete on deployed 0.1.2-pilot.1: all requested behavior worked as planned, including the new layout and the analysis-completion email. Earlier owner feedback separately confirmed fresh SSO name/profile refresh and interactive notification consent. The owner explicitly authorized closure. Implementation, dependency/security review, native build, immutable image pins, deployment and checks are recorded in comments 624, 632, 641 and 646. Closing #25 as accepted and verified for this pilot. Broader full-release/performance/security work remains tracked separately; #12/PR #19 are unchanged.

Owner validation is complete on deployed 0.1.2-pilot.1: all requested behavior worked as planned, including the new layout and the analysis-completion email. Earlier owner feedback separately confirmed fresh SSO name/profile refresh and interactive notification consent. The owner explicitly authorized closure. Implementation, dependency/security review, native build, immutable image pins, deployment and checks are recorded in comments 624, 632, 641 and 646. Closing #25 as accepted and verified for this pilot. Broader full-release/performance/security work remains tracked separately; #12/PR #19 are unchanged.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
codex/issue-26-diagnostics-evidence
issue-12-isolated-malware-scanning
codex/issue-5-mobile-file-list
codex/issue-13-advanced-import
codex/issues-1-3-sso-profile
codex/merged-pr-handoff-docs
codex/issue-9-task-emails
codex/issue-6-metadata-coverage
backup/issue-12-pre-layered-20261027
codex/issues-4-7-8-activity
codex/issue-2-oidc-availability
codex/issues-10-11-diagnostics
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
jchapman/Immich-Bridge#25
No description provided.