Feat coverage profiles

[thecalcc]

STT-111

Front-end checklist

• This pull request is adding missing TypeScript types to modified code segments where it's easy to do so with confidence
• This pull request is using TypeScript interfaces instead of prop-types and updates usages where it's quick to do so
• This pull request is using memo or PureComponent to define new React components (and updates existing usages in modified code segments)
• This pull request is replacing lodash.get with optional chaining and nullish coalescing for modified code segments
• This pull request is not importing anything from client-core directly (use superdeskApi)
• This pull request is importing UI components from superdesk-ui-framework and superdeskApi when possible instead of using ones defined in this repository.
• This pull request is not using planningApi where it is possible to use superdeskApi
• This pull request is not adding redux based modals
• In this pull request, properties of redux state are not being passed as props to components; instead, we connect it to the component that needs them. Except components where using a react key is required - do not connect those due to performance reasons.
• This pull request is not adding redux actions that do not modify state (e.g. only calling angular services; those should be moved to planningApi)

[tomaskikutis]

While the task requires being able to configure a distinct content profile for each content type e.g. text, video, audio - the implementation itself at the database level or at data-structure level - should not be coupled to content type. If a new requirement came in tomorrow - that we want multiple profiles for a single content type - that shouldn't require us to do changes to database structure or data structures. It should be enough to adjust the UI in the modal.

I remember discussing this - that we'd retrieve profiles by ID - not content type with @petrjasek. Not sure if you @thecalcc wasn't participating in the discussion or you guys changed the approach.

[tomaskikutis]

field {{name}} is required by the system would be better

[thecalcc]

this code was actually kind of bad. I began reworking it, but it was tied to other bad code, then I realized that some stuff related to embeddedProfile was no longer used now that I decoupled the coverage profiles. So I now have reworked it to work without this case, while achieving the same functionality in a better and more obvious way for the user - by notifying them about each required field

[thecalcc]

While the task requires being able to configure a distinct content profile for each content type e.g. text, video, audio - the implementation itself at the database level or at data-structure level - should not be coupled to content type. If a new requirement came in tomorrow - that we want multiple profiles for a single content type - that shouldn't require us to do changes to database structure or data structures. It should be enough to adjust the UI in the modal.

I remember discussing this - that we'd retrieve profiles by ID - not content type with @petrjasek. Not sure if you @thecalcc wasn't participating in the discussion or you guys changed the approach.

It's not actually coupled to the content_type I think. Now we use that as just a property right @petrjasek ? We can always make the creation of new coverage types also dynamic which would pass on the backend because in the schema it's defined like this: "content_type": {"type": "string", "required": True},. Then we can adjust frontend according to the requirements - instead of working with a static type we'll use ids and list all coverage profiles by fetching them all. Just like we do with article profiles probably. For now how I understand it - we should list profiles for all coverage types, regardless whether they were actually created by the user or not - if not - we render the old profile. If it was created after this update - we show the new data.

[thecalcc]

To add to my comment - now I think we should keep things as they are in the UI. Otherwise we need to either make some workaround (mock some static profiles so users can access the in the profile config) to prepare for a feature that may never come. And when it comes we can add more UI - a plus button to add coverage profiles dynamically, and endless content_types. And a text input for content_type field itself and then fetch everything by id.

[petrjasek]

While the task requires being able to configure a distinct content profile for each content type e.g. text, video, audio - the implementation itself at the database level or at data-structure level - should not be coupled to content type. If a new requirement came in tomorrow - that we want multiple profiles for a single content type - that shouldn't require us to do changes to database structure or data structures. It should be enough to adjust the UI in the modal.

I remember discussing this - that we'd retrieve profiles by ID - not content type with @petrjasek. Not sure if you @thecalcc wasn't participating in the discussion or you guys changed the approach.

we're ready for multiple on the backend, nothing changed in that regard

[tomaskikutis]

image

@dzonidoo could you improve this PR to make button content left-aligned?

See client/components/ContentProfiles/CoverageProfileModal.tsx.
You'll need to add that capability to ui-framework buttons. Use RTL friendly names for the prop
textAlign: 'start' | 'end' | 'center' // defaults to 'center'