PhoenixKitCatalogue.Web.SettingsLive (PhoenixKitCatalogue v0.44.2)

Copy Markdown View Source

Settings → Catalogue.

The module had no settings page at all, so everything it stores was either unreachable (the whole AI-translation sweep, four keys whose only writer was an operator calling update_* from a console) or lived on whichever list page happened to write it. The owner noticed the gap from the other end — /admin/settings simply had no Catalogue entry (boss via Max, 2026-09-21).

Every key the module owns that a person can meaningfully change is here; PhoenixKitCatalogue.Web.Settings is where they are read and written.

Two things deliberately NOT here:

  • The module kill switch (catalogue_enabled) — Admin → Modules owns it, and a copy of it on this page would be a switch that hides the page it lives on, since the tab is gated on the module's permission.
  • The per-scope list sort (catalogue_sort_*) — the sort selector on each list writes it, which is the place a person is standing when they decide what "sorted" means. A second control here would disagree with it.

Summary

Functions

The languages a posted checkbox group names, kept to the ones on offer.

Functions

on_mount(atom, params, session, socket)

picked_langs(params, available)

@spec picked_langs(map(), [String.t()]) :: [String.t()]

The languages a posted checkbox group names, kept to the ones on offer.

An unticked group posts nothing at all, so an absent "langs" key means "none" — not "unchanged". A code that is not an enabled language is dropped, so a crafted post cannot store a language the sweep would then target. Public for its tests: the LiveView only offers this group when a second language is enabled, which a test database may not have.