Issue Diagnose & Repair missing information

[Azurel]

Server operating system version

AlmaLinux 8.10

Plesk version and microupdate number

18.0.65

Hey, there is Diagnose & Repair /modules/repair-kit/index.php/index which is cool, but I'm here lost.

1. What means "No issues detected" and when was this tested? In particular, the check for the file system takes an extremely long time. So "No issues detected" as default text is a bad choice.

2. And if I carry out a manual check myself, then please include the date and time of the last check. I don't assume that the system automatically tests itself and if it did, this information would be missing.

Thanks

 

[learning_curve]

Hey, there is Diagnose & Repair /modules/repair-kit/index.php/index which is cool, but I'm here lost.

Why? It's a simple GUI for those who prefer not to use the more detailed and more informative CLI option:

Plesk Repair Utility

The Plesk self-repair functionality enables you to automatically diagnose and resolve issues with Plesk and Plesk services. If you encounter an issue with one of the Plesk services (for example, if mail is not being sent or delivered, or a website fails to open, and so on), or with Plesk itself...

docs.plesk.com

1. What means "No issues detected"

Exactly what it says

and when was this tested?

When YOU last ran the GUI interface. WYSIWYG. If you need a time-date stamp on every simple GUI interface, then....

In particular, the check for the file system takes an extremely long time.

Have you considered why that is AKA How detailed test this is (in comparison to the other tests shown)?

So "No issues detected" as default text is a bad choice.

It's not default text. See your own Point 1. above

2. And if I carry out a manual check myself, then please include the date and time of the last check.

Why? See your own Point 1. above
Plus: Just use the CLI option instead (if a time-date stamp is critical to you, as you can retain all of those records) and/or - IF - you're not working to any predefined maintenance schedule of your own, which utilises a system of logs etc

I don't assume that the system automatically tests itself

Correct

and if it did, this information would be missing.

Perhaps this last comment is largely academic now?

 

[Azurel]

Thanks, but ....

You get to a page that first says in green that everything is OK, so you assume EVERYTHING IS OK, I can close this page, all is fine. Now you do a check and it finds errors. This is simple bad design!

"When YOU last ran the GUI interface."
Okay... very helpful. What if I'm not the only admin? Especially with such long checks as in the file system, this display would be helpful for colleagues.

"Have you considered why that is AKA How detailed test this is (in comparison to the other tests shown)?"
My statement referred to the missing timestamp BECAUSE some checks take a long time so that they are not started unnecessarily in short time. I did NOT criticize that it takes a long time.

 

[learning_curve]

You get to a page that first says in green that everything is OK, so you assume EVERYTHING IS OK, I can close this page, all is fine.

Assumptions are not test results

Now you do a check and it finds errors. This is simple bad design!

No. It's a dynamic, interactive GUI.
The results you see were presented, the last time you (or somebody on your team) used that dynamic interactive GUI

"When YOU last ran the GUI interface."
Okay... very helpful. What if I'm not the only admin?

You can't use your own team's communications / their interactions (or any lack of) as the basis of a complaint stating "...simple bad design"
If you have multiple admin users, but only one shared interface, then it's team housekeeping & management that may need more focus, surely?

Especially with such long checks as in the file system, this display would be helpful for colleagues.
"Have you considered why that is AKA How detailed test this is (in comparison to the other tests shown)?"

To be fair, only seen your own opinion that this ^ is an actual issue. There may be others, but there are probably very few.
Many people want a pretty simple, non-cluttered look for GUI interfaces, but with CLI in-depth analysis / testing as an alternative too.
So, is it really an issue? Or is it personal preference and this GUI doesn't meet your own expectations? That would make more sense.

My statement referred to the missing timestamp BECAUSE some checks take a long time so that they are not started unnecessarily in short time.

You were given an answer (& a link) for your time-date stamp requirements, but you've completely avoided mentioning that... Why?
Is CLI not suitable for you and this specific functionality?

I did NOT criticize that it takes a long time.

It may have been unwittingly implied, because (purely a guess) English is possibly not your 1st language, so that's understandable and no problem. Thanks.

 

