V14/feature/response model type info improvements

[Migaroez]

Prerequisites

• I have added steps to test this contribution in the description below

If there's an existing issue for this PR then this fixes

Description

Added a type property to all ResponseModels that return actionable objects, most of them are entitites.
This helps the frontend to determine what UI they need to show when an intent for manipulation on these items is requested (especially in mixed lists).

Also

• made some ResponseModels more specific
• made all type fields fixed
• updated some controllers to return ResponseModels instead of more general Presentation models.

Possible improvements

For consistency, we are reusing entityUdi keys for most of the types. But we have to introduce some new values and it might not be the correct place to do so.

Reproduction

All fetch endpoints for the following resources should supply a type key that is the same for all endpoints within that resource

• Dictionary
• Document (seperate type for items requested trough the recyblebin endpoints)
• Media (seperate type for items requested trough the recyblebin endpoints)
• Membergroup
• MemberType
• Partialview
• Relation
• RelationType
• Script
• StaticFile
• Stylesheet
• Template
• Language
• User

[kjac]

Hi @Migaroez 👋

A few comments from my part:

1. The new UDI type constants might be somewhat questionable. In general, a UDI type constant should only exist if an entity is uniquely identifiable by said UDI type -- that is, can be queried and/or identified in code (not in human eyes). For example, a document in the recycle bin will still be identified by the Document UDI type.
2. A lot of models need a linebreak between the existing properties and the Type property override.
3. A few changes are exclusively due to added and unused usings. I have noted FolderResponseModel and ContentTreeItemResponseModel, there may be others.

[Migaroez]

Thx @kjac for the critical eye!

2 & 3 have been taken care off.

Regarding point one, I had a different approach previously where i proxied the udis as getOnly strings in a static class combined with constant strings for the non udi types and called it ResourceObjectTypes in the ...Api.Management.Constants namespace.
Advantage was to keep the naming consistent across UDI and resource types while being able to add types that didn't map onto UDI types
But this led some namespace conflicts with introducing a Constants namespace and this is why I abandoned the idea. Any suggestions besides moving the constants namespace under ...Api.Management.ViewModels?

[Migaroez]

Responsibility was moved to frontend