Pre-release 1.2.6.1-beta: Audit & Report section #343
Replies: 6 comments
|
Hi @MacRimi, thank you again for the invitation. I reviewed the full new Audit & Report section, and #344 has now been merged for the beta. The section already gives a much clearer picture of the server. For a later follow-up, I would especially consider:
I kept these as suggestions rather than adding them to the localization PR, so #344 stays focused and easy to merge. I would be happy to help with any of them after the release. |
|
Hi @Vaso73, Thanks again — the Slovak copy really lifted the section. I'm releasing 1.2.6.1-beta on Monday, and after that I'd like to take your three suggestions on properly. On the second one: the note is already in there — accepting a finding requires a reason, and the acceptance can be given an expiry in days. If what you had in mind is a review date that brings it back to your attention without the acceptance lapsing by itself, that's a different thing, and I think a better one. The third looks like the natural place to start. The comparison already separates new, resolved, accepted and retired, but a finding that is still present and has got worse — a warning that became critical, or one that affected three guests and now affects nine — currently sits under "unchanged", which isn't true. Giving those a group of their own seems like the smallest change with the clearest gain. The first is the biggest of the three, and the one I'd most like to get right: plain language and a next step, for every check, in eight languages. There's one more thing I'd like to explore alongside them. The Changes view already records what ProxMenux did to the host — the natural next question is whether it can undo it from there. For an application, a button that uninstalls it; for a post-install option, calling the uninstaller that already exists for it. Not automatic, and not for everything — only where the reversal is genuinely known. What do you think? |
|
Hi @MacRimi, That sounds like a very good direction. I agree that the comparison view is the best place to start: a separate group for findings that became worse would make the reference comparison much more honest and useful without making the flow heavier. For accepted findings, I had exactly the non-expiring review reminder in mind. Keeping the acceptance in place while bringing it back to the administrator’s attention at a chosen date feels safer and more flexible than relying only on an expiry. The plain-language explanation and next step would be the most valuable improvement for everyday users, but I agree it deserves careful design before translating it across all eight languages. It may work best if each check has a short, reusable explanation, a recommended next step, and a clear indication when no action is needed. The reversible Changes actions are promising too, especially when the reversal is explicit and already known. I would keep those opt-in, clearly labelled, and limited to a small initial set of safe actions. For delivery, my suggested order would be:
From a direct user-value perspective, though, the plain-language guidance is the most important of the four. I see it as the larger follow-up that deserves careful design, rather than something to postpone in principle. Happy to help review the wording and Slovak copy when you are ready after the release. |
|
Hi @Vaso73, The first two are in develop. A finding that is still present but has got worse now has its own group in the comparison, apart from the ones that improved — a warning that became critical, or one that affected three guests and now affects nine, no longer sits under "unchanged". And an acceptance can carry a review date that brings the finding back without the acceptance lapsing by itself, which was the distinction you drew. The third is where I'd like your eyes before it goes further. Rather than write forty-three explanations and then find out the shape was wrong, I've done one whole area — the six backup checks — as the pattern the rest would follow. Each check says in plain terms what it looked at, and each outcome carries its own next step, so the advice changes with what was actually found rather than being generic to the check. Where nothing needs doing it says so; where the check could not run it says that, instead of letting silence read as a clean result. That's 6 of 43. The other 37 would repeat whatever that pattern turns out to be, which is exactly why it's worth being slow about it now — if the wording reads wrong in English it will read worse in eight languages. The fourth hasn't been started. Your framing of it is how I'd want to scope it when it comes. The Slovak is yours whenever you want it, but I'd rather not hand you forty-three checks' worth of text until the shape is settled. |
|
Hi @MacRimi — I went through the six Backup Assurance checks as the proposed pattern for the broader plain-language guidance. I think the overall shape is very strong. The explanations make clear what each check actually looked at, and the outcome-specific next steps avoid generic advice. In particular, the distinction between a stored copy, a verified-readable copy, and a full restore comes through clearly. The handling of a check that could not run also reads honestly rather than implying a clean result. I would only suggest two small wording adjustments before the pattern is repeated elsewhere:
Everything else reads clear, concrete and useful to a non-specialist. I would be comfortable using this as the pattern for the remaining areas, then reviewing the Slovak copy once the English shape is settled. |
|
Hi @Vaso73, Both are in, and you were right on each count. The task log records how a run ended, not what sits on the destination — asserting no usable copy was the check speaking past its own evidence. And "nothing stores this node's configuration" claimed to know about backups the Monitor has no way of seeing. They read as follows now: Read the error in the task log for these runs. Treat a run that ends with an error as unsuccessful, and confirm an available copy for the guests it covers before relying on one. No stored host-configuration backup is recorded here. Unless one exists somewhere this node cannot see, rebuilding would mean reconstructing the storage, network and user definitions by hand, from whatever notes exist. It's PR #374, with the seven locales retranslated so they don't keep pointing at the old English. With the shape settled I'll carry the pattern into the remaining six areas. Anything that reads wrong to you along the way — wording, tone, a claim that goes further than it should — please just say so. You've already caught two that I'd have repeated thirty-seven times. And thank you, genuinely. Between the Slovak and this kind of review, you've become one of the people this project depends on. |
Uh oh!
There was an error while loading. Please reload this page.
Hi @Vaso73, how are you?
I've just finished the new Audit & Report section. It's a new area focused on giving users an assessment of their servers, and also a place where they can transparently see which ProxMenux actions touch the host. It includes an inventory view, an assessment engine with a findings catalogue, a change journal of ProxMenux's actions on the host, focused reports (security review, backup assurance, capacity & wear) and PDF/print output — so it brings a considerable amount of new user-facing text.
I'd really love for you to take a look at the whole new section, both in case you'd like to improve or correct anything and to provide the Slovak strings so they go straight into the release. If it helps.
No rush on my side. Thanks, as always, for keeping the translations in such good shape.
All reactions