Include the 'default' profile in the options for the profile to be edited

[jamesrwelch]

Overview

The current bulk-editor only supports profiles defined by a profile service - it would be nice if we could also include the 'default profile' as an option. This may need to be hand-coded, but bulk-editing descriptions will be an important use-case.

Tasks

• Create profile abstraction layer for bulk editor #590
• Implement a default profile provider interception service #591
• Integrate the default profile provider service into the bulk editor #592

[pjmonks]

A "default profile" does not exist as such, but there may be ways to pretend or intercept that idea using profiles, but treated differently.

• If handled in the back-end, it may require extensive implementation to intercept a special profile and map the properties to their hardcoded catalogue item properties.
• Alternatively, the front-end could treat this as a profile in it's own right for display/editing, but would have to handle the read/write operations manually by mapping the catalogue item properties to/from the profile.

However, if it could be treated like any other profile, then the bulk editor should just work by adding additional tabs to the existing edit interface.

Things to consider though:

1. The "default profile" will differ slightly between domain types e.g. a Data Class and Data Element may have slightly different core metadata properties.
2. A plan will need to be made as to how to implement the profile interception (most likely in the front-end).

[pjmonks]

After some architecture review of the current bulk editor, here is my proposal to support "default" profiles.

Profile Object

When using the /api/{domain}/{id}/profiles/... endpoints, they always return one or more Profile objects, structured something like:

{
  "id": "1234",
  "domainType": "DataModel",
  "label": "Profile name",
  "sections": [
    {
      "name": "Section 1",
      "fields": [
        {
          "metadataPropertyName": "keyName",
          "fieldName": "Display name",
          "dataType": "string",
          "currentValue": "Hello"
        }
      ]
    }
  ]
}

The issue with a "default" profile is that such a profile would actually map to concrete data fields in a catalogue item:

{
  "description": "Some text",
  "author": "A. User",
}

So my thinking is to create a a fake profile object to represent the "default" profile:

{
  "id": "1234",
  "domainType": "DataModel",
  "label": "Default profile",
  "sections": [
    {
      "name": "Default",
      "fields": [
        {
          "metadataPropertyName": "description",
          "fieldName": "Description",
          "dataType": "string",
          "currentValue": "Some text"
        },
        {
          "metadataPropertyName": "author",
          "fieldName": "Author",
          "dataType": "string",
          "currentValue": "A. User"
        }
      ]
    }
  ]
}

This would be a special Profile object though:

1. It would not be retrieved from Mauro - since no plugin or profile service would provide this. Instead, the UI would manually create this Profile object and map a catalogue item to each currentValue
2. Saving this default profile would also have to be intercepted, as the /api/.../profile endpoints would not accept it. Instead, the UI would grab this and map all currentValue properties back to the original catalogue item, then save the item via a POST request.

Bulk edit abstraction layer

To intercept this special profile object, first the bulk editor components need to have an abstraction layer added between the UI components and the Mauro API. This will allow the UI to continue functioning when the abstraction layer can then be refactored without affecting other components/services.

Profile services

Two Angular services can then be created that map to a common function interface:

1. MauroProfileService - handles profile operations using only the Mauro REST API, namely the /api/.../profile endpoints.
2. DefaultProfileService - handles the interception of the special "default" Profile object, wrapping fetch/save operations around other endpoints instead.

These two services combined can then combine to handle the same operations required for the bulk editor to work, namely:

1. Fetch all profile objects
2. Validate all profile objects
3. Save all profile objects

By treating the "default" profile as just another Profile to use, this will allow the UI components to continue to function as before.

Next steps

1. Confirm with @jamesrwelch if this approach is acceptable. Or identify ways for the backend to do a similar job.
2. Break down into further sub-tasks for implementation.

[pjmonks]

All issues (sub-tasks) under this main task have now been completed/merged, this issue can also be closed now.