Review Error handling after refactoring

Description

There are a few areas where the error messages could be improved. There is important to make an analysis of all the current places errors needs to be displayed and how they should be displayed (Toast, other element such as the Error Page or an Alert)

For example, when a user does not have access to any course or library (an edge case), the application displays a generic error message instead of indicating that the user lacks the required permissions or access.

It is also important to review whether the error page should be displayed and update the messages if needed (if they are generic we should consider move it inside the component instead of the module location)

Steps to Reproduce

1. Log in with a user account that does not have access to any course or library.
2. Navigate to the application.
3. Observe the error message displayed.

Actual Behavior

A generic error message is displayed.

Expected Behavior

The application should display a more specific error message indicating that the user does not have access to any courses or libraries, rather than showing a generic error. This would provide clearer feedback and help users better understand the reason for the failure.

Start by reproducing the no-access case with a user who has no course or library access, then trace where the generic error is selected and displayed. Review the application’s error messages and decide whether each belongs in a Toast, alert, error page, or component. Done means the no-access case gives a specific permissions message and the relevant error-page behavior and wording are reviewed.