* feat(salary): add remove-employee button to draft salary runs
The DELETE /api/salary/runs/{id}/employees/{employeeId} endpoint already
existed (draft-only, cascades to the employee's line items) but had no UI
trigger, so a mistakenly added employee could only be cleared by deleting
the whole draft. Add a trash-icon action column to the "Anställda" table,
gated on draft status + write permission to match the endpoint's guard,
with a confirm prompt and success/error toast.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* fix(settings): prevent horizontal overflow on mobile
The company settings invite form was a non-wrapping fixed-width flex row that overflowed narrow viewports, forcing the full-screen settings modal to scroll on the x-axis. Stack the form vertically on mobile (sm:flex-row at and above the sm breakpoint) and add the missing min-w-0 guard to the modal content pane.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* feat(bookkeeping): move journal entry filters into a filter dialog
The ledger toolbar showed every filter inline (fiscal year, sort, series,
date range, missing-documents toggle), which felt cluttered. Keep only the
search field visible and move the rest into a "Filtrera" dialog with an
active-filter count badge.
- JournalEntryList now owns the fiscal-year scope, restored from the same
localStorage key FiscalYearSelector writes, so the page no longer renders
the selector separately.
- Filters apply live and the dialog stays open; "Rensa alla filter" clears them.
- Export STORAGE_KEY_PREFIX / ALL_YEARS_VALUE from FiscalYearSelector so the
list reuses the persisted selection without duplicating the key.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* feat(transactions): implement imported transaction guard for deletion
- Added a guard to prevent deletion of transactions that are imported via bank sync or file uploads.
- Introduced `isImportedTransaction` utility to determine if a transaction is user-created or imported.
- Updated DELETE endpoint to return a 409 status for attempts to delete imported transactions.
- Enhanced transaction history and inbox components to reflect the new deletion rules.
- Added tests for transaction origin determination and deletion behavior.
- Updated UI components to include a confirmation dialog for clearing journal entry forms.
- Localized new strings for clearing form functionality in English and Swedish.
* feat(transactions): enhance transaction deletion guard and improve fiscal year visibility
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
231 lines
9.9 KiB
TypeScript
231 lines
9.9 KiB
TypeScript
import { createClient } from '@/lib/supabase/server'
|
|
import { NextResponse } from 'next/server'
|
|
import { requireCompanyId } from '@/lib/company/context'
|
|
import { requireWritePermission } from '@/lib/auth/require-write'
|
|
import { withRouteContext } from '@/lib/api/with-route-context'
|
|
import { errorResponse, errorResponseFromCode } from '@/lib/errors/get-structured-error'
|
|
import { validateBody } from '@/lib/api/validate'
|
|
import { UpdateTransactionTitleSchema } from '@/lib/api/schemas'
|
|
import { guardSandbox } from '@/lib/sandbox/guard'
|
|
import { isImportedTransaction } from '@/lib/transactions/origin'
|
|
import type { Transaction } from '@/types'
|
|
|
|
export async function DELETE(
|
|
_request: Request,
|
|
{ params }: { params: Promise<{ id: string }> }
|
|
) {
|
|
const supabase = await createClient()
|
|
const { id } = await params
|
|
|
|
const { data: { user } } = await supabase.auth.getUser()
|
|
if (!user) {
|
|
return NextResponse.json({ error: 'Unauthorized' }, { status: 401 })
|
|
}
|
|
|
|
const writeCheck = await requireWritePermission(supabase, user.id)
|
|
if (!writeCheck.ok) return writeCheck.response
|
|
|
|
const companyId = await requireCompanyId(supabase, user.id)
|
|
|
|
// Fetch the transaction with ownership check. `bank_connection_id` +
|
|
// `import_source` tell us where the row came from (see the imported guard below).
|
|
const { data: transaction, error: fetchError } = await supabase
|
|
.from('transactions')
|
|
.select('id, journal_entry_id, bank_connection_id, import_source')
|
|
.eq('id', id)
|
|
.eq('company_id', companyId)
|
|
.single()
|
|
|
|
if (fetchError || !transaction) {
|
|
return NextResponse.json(
|
|
{
|
|
error: {
|
|
code: 'TRANSACTION_NOT_FOUND',
|
|
message: 'Transaktionen hittades inte.',
|
|
message_en: 'Transaction not found.',
|
|
},
|
|
},
|
|
{ status: 404 }
|
|
)
|
|
}
|
|
|
|
// Guard: only unbooked transactions can be deleted. A booked/matched row is
|
|
// räkenskapsinformation — the fix is to unlink (reconciliation) or storno, not
|
|
// delete. Return a structured bilingual envelope so the UI shows this clear,
|
|
// actionable message instead of the generic "Ladda om sidan" 409 fallback.
|
|
if (transaction.journal_entry_id) {
|
|
return NextResponse.json(
|
|
{
|
|
error: {
|
|
code: 'TRANSACTION_DELETE_BOOKED',
|
|
message:
|
|
'Transaktionen är redan bokförd eller kopplad till en verifikation och kan inte raderas. Koppla bort den under Rapporter → Bankavstämning om kopplingen är fel, eller storna verifikationen.',
|
|
message_en:
|
|
'The transaction is already booked or linked to a journal entry and cannot be deleted. Unlink it under Reports → Bank reconciliation if the link is wrong, or reverse (storno) the voucher.',
|
|
},
|
|
},
|
|
{ status: 409 }
|
|
)
|
|
}
|
|
|
|
// Guard: only transactions the user created in the app can be deleted. Rows
|
|
// fetched via bank sync or uploaded via a bank-file import are an external
|
|
// record of money that moved — deleting one would silently drop a real bank
|
|
// line (and a re-sync would just bring it back). The user can *ignore* such a
|
|
// row (POST /api/transactions/[id]/ignore) to take it off the to-book list,
|
|
// but never delete it. See lib/transactions/origin.ts for the origin rule.
|
|
if (isImportedTransaction(transaction)) {
|
|
return NextResponse.json(
|
|
{
|
|
error: {
|
|
code: 'TRANSACTION_DELETE_IMPORTED',
|
|
message:
|
|
'Transaktionen har hämtats från banken eller importerats via fil och kan inte raderas. Du kan ignorera den så att den döljs från listan över transaktioner att bokföra.',
|
|
message_en:
|
|
'This transaction was fetched from your bank or imported from a file and cannot be deleted. You can ignore it to hide it from the list of transactions to book.',
|
|
},
|
|
},
|
|
{ status: 409 }
|
|
)
|
|
}
|
|
|
|
const { error: deleteError } = await supabase
|
|
.from('transactions')
|
|
.delete()
|
|
.eq('id', id)
|
|
.eq('company_id', companyId)
|
|
|
|
if (deleteError) {
|
|
// An unbooked row can still carry payment_match_log rows (written at ingest
|
|
// for every auto-suggested match). Their FK cascades on delete, but the
|
|
// audit-immutability trigger raises P0001 — surface that as an actionable
|
|
// message (match or ignore instead) rather than a bare 500.
|
|
const code = (deleteError as { code?: string }).code
|
|
const message = (deleteError as { message?: string }).message ?? ''
|
|
if (code === 'P0001' || /Audit log entries cannot be modified or deleted/i.test(message)) {
|
|
return NextResponse.json(
|
|
{
|
|
error: {
|
|
code: 'TRANSACTION_DELETE_HAS_AUDIT_TRAIL',
|
|
message:
|
|
'Transaktionen kan inte raderas eftersom den har en kopplad matchningshistorik (räkenskapsinformation, BFL 7 kap.). Matcha den mot en befintlig verifikation, eller ignorera den under Rapporter → Bankavstämning om du inte vill bokföra den.',
|
|
message_en:
|
|
'The transaction cannot be deleted because it has linked match-history records (accounting information, BFL ch. 7). Match it to an existing voucher, or ignore it under Reports → Bank reconciliation if you do not want to book it.',
|
|
},
|
|
},
|
|
{ status: 409 }
|
|
)
|
|
}
|
|
return NextResponse.json(
|
|
{
|
|
error: {
|
|
code: 'TRANSACTION_DELETE_FAILED',
|
|
message: 'Kunde inte ta bort transaktionen. Försök igen.',
|
|
message_en: 'Could not delete the transaction. Please try again.',
|
|
},
|
|
},
|
|
{ status: 500 }
|
|
)
|
|
}
|
|
|
|
return NextResponse.json({ success: true })
|
|
}
|
|
|
|
/**
|
|
* Edit a bank transaction's title (description).
|
|
*
|
|
* Legal under BFL only while the row is a mutable staging label — i.e. NOT yet
|
|
* booked into a verifikat and NOT confirmed-matched to an invoice. Once booked
|
|
* the description is räkenskapsinformation and corrections go through storno
|
|
* (reverseEntry/correctEntry), so this route hard-blocks those rows. The bank's
|
|
* original title is preserved immutably in original_description (set at ingest)
|
|
* and is never written here; passing it back restores the "not edited" tag.
|
|
*/
|
|
export const PATCH = withRouteContext(
|
|
'transaction.updateTitle',
|
|
async (request, ctx, { params }: { params: Promise<{ id: string }> }) => {
|
|
const { id } = await params
|
|
const { supabase, companyId, log, requestId, user } = ctx
|
|
|
|
const blocked = await guardSandbox(supabase, companyId)
|
|
if (blocked) return blocked
|
|
|
|
const validation = await validateBody(request, UpdateTransactionTitleSchema, {
|
|
log,
|
|
operation: 'transaction.updateTitle',
|
|
})
|
|
if (!validation.success) return validation.response
|
|
const { description } = validation.data
|
|
|
|
const { data: transaction, error: fetchError } = await supabase
|
|
.from('transactions')
|
|
.select('id, description, original_description, journal_entry_id, invoice_id, supplier_invoice_id')
|
|
.eq('id', id)
|
|
.eq('company_id', companyId)
|
|
.single()
|
|
|
|
if (fetchError || !transaction) {
|
|
return errorResponseFromCode('TX_CATEGORIZE_TX_NOT_FOUND', log, { requestId })
|
|
}
|
|
|
|
// Gate: editable only when neither booked nor confirmed-matched. (A
|
|
// confirmed invoice/supplier-invoice match also sets journal_entry_id, but
|
|
// we check all three for defense-in-depth.) An unbooked row has no fiscal
|
|
// period, so the period-lock requirement is satisfied implicitly.
|
|
if (transaction.journal_entry_id || transaction.invoice_id || transaction.supplier_invoice_id) {
|
|
return errorResponseFromCode('TRANSACTION_TITLE_LOCKED', log, { requestId })
|
|
}
|
|
|
|
// Restoring to the bank original clears the "edited" tag; any other value
|
|
// marks the title as user-edited. Compare against the TRIMMED original (the
|
|
// incoming description is already trimmed by the schema) so a legacy
|
|
// original carrying surrounding whitespace still restores cleanly.
|
|
const isRestore =
|
|
transaction.original_description != null &&
|
|
description === transaction.original_description.trim()
|
|
const titleEditedAt = isRestore ? null : new Date().toISOString()
|
|
|
|
const { data: updated, error: updateError } = await supabase
|
|
.from('transactions')
|
|
.update({ description, title_edited_at: titleEditedAt })
|
|
.eq('id', id)
|
|
.eq('company_id', companyId)
|
|
// Re-assert the FULL editable gate atomically against a concurrent book
|
|
// or auto-match. Ingest's supplier auto-match can set supplier_invoice_id
|
|
// WITHOUT journal_entry_id, so guarding journal_entry_id alone leaves a
|
|
// narrow TOCTOU window — mirror the read-time gate here.
|
|
.is('journal_entry_id', null)
|
|
.is('invoice_id', null)
|
|
.is('supplier_invoice_id', null)
|
|
// Return only what the client renders (data minimisation — the row also
|
|
// carries company_id and other internal fields the caller doesn't need).
|
|
.select('id, description, title_edited_at')
|
|
.maybeSingle<Pick<Transaction, 'id' | 'description' | 'title_edited_at'>>()
|
|
|
|
if (updateError) {
|
|
return errorResponse(updateError, log, { requestId })
|
|
}
|
|
if (!updated) {
|
|
// 0 rows updated → the row was booked/matched between read and write.
|
|
return errorResponseFromCode('TRANSACTION_TITLE_LOCKED', log, { requestId })
|
|
}
|
|
|
|
// Behandlingshistorik (BFNAR 2013:2 kap 8) — light-touch for a pre-verifikat
|
|
// working label; updated_at (trigger) captures "when". We deliberately do
|
|
// NOT log the description text: a bank label can carry PII (payee names,
|
|
// reference numbers). The before-value stays recoverable in
|
|
// original_description and the after-value is the row's current
|
|
// description, so the log only needs to record that/which way it changed.
|
|
log.info('transaction title edited', {
|
|
transactionId: id,
|
|
actor: user.id,
|
|
restored: isRestore,
|
|
previousLength: transaction.description?.length ?? 0,
|
|
newLength: description.length,
|
|
})
|
|
|
|
return NextResponse.json({ data: updated })
|
|
},
|
|
{ requireWrite: true },
|
|
)
|