[Azurel]

Assumptions are not test results

Is it the default text you see when you open the page and it is identical when you do the check. If you don't make a mental list in your head, you don't even know where you've already done a check.

That's your opinion and I have mine. Let's leave it at that way.
But anyway, I now know that the initial text there is nonsense and you have to do a check first.

My suggestion would have been to display the text “No issues detected” only after a check has been carried out and not immediately when you call up the website, because the text is simply wrong if errors do occur during the check. I would have recommended not displaying any text at all at the beginning. simplest solution.

 

[Maarten]

Hey, there is Diagnose & Repair /modules/repair-kit/index.php/index which is cool, but I'm here lost.

1. What means "No issues detected" and when was this tested? In particular, the check for the file system takes an extremely long time. So "No issues detected" as default text is a bad choice.

2. And if I carry out a manual check myself, then please include the date and time of the last check. I don't assume that the system automatically tests itself and if it did, this information would be missing.

Thanks

I completely agree; that's a fair point. The "No issues detected" message could definitely cause confusion, especially without a timestamp. Ideally, the repair kit should show this only after a new manual check, so it’s clear the results are up-to-date. Adding a date and time for the last check would also make a big difference in usability.

 

[Azurel]

Oh. After you quote me, i see there is a line missing in my first point. should be:

1. What means "No issues detected" and when was this tested? In particular, the check for the file system takes an extremely long time. After use check, there was errors. So "No issues detected" as default text is a bad choice.

 

[Maarten]

Could you possibly provide some screenshots? It sounds like the "No issues detected" message might be showing up even after errors were found, but I'm not entirely sure if I follow. Screenshots would really help to see what you're experiencing.

 

[learning_curve]

~~ The "No issues detected" message could definitely cause confusion, especially without a timestamp.

Excluding the OP - Has it?
If it has, it's not been an issue with many (if any ) relevant comments posted on here (so far). This thread may change that of course, but, at this point in time etc

Ideally, the repair kit should show this only after a new manual check, so it’s clear the results are up-to-date.

It does. It's the default showing of this "No issues detected" message, not any post test message, that would be the same message IF there are NO issues, or a different messge IF there ARE issues, that the OP is commenting about. Specifically, that the default presentation "No issues detected" message & any post test (one that has no issues) message, are identical.

Adding a date and time for the last check would also make a big difference in usability.

Yet, as per the first item / post #4 etc - IS this part, really an widespread issue and/or is it that CLI is preferred by those that do need this specific data?

~~ It sounds like the "No issues detected" message might be showing up even after errors were found, but I'm not entirely sure if I follow ~~

I think it's just language / translation nuances, as the OP's issues are pretty clear to be fair. See below:

1. What means "No issues detected" and when was this tested? In particular, the check for the file system takes an extremely long time. After use check, there was errors. So "No issues detected" as default text is a bad choice.

The 1st issue for the OP is:
The default "No issues detected" message, is presented by default, so he, cannot determine the date/time of the last actual test via this current GUI.
He could, quite easily determine the date/time via CLI, but for his own reasons, does not to want to utilise that option, which is fair enough.

The 2nd issue for the OP is:
The potential effect (of the File System test section, taking a long time) on the time/date factor, which is being requested as part of a fix suggested by the OP that is his concern here. It is NOT the duration of the File System test itself, as he has since stated.
FWIW Again this is also negated via CLI

The final Issue, commencing with 'After use ...' above, is facts (i.e. a test with issues), followed by a comment, that's using those facts, to underline the OP's main issue AKA the potential confusion (for him & one that's supported by yourself) caused by using the "No issues detected" message, by default. on this GUI, but with no accompanying date/time stamp, to allow him to determine IF; this was post a previous test OR. knowing that this is just the default GUI presentation.

 

[Maarten]

The main question here is whether the default "No issues detected" message could benefit from added clarity, like a timestamp of the last manual check. This would help users see whether the displayed message reflects a recent test or is simply the default view.

For those who rely on the GUI over the CLI, a timestamp could be a practical improvement. Let's see if we can get a response from the Plesk team about this usability suggestion.