ekwo-os 0.4.1

package/dist/assets/modules/assets/supabase/migrations/20260913104234_foreign_key_indexes.sql

@@ -0,0 +1,47 @@
+-- Ekwo OS — a foreign key without an index is a sequential scan waiting for
+-- a big enough table.
+--
+-- Postgres indexes the *referenced* side of a foreign key, because that side
+-- is a primary key. It indexes nothing on the referencing side. Two things
+-- then read the whole table:
+--
+--   * every delete or key update of the parent, which has to prove no child
+--     points at the row — deleting one contact scans `entry_lines`;
+--   * every join written the natural way, which for an accounting core is
+--     most of them: a document to its lines, an entry to its lines, a line to
+--     its account, its tax, its contact.
+--
+-- On the demo company nothing is slow, which is exactly why this survived 49
+-- migrations. On a company with four years of books it is the difference
+-- between a report and a timeout.
+--
+-- 11 indexes: every foreign key of the `assets` module that had none, and the
+-- `company_id` of the tables that had none either — which the sweep covers,
+-- because `company_id` is itself a foreign key everywhere it appears.
+--
+-- Where a table has both a single-column key and a composite one leading with
+-- the same column — `(account_id)` and `(account_id, company_id)`, the shape
+-- this schema uses to keep a child in its parent's company — one index on the
+-- composite serves both, and that is the one created.
+--
+-- The list is not maintained by hand. `tests/schema.test.ts` asks the
+-- catalogue the same question and fails when the answer is not empty, so a
+-- foreign key added later arrives with its index or the build says so.
+
+
+-- assets.assets
+create index if not exists assets_asset_account_company_idx on assets.assets (asset_account_id, company_id);
+create index if not exists assets_contact_company_idx on assets.assets (contact_id, company_id);
+create index if not exists assets_depreciation_account_company_idx on assets.assets (depreciation_account_id, company_id);
+create index if not exists assets_expense_account_company_idx on assets.assets (expense_account_id, company_id);
+create index if not exists assets_product_idx on assets.assets (product_id);
+
+-- assets.depreciation_lines
+create index if not exists depreciation_lines_asset_company_idx on assets.depreciation_lines (asset_id, company_id);
+
+-- assets.disposals
+create index if not exists disposals_asset_company_idx on assets.disposals (asset_id, company_id);
+create index if not exists disposals_company_idx on assets.disposals (company_id);
+create index if not exists disposals_contact_idx on assets.disposals (contact_id);
+create index if not exists disposals_counterpart_account_idx on assets.disposals (counterpart_account_id);
+create index if not exists disposals_entry_idx on assets.disposals (entry_id);

package/dist/assets/modules/assets/supabase/migrations/20260913104500_assets_capabilities.sql

