- Ya
- 14 Agosti 2026, 00:18 UTC
- Mwandishi
- Kamo
- Ahadi ya
- c9833af
Adds the persistence spine for connecting an organization's timecards to a third-party payroll system: the connection and its encrypted per-org config, the OAuth grant, the member-to-provider-employee link, the earning-code map, and the two append-only records (dispatch attempts and sync issues) that make a sync explainable afterwards. Kept inside com.kamo.z.shared.hr.timecard rather than a new package on purpose: a new shared-lib package has to be added to three separate explicit @EnableJpaRepositories lists, and omitting one aborts a service context — or, in KamoInitializer, aborts the run while still reporting BUILD SUCCESS. Notes on the shape: - PayrollProviderType reuses the token vocabulary already documented on **************** (ADP_WFN, PAYCHEX, GUSTO, ...). A second spelling for the same vendor would split export history with no error anywhere. ADP_RUN and QUICKBOOKS are kept because the payroll export screen has offered them since it shipped, so live rows may carry them. - Employee links are keyed by provider, not by connection, so switching provider and switching back does not throw away the mapping work. TWO unique constraints: one stops a member holding two links, the other stops two members claiming one provider employee — that one prevents a double-pay. - PayrollDispatch and PayrollSyncIssue are WORM. A payroll transmission attempt is a money event; "we sent it, then we sent it again" is the fact a reconciliation needs. - Credentials live in ONE encrypted config_json blob rather than a column per field, so adding a vendor is not a schema change that re-arms every service. RoleRightType gains MANAGE_PAYROLL_PROVIDER (199) — deliberately NOT the legacy MANAGE_PAYROLL (40), which gates nothing today and is already held by unknown numbers of members; reusing it would hand third-party payroll credentials to every rate-viewing right holder on the boot that shipped it. PlatformOAuthProviderType gains the seven payroll vendors where Kamo holds one partner registration (ids 11-17). Dayforce, Workday and UKG issue credentials per customer and deliberately get no constant: the platform screen renders a card for every constant, so one for them would be a form no operator could fill in. Also fixes a stale assertion in BillingDelegationModeTest: commit 9276487 deliberately made REQUIRES_APPROVAL allow groups (the exclusion made the approval path unreachable) but left the test asserting the old behaviour, so the suite has been red on main since. Schema applied and verified in Yugabyte before this push.