Sluicio v0.11.59

Put a system on a dashboard

Dashboards could pin integrations and services. Systems — the thing that has members, its own health checks, and its own rollup status — could not go on a board at all, even though they are peers of integrations everywhere else in the product.

They can now. edit dashboard gains a second picker, add system entity, listing your systems with their member counts. The card shows the system's type, its health, and how many services it covers, and clicks through to the system.

Two kinds of system card, on purpose

The older add system picker is still there and still works. It pins a service that has been flagged as a system, keyed by its name. The new picker pins a system — a different object, with an id, several member services, and checks bound to itself.

Existing cards were left exactly as they are. Converting them would have meant guessing which system a flagged service belongs to, and it may belong to none. When a dashboard holds both, the older strip is labelled System services so the two stay distinguishable.

The card reports health, not a guess

The card shows the status the server computes, which already folds in the checks bound to the system itself. A browser cannot see those checks, so anything recomputing health in the page calls a system with a firing check quiet — the failure fixed across four surfaces in v0.11.56–58. This card does not recompute.

Also

• Pinning a system from another organisation is refused at the API rather than accepted and rendered as a permanently blank card.
• A card whose system was deleted still renders, marked no longer exists, so it can be removed. Previously an invisible card would have been unremovable.