@@ -0,0 +1,145 @@
+-- Ekwo module `assets` — the module names what it lets somebody do.
+--
+-- Its policies asked `public.can_write_company()`, which is `entries.write`:
+-- whoever may draft a journal entry may also create a fixed asset, change its
+-- cost, rewrite its schedule and record its disposal. That is one lock for two
+-- doors, and the wrong one — the register that explains a depreciation entry
+-- is not the entry, and the person who keeps it is often not the person who
+-- posts the books.
+--
+-- So the module declares its own vocabulary, in its own migration, which is
+-- where it belongs: a migration of the socle that named `assets` would be the
+-- socle knowing what is built beside it. `capabilities.area` is the module
+-- code, exactly as the socle's comment says it should be.
+--
+--   assets.read   — see the register.
+--   assets.write  — create an asset, change it, plan its depreciation.
+--   assets.post   — put a period or a disposal into the ledger.
+--
+-- `assets.post` is not the same as `entries.post`, and both are asked: this
+-- one says the module may send *this* to the ledger, and `post_entry()` still
+-- asks the socle's own question afterwards. Neither is redundant — an
+-- accountant who may post the books may be deliberately kept off the asset
+-- register, and somebody who keeps the register is not thereby allowed to
+-- post anything else.
+--
+-- The presets follow the socle's: a viewer reads, an accountant does the work,
+-- an owner holds everything. The socle filled the owner preset with `select
+-- 'owner', code from capabilities` at its own migration time, so a code added
+-- later has to name the owner itself.
+
+insert into public.capabilities (code, area, description) values
+  ('assets.read',  'assets', 'Read the fixed asset register, its depreciation schedules and its disposals.'),
+  ('assets.write', 'assets', 'Create and change fixed assets and plan their depreciation.'),
+  ('assets.post',  'assets', 'Book a depreciation period or a disposal to the ledger. Cannot be undone.')
+on conflict (code) do update set area = excluded.area, description = excluded.description;
+
+insert into public.role_capabilities (role, capability) values
+  ('viewer'::public.member_role,     'assets.read'),
+  ('accountant'::public.member_role, 'assets.read'),
+  ('accountant'::public.member_role, 'assets.write'),
+  ('accountant'::public.member_role, 'assets.post'),
+  ('owner'::public.member_role,      'assets.read'),
+  ('owner'::public.member_role,      'assets.write'),
+  ('owner'::public.member_role,      'assets.post')
+on conflict do nothing;
+
+-- ---------------------------------------------------------------------------
+-- The policies, on the module's own words
+--
+-- `module_enabled()` stays in front of every one of them: a capability says
+-- what a person may do, and the module being enabled says whether the company
+-- has this at all. The two questions are not the same and neither replaces
+-- the other.
+-- ---------------------------------------------------------------------------
+
+drop policy assets_select on assets.assets;
+create policy assets_select on assets.assets
+  for select using (
+    public.module_enabled(company_id, 'assets')
+    and public.has_capability(company_id, 'assets.read')
+  );
+
+drop policy assets_write on assets.assets;
+create policy assets_write on assets.assets
+  for all using (
+    public.module_enabled(company_id, 'assets')
+    and public.has_capability(company_id, 'assets.write')
+  )
+  with check (
+    public.module_enabled(company_id, 'assets')
+    and public.has_capability(company_id, 'assets.write')
+  );
+
+drop policy assets_lines_select on assets.depreciation_lines;
+create policy assets_lines_select on assets.depreciation_lines
+  for select using (
+    public.module_enabled(company_id, 'assets')
+    and public.has_capability(company_id, 'assets.read')
+  );
+
+drop policy assets_lines_write on assets.depreciation_lines;
+create policy assets_lines_write on assets.depreciation_lines
+  for all using (
+    public.module_enabled(company_id, 'assets')
+    and public.has_capability(company_id, 'assets.write')
+  )
+  with check (
+    public.module_enabled(company_id, 'assets')
+    and public.has_capability(company_id, 'assets.write')
+  );
+
+drop policy assets_disposals_select on assets.disposals;
+create policy assets_disposals_select on assets.disposals
+  for select using (
+    public.module_enabled(company_id, 'assets')
+    and public.has_capability(company_id, 'assets.read')
+  );
+
+drop policy assets_disposals_write on assets.disposals;
+create policy assets_disposals_write on assets.disposals
+  for all using (
+    public.module_enabled(company_id, 'assets')
+    and public.has_capability(company_id, 'assets.write')
+  )
+  with check (
+    public.module_enabled(company_id, 'assets')
+    and public.has_capability(company_id, 'assets.write')
+  );
+
+-- ---------------------------------------------------------------------------
+-- What `assets.post` actually guards
+--
+-- Guards on the transition rather than inside `run_depreciation()` and
+-- `dispose_asset()`, for the reason the socle gives for its own three: a
+-- guard on the transition holds for every path into it, including a client
+-- that writes the column itself, and it does not require republishing four
+-- hundred lines of depreciation arithmetic for four lines of permission.
+--
+-- `is_installer()` for the same reason as everywhere else: the seeds and the
+-- CLI hold a connection and no session.
+-- ---------------------------------------------------------------------------
+
+create or replace function assets.assert_may_post()
+returns trigger
+language plpgsql
+as $$
+begin
+  if not public.is_installer() and not public.has_capability(new.company_id, 'assets.post') then
+    raise exception 'not_allowed: booking this to the ledger needs assets.post'
+      using errcode = '42501';
+  end if;
+  return new;
+end;
+$$;
+
+create trigger assets_lines_assert_may_post
+  before update of posted_at on assets.depreciation_lines
+  for each row when (new.posted_at is not null and old.posted_at is null)
+  execute function assets.assert_may_post();
+
+create trigger assets_disposals_assert_may_post
+  before insert on assets.disposals
+  for each row execute function assets.assert_may_post();
+
+revoke execute on all functions in schema assets from public;