@mvthul — upstreaming your invoice grouping and display fixes?

[ToddHebebrand]

@mvthul — I noticed the patches you've been carrying on your fork and a few of them look like straight wins for everyone. Would you be willing to open PRs against main so they land under your name?

The ones I'd merge on sight:

• Invoice lines grouped by ticket / category across PDF, portal and web — d52c4af, bc3c3f1, 4cddb99. This is a better default than the flat list we have now, and you've already covered all three surfaces.
• Monitoring role/OS policy filtering, group-policy assignment display, contacts redirect — 3a258a5. Display fixes, no reason to keep patching them locally.
• Clean up config policy assignments before deleting a device group — 4663cb7. That's a real bug on our side.

The SSO MFA amr claim relaxation and the docs-embedding CORS change I'd also like to see, but they touch auth, so I'd want to review those with more care. A PR with a sentence on which IdP was tripping the amr check would make that easy — I suspect other people hit the same thing and just gave up.

No CLA, AGPL stays AGPL, CONTRIBUTING.md has the mechanics. If you'd prefer I cherry-pick with attribution instead, just say so. Either way, thanks for the work — it's nice to see a self-hosted install patching things forward rather than working around them.

[mvthul]

Hi @ToddHebebrand,

Thanks for reaching out! Really appreciate you noticing and maintaining Breeze. Happy to upstream these!

I've opened the PRs for the three items you mentioned:

1. Clean up config policy assignments before deleting device group: fix(device-groups): clean up config policy assignments before deleting device group #5855
2. Invoice lines grouped by ticket and category across PDF, portal, and web: feat(billing): group invoice lines by ticket and category across PDF, portal, and web #5856
3. Monitoring role/OS policy filtering, group-policy assignment display, and contacts redirect: fix(monitoring,groups): canonical role/os policy filtering and group policy assignment display #5857

Regarding the other two:

• SSO MFA amr claim: We ran into this with Microsoft Entra ID (Azure AD) and certain custom OIDC/SAML setups where MFA is enforced upstream via Conditional Access, but the token either omits the amr array or emits claims like pwd, rsa, etc., without the exact literal "mfa" string. When trustsIdpMfa was enabled, it was rejecting legitimate logins or failing the MFA gate. I'll open a separate, isolated PR with tests and details on this once these are reviewed.
• Docs-embedding CORS: We needed self-hosted instances running on custom domains to allow embedding the docs without running into CSP/CORS frame restrictions. Happy to open a dedicated PR for this as well.

Let me know if anything needs tweaking in the PRs!

[mvthul]

Also wanted to mention that we are actively putting Breeze through its paces in real-world environments. I'm planning to thoroughly test features across the board, especially the upcoming roadmap items around ticketing, PSA workflows, and Windows Defender / security management.

On the development front, I would love to help contribute to time tracking / registration in the mobile app, as that is a critical day-to-day workflow for technicians on the go. I'll make sure to dive deeper into the repo's contributing workflow (CONTRIBUTING.md, plans, and specs) so any future contributions and PRs land smoothly according to project standards!

[ToddHebebrand]

Great, thank you — reviews are up on all three (#5855, #5856, #5857) and CI is now approved on each; that first-contributor gate is why you saw no checks. The group-delete one is a real trigger bug and just needs a regression case; the other two have a few items each, none of them structural.

The amr claim and docs-embedding changes sound right as separate PRs. For the amr one, please include the exact claim sets you saw from Entra with Conditional Access so the test cases match real tokens.

On mobile time tracking: the core is already shipped (#3206, eight waves): ticket start/stop timer, offline-started timers, a durable offline write queue with replay, the timesheet screen with edit / billable / locking, and one-tap confirmation of AI-suggested entries from remote sessions. So the interesting work is on top of that rather than building it. Two concrete places to start:

• Location-aware time suggestions in the mobile app (one-tap arrival prompt) #4186 — location-aware time suggestions (arrival-at-customer-site prompt). The spec is approved; it needs an implementation plan. If this matches what your techs need day to day, writing that plan is the highest-leverage contribution and I'll review it fast.
• Activity-type codes on time entries (remote/onsite/consulting) driving rate and reporting #4615 — activity-type codes on time entries. Idea stage, touches billing and the mobile timer UI; a short design note would move it forward.

If what you have in mind is different from both, describe the workflow in a Discussion first (what the tech is doing on the phone, what gets entered, what the office needs out of it) and we'll shape it into a spec before any code. Two mechanical notes for mobile PRs: screen logic lives in a paired .ts module next to the .tsx screen because the vitest config only runs .ts, and the iOS native build is a required CI gate.

[ToddHebebrand]

One more thing since you mentioned testing in real environments: the iOS app went live on the App Store a couple of days ago — https://apps.apple.com/us/app/breeze-rmm/id6789370762 — so your techs can run the shipped timer and timesheet flows against your instance today rather than building from source. Field notes on what feels wrong on the phone are as useful as code at this stage.

[ToddHebebrand]

And if Android is what your techs carry: the app is Expo (apps/mobile), with preview and production profiles already in apps/mobile/eas.json and an expo run:android script, so producing an APK is straightforward — point EXPO_PUBLIC_API_URL at your instance and build the preview profile. There is no Play Store listing yet; if you get to an Android build before I do, notes on anything that needed changing to make it work would be welcome.

[ToddHebebrand]

Correction on the Android build: don't use EAS. We deliberately build without an Expo account — the native projects are generated with expo prebuild and built locally, so for Android it's npx expo prebuild --platform android and then Gradle (./gradlew assembleRelease in the generated android/ dir, or expo run:android for a device build). Two things to have in place first: EXPO_PUBLIC_API_URL pointing at your instance, and a google-services.json from your own Firebase project written into apps/mobile/ via pnpm --filter breeze-mobile write-google-services (the config plugin only resolves it at prebuild time; it is gitignored). apps/mobile/STORE_SUBMISSION.md walks through both. Push on Android goes through native FCM, so it will only fire if your server also has FIREBASE_SERVICE_ACCOUNT set.