securo

SQLite gives a column declared as UUID NUMERIC affinity, so some UUID hex strings such as 1e999... are silently converted to REAL/float. SQLAlchemy's UUID result processor then receives a float instead of a string and calls .replace() on it.

Fix the SQLite test schema by compiling PostgreSQL UUID as CHAR(32), which has TEXT affinity:

from sqlalchemy.dialects.postgresql import UUID as PG_UUID
from sqlalchemy.ext.compiler import compiles

@compiles(PG_UUID, "sqlite")
def _uuid_as_char32(element, compiler, **kw):
    return "CHAR(32)"

Register this before Base.metadata.create_all() or engine/table creation. Recreate any existing file-based SQLite test database; in-memory databases are recreated automatically. PostgreSQL remains unaffected and continues using its native uuid type.

This is caused by podman-compose versions older than 1.6.0, which cannot parse nested default values in compose files like ${FRONTEND_URL:-http://localhost:${FRONTEND_PORT:-3000}}. The parser stops at the first } and leaves the trailing brace attached to the value, so printenv FRONTEND_URL shows https://example.mydomain.com}. Fix: upgrade podman-compose to 1.6.0 or newer (e.g., pip install -U podman-compose), then recreate the containers with podman-compose up -d. Alternatively, update to the version of this project that removed the nested variable syntax so it works with any podman-compose version.

The test suite uses a hardcoded frozen date (e.g. TODAY = date(2026, 8, 26)) while the service generates issue_date from the real UTC clock via datetime.now(timezone.utc).date(). Once real time passes the frozen due_date (TODAY + 10 days), validation due_date < issue_date rejects the invoice and all dependent tests fail permanently. Fix: anchor the test to the same clock the service uses — replace TODAY = date(2026, 8, 26) with TODAY = datetime.now(timezone.utc).date(). This was fixed upstream by PR #852, which pins the invoice test suite to its own clock; updating to a version including #852 also resolves it. Avoid just moving the literal forward (e.g. date(2027, 1, 1)) — it recreates the same failure later. Note: the test constant is evaluated at import time while the service reads the clock at call time, so keep a multi-day margin between issue and due dates to avoid flaky failures across UTC day boundaries.

This regression affects Securo v0.16.0. PR #375 added a strict Group.workspace_id == workspace_id check to split_service._validate_members, rejecting a user who is linked to a shared group from another workspace even though the UI displays the group.

Fix by upgrading to a release containing PR #972. If you need to patch v0.16.0 yourself, update split_service._validate_members to use the same visibility rule as group_service._visible_predicate: allow either a group in the current workspace or a group where the user is linked as a non-owner member:

member_groups = (
    select(GroupMember.group_id)
    .where(
        GroupMember.linked_user_id == user_id,
        GroupMember.is_self.is_(False),
    )
    .distinct()
)

result = await session.execute(
    select(GroupMember, Group)
    .join(Group, GroupMember.group_id == Group.id)
    .where(
        GroupMember.id.in_(member_ids),
        or_(
            Group.workspace_id == workspace_id,
            Group.id.in_(member_groups),
        ),
    )
)

Preferably reuse/import group_service._visible_predicate instead of duplicating the rule so read and write paths cannot diverge again. Rebuild/restart the self-hosted container after applying the patch. This still prevents arbitrary groups from other workspaces being referenced; only groups to which the requesting user is explicitly linked are accepted.

This happens when remittance_information and additional_information are empty; Securo falls back directly to "Transaction" instead of using the counterparty name. Fix the Enable Banking import mapping so that, after remittance and additional information are checked, it uses creditor.name for debit (DBIT) transactions or debtor.name for credit (CRDT) transactions, then the opposite counterparty, and only finally "Transaction":

description = _join_remittance(raw.get("remittance_information")) or (
    raw.get("additional_information") or ""
)

if not description:
    creditor = (raw.get("creditor") or {}).get("name") or raw.get("creditor_name")
    debtor = (raw.get("debtor") or {}).get("name") or raw.get("debtor_name")

    if indicator == "DBIT":
        description = creditor or debtor or ""
    else:
        description = debtor or creditor or ""

description = description.strip()[:500] or "Transaction"

Apply the Enable Banking counterparty-fallback patch or upgrade to a release containing PR fix(enable-banking): fall back to counterparty name when description is missing. Existing transactions may need to be reimported or manually corrected after the fix.