site-profile-universal.json is what the released Windows installer is built from, so a bundled plugin missing from it is invisible to the install wizard. Worse, `flask plugin prune-schema` drops the tables owned by plugins the site did not install (ADR-014), so backuprevisions would have been dropped at provisioning on every new site - a table that shipped in the build, removed because the profile never named it. The same omission explains why `flask plugin upgrade-all` skipped backups: upgrade_all_plugins iterates the REGISTRY, not the plugins directory, on purpose - a plugin folder merely sitting on disk unadopted must not have its DDL run as a side effect of a deploy. instance/ is gitignored, so any machine that never ran `flask plugin install backups` has it on disk but unadopted. Nothing in the suite caught the stale profile, so this adds two guards: every bundled plugin carrying a manifest must appear in the universal profile, and the profile must not name a plugin that does not exist. Verified the first one fails with the profile as it was.
22 lines
923 B
JSON
22 lines
923 B
JSON
{
|
|
"site": "universal",
|
|
"plugins": [
|
|
"backups",
|
|
"computers",
|
|
"employees",
|
|
"geenforce",
|
|
"knowledgebase",
|
|
"machines",
|
|
"measuringtools",
|
|
"network",
|
|
"notifications",
|
|
"printedparts",
|
|
"printers",
|
|
"slides",
|
|
"usb",
|
|
"warranty"
|
|
],
|
|
"locked": [],
|
|
"_comment": "The profile the released Windows installer is built from. Every bundled plugin that carries a manifest, so ONE exe serves any site: the wizard offers all of them and the operator ticks what that site uses. Plugins left unticked are never installed, and 'flask plugin prune-schema' drops their tables at provisioning (ADR-014). 'applications' is deliberately absent - it is manifest-less core and always ships. Build with: deploy/windows/installer/build-installer.sh deploy/site-profile-universal.json <repo>. Use site-profile.example.json instead only when a site genuinely needs a lean build; see ADR-013."
|
|
}
|