Refactor facades to cleanup code and split api methods from internal ones and authorize api methods

[leventegal-she]

Feature Description

Refactor facades to cleanup code and split api methods from internal ones.

Problem Description

A lot of facade ejbs have common super class and some of them override methods but never call the super one. Since there are multiple levels of abstractization it's not clear which methods are meant to use internally (e.g. facade to facade calls) and which ones are api methods (the ones called from the UI module or REST module). Sometimes there are internally used methods daclared as api methods. Also api methods needs to be authorized using @RolesAllowed as requested on #5057. This is a followup ticket of #5057.

Proposed Change

This needs to be discussed/refined

For all facade ejb classes.

• [ ] Move the implementation into FacadeEjbLocal class and extract tu a separate class file.
• [ ] inject the FacadeEjbLocal into the FacadeEjb and the implementation of the api methods should call the corresponding methods on the FacadeEjbLocal.
• [ ] Add @RolesAllowed annotation with the corresponding user right on each api method in the FacadeEjb class
• [ ] Check usages of public methods and don't create an api method for the ones that are used only in the backend module

Make sure method overrides call super method if possible -> #8508

Possible Alternatives

Additional Information

[MartinWahnschaffe]

Before we touch this we need a clear vision of what the backend class architecture should look like.

If we decided to have a third layer here, the layers might be named: Facade -> Service -> Repository/Dao

What is especially important is to clearly define what part of the logic has to go into each layer and to test this with unit tests.

One example would be the question which classes can access the entity manager. My feeling is that Facades should no longer be able to do so.

Another example is the question where a method like "archiveAllArchivableCases" should be located. This should probably also not lie in the Facade, but instead either in the Service or maybe in a Repository class.