Description: I use calc a lot, I have it on autosave and I have never lost data. If I forget to close a file and I shut down, or if I have a power outage, when I start up a ods file again having left a file open it always stops the process of opening the file I want in order to ask me if i want to recover previous files. It then churns away and a few moments later it asks me if I want to “finish” the recovery. I always say yes to both questions - I would like the option to pre-choose "always recover" and "always finish" so I can choose to open a file, walk away and when I come back its just open rather than asking me these same questions. Steps to Reproduce: 1.save a calc file 2.leave it open, even past the autosave time frame 3.force reboot computer and try to open the same file again. Actual Results: I do the above and attempt to open the same file and it invariably asks those questions to which I have never in my life answered "no" Expected Results: I never see that dialog again, the program just opens, and if I loose data I will consider it to be my fault, not the programmers' fault. (I have backup scripts I'm happy with) Reproducible: Always User Profile Reset: No Additional Info: Version: 7.2.2.2 / LibreOffice Community Build ID: 1eb16ced50a80b7125fabf09652dbb09393766d2 CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded
https://ask.libreoffice.org/t/how-to-set-always-recover-and-always-finish/70260
While I think what you suggest is a reasonable feature, I can say that it may be some time before it is implemented. A more immediate way of dealing with the inconvenience of the recovery dialog box would be to create a Sikuli script to click the buttons for you, and have that launch on startup. Or you could just get in the habit of always closing all applications before shutting down, that's what I do.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6444f5e2c5c8b3d1fac12755af09339083c74055 tdf#145606 autorecover: skip "Finish" button if all recovered OK. It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
In my opinion, this is now fixed as much as it should be. The same recovery dialog is used for 3 different kinds of recovery. SessionSave could arguably restore without requiring a "start" button press. However, EmergencySave (soft error recovery) and AutoRecovery (hard error recovery) both deal with buggy situations, and thus I don't think that recovery should begin without the user knowing or being informed. A single click "start recovery" is not very difficult or time consuming, so I have no intention of changing that - not even for SessionSave. I agree that if everything is completely successful, that there is no need for the "finish" button - the patch removes that. However, if there is any other status I think the dialog should continue to display that to the user and wait for a "finish" command. So I consider this bug fixed, but I'll leave it open since the patch doesn't do everything that was requested. P.S. Bug 57414 should have reduced the number of times that AutoRecovery has documents that it asks to recover.
UX/Design team, do you think more needs to be done for this ticket?
(In reply to Justin L from comment #4) > I don't think that recovery should begin without > the user knowing or being informed. This was my first thought too. Ideally no recovery dialog is shown (no crash, no hard shutdown), and if, the user should get feedback. (In reply to Justin L from comment #4) > ...there is no need for the "finish" button - the patch removes that. Sounds as if the dialog needs to be closed with the window controls rather a button. There could be configurations that hides those, and would be unusual anyway. But not directly related to the request, so => fixed.