hamedandClaude Opus 5
1f58b1b9b3
An appointment can now carry the insurance it is billed with: the service kind (outpatient/inpatient) and the basic insurance. Confirming it no longer hands the whole amount to the patient — the visit is split through BillingCalculator with the coverage percent of that service kind, and the choice travels to the encounter and the invoice built from it. The enabled service kinds are a tenant-wide setting (all of that tenant's insurances share it), so a tenant covering only one kind is never asked which one: the panel resolves it the same way the server does. - add tenant_service_category_settings + TenantServiceCategoryService, exposed on the existing insurance-pricing endpoint (service_categories, default_service_category); at least one kind must stay enabled - add appointments.insurance_service_category / insurance_base_id with AppointmentInsuranceService validating them against the tenant's own settings and active contracts (basic only), accepted by PATCH and by confirm - snapshot the kind on patient_sessions and invoices; the visit's coverage rule is resolved per kind (services keep using their own ServiceItem.service_category) - lib/insuranceShares becomes the single client-side mirror of BillingCalculator, shared by the confirm modal, the appointment edit page and the session form - surface the selection: confirm modal (with live shares), turns timeline chip, appointment edit page, patient record service card and invoice summary - the session form shows the insurance block whenever the tenant has an active contract and prefills the patient's own insurance, so it can be changed - fix: the confirm modal showed a zero visit price when the appointment had none — it now falls back to the tenant's free-visit price like the server - fix: useServiceCategories read one level too shallow, so Persian labels never arrived and raw enum keys leaked into the contract summary - fix: BlogsPage test asserted the public blogs endpoint after the page moved to the admin one Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
52 lines
1.9 KiB
TypeScript
52 lines
1.9 KiB
TypeScript
import { describe, it, expect, beforeEach, vi } from 'vitest';
|
|
import { screen, waitFor } from '@testing-library/react';
|
|
import { renderWithProviders } from '../test/utils';
|
|
|
|
vi.mock('../lib/api', () => ({
|
|
api: { get: vi.fn(), post: vi.fn(), patch: vi.fn(), put: vi.fn(), delete: vi.fn() },
|
|
ApiError: class extends Error {},
|
|
}));
|
|
|
|
import { api } from '../lib/api';
|
|
import { useServiceCategories } from './useServiceCategories';
|
|
|
|
const get = api.get as ReturnType<typeof vi.fn>;
|
|
|
|
function Probe() {
|
|
const { categories } = useServiceCategories();
|
|
|
|
return <div data-testid="labels">{categories.map((c) => c.label).join('|')}</div>;
|
|
}
|
|
|
|
beforeEach(() => get.mockReset());
|
|
|
|
describe('useServiceCategories', () => {
|
|
/** کنترلر با success(['data' => …]) پاسخ میدهد، پس آرایه یک لایه تودرتوست. */
|
|
it('آرایه را از پاسخ تودرتوی کنترلر بیرون میکشد', async () => {
|
|
get.mockResolvedValue({ success: true, data: { data: [
|
|
{ key: 'outpatient', label: 'خدمات سرپایی' },
|
|
{ key: 'inpatient', label: 'خدمات بستری' },
|
|
] } });
|
|
|
|
renderWithProviders(<Probe />);
|
|
|
|
await waitFor(() => expect(screen.getByTestId('labels')).toHaveTextContent('خدمات سرپایی|خدمات بستری'));
|
|
});
|
|
|
|
it('پاسخ تخت (بدون لایهٔ اضافه) هم پذیرفته میشود', async () => {
|
|
get.mockResolvedValue({ success: true, data: [{ key: 'outpatient', label: 'خدمات سرپایی' }] });
|
|
|
|
renderWithProviders(<Probe />);
|
|
|
|
await waitFor(() => expect(screen.getByTestId('labels')).toHaveTextContent('خدمات سرپایی'));
|
|
});
|
|
|
|
it('پاسخ نامعتبر → لیست خالی، بدون خطا', async () => {
|
|
get.mockResolvedValue({ success: true, data: { insurances: [] } });
|
|
|
|
renderWithProviders(<Probe />);
|
|
|
|
await waitFor(() => expect(screen.getByTestId('labels')).toHaveTextContent(''));
|
|
});
|
|
});
|