Added section to describe how parts of the UI can be hidden based on user role

[schiwekM]

Hi @renejeglinsky,

a few newcomers mentioned the lack of documentation on how parts of the UI can be hidden based on roles. This section should explain it.

@DanSchlachter Maybe it is also something to include in a tutorial or course / SFlight?

Hope the wording is understandable.

BR,
Marten

[DanSchlachter]

maybe it should be mentioned, that there is a trade-off between having multiple apps for multiple roles or a single app for multiple roles.
You don't want to duplicate the entire app for a small difference in UI -> use small amount of additional logic over creating multiple apps with duplicate code
You don't want to have a lot of logic in one app, when it's easier to define two apps -> use two apps over overcomplicating one app

[schiwekM]

I agree but would argue that this should be part of Providing services or Modelling best practices. In general it is quite common that there is one app but create / edit / delete is restricted to an admin user, I'd say.

[renejeglinsky]

Hi @schiwekM ,
what is the result here? When I'm logged in as admin, I can't see the Books through this service?

[schiwekM]

essentially if you are not the admin than you do not see the EDIT or Create buttons

[renejeglinsky]

This is doing the same as the previous snippet when using Fiori Elements, right? In which cases am I not allowed to do omit the entity container?

[schiwekM]

Yes - EntityContainer is syntactically from an OData PoV correct however in most cases Fiori elements allows you to leave it out. For compatibility I added the entity container notation if something does not work that users can try the syntactically correct one.