This occurs when there's a timeout, on some systems, when asking for the password to the keyring. We'll interpret a timeout as a refusal to enter a password.
Fixes Sentry issue CURA-332.
We changed tree support to have a correct top distance now. If you ask for 0 top distance, you get 0 top distance. If you ask for 0.2mm top distance, you get 0.2mm top distance (rounded to layers). Previously the top distance was too high. Yet it seems that people were happy with how easily Tree Support was removed from the print. So this is a best-effort attempt to keep the final result similar to what it was originally.
It won't work for everything, I fear. But it's about as good as we can make it.
Contributes to issue CURA-7624.
This is normally not possible from the interface. However on MacOS, the application menu gets carried to the top bar of the operating system. It is not blocked there, and the user could write a project file before they even add a printer. This prevents Cura from crashing when they do that.
Fixes Sentry issue CURA-2ZR.
If two requests to the API occur at the same time, they will both see at the same time that they need an access token, and if it is expired they will both see that it needs refreshing. The server then sees two refreshes, both with the same refresh token. This is not allowed. The second one then gets a failure to refresh the token, which causes the user to log out.
Instead, we'll stop one of the refresh requests. They were fire-and-forget anyway, so it's not needed to actually continue the request.
Contributes to issue CURA-8539.
The UserProfile is being stored in the account with a simple assignment, and these are just some property getters with a fallback. I don't think we need to test that.
The actual getting of a user profile (and whether that returns correctly when logged out and such) is already tested as part of the OAuth flow where that code lives.
Contributes to issue CURA-8539.
The return type missing caused the type checker to think it returned Any, which is clearly not true. And the type missing from _user_profile caused it to think it always had to be None, which is nonsense in any application.
Contributes to issue CURA-8539.
It gives two parameters, additionally an error code. However our callback wrapper gets the error code from the reply itself so it doesn't need it.
Contributes to issue CURA-8539.
The actual profile is not necessary for this test. But this function always returns None and we shouldn't patch it to make it return something else.
Contributes to issue CURA-8539.
We're no longer generating that error. We're generating a QNetworkReply with a built-in error code and those errors are handled the same way as the failed requests tested above.
Contributes to issue CURA-8539.
It was previously mocking some return values that should now get returned via callbacks. And it was previously relying on a web service which might not connect at all.
Contributes to issue CURA-8539.
The reply is not really relevant. The reply is mocked through readJSON.
So it turns out that so far, our tests have been making actual requests to the authentication server, and depended on it being online. Not good. Mock those external dependencies!
Contributes to issue CURA-8539.
In this case the callback should get called immediately (no wait) so it is safe to test for this callback, albeit slightly implementation-defined.
Contributes to issue CURA-8539.
Because not having auth data is a reason to return no profile too. Otherwise the other side might wait for a response for a long time.
Contributes to issue CURA-8539.
The `printJob` now also contains a status for detecting aborted prints
that were awaiting cleanup, preventing the need for the additional
checks in the `await_cleanup` status.
It provides 2 arguments (reply and error) which we both ignore and proceed to call failed_callback. And failed_callback may also be None in which case we don't call anything.
Contributes to issue CURA-8539.
As a result, the local webserver now needs to synchronise that with a lock. Otherwise the do_GET function would no longer block, and wouldn't properly be able to return the correct redirect URL.
Contributes to issue CURA-8539.
