Revise set of core elements based on new/updated attributes

[chrisdburr]

User Role

Developer

Goal / Desire

New attributes and respective UI fields for the core assurance elements

Benefit / Reason

The TEA platform is more aligned to GSN Standard (V3)

Acceptance Criteria

• The TEA platform allows users to add new attributes to existing elements
• The TEA platform allows users to edit attributes that have already been added
• The TEA platform allows users to be able to delete attributes
• When an assurance case is shared or published, attributes are inlcuded
• Existing assurance cases with context elements, will be converted following merge of this issue

Additional Notes / Considerations

List of Revisions

1. Goal Elements to have Context (many allowed) and Assumption (one only)
2. Separate context element/node to be removed
3. Property claims to have Context (many allowed) and Assumption (one only)
4. Strategies to have Context (many allowed), Justification (one only) and Assumption (one only)

• GSN Community Standard: https://scsc.uk/r141C:1?t=1

[RichGriff]

UI elements have been added/updated.

Removed the rendering of Context nodes

Assumption and Justification fields added - as per request (justification only on strategies)

Manage Contexts added - allowing for users to add a context and then list out any already present for the node (plan is to allow users to remove contexts also)

These images will include some sample content, as the next step is to complete work in the api to handle these new requests.

[chrisdburr]

Thanks, @RichGriff.

My preference would be to have a single Manage Attributes button for all elements (rather than Manage Context), which then lets a user add either Context, Justification, or Assumption conditional on which element they have selected (e.g. if a Goal element is selected, they can add multiple 'Contexts' and one 'Assumption', see above).

This way, all attributes would be managed from within a single pane.

As a suggestion for UI, perhaps the user could select what type of attribute (from a drop-down) they are adding when they enter the text.

[chrisdburr]

I've also added an additional acceptance criteria to this issue, because we will need a way to handle conversion of existing cases where context elements are already added. Perhaps a pop-up that tells users that any existing context elements can now be found under attributes?

[RichGriff]

@chrisdburr The reason I approached it like this with 'Manage Contexts' is because that screen allows users to add a new context as well as view existing ones on that node.

And added assumption along with justification below description because they are properties on the node itself.

// Goal
{
id: 1
....
description: '',
assumption: '', // single property
contexts: [] // collection
}

I was thinking it would be best to show the information on the first screen when a user selects a node to view/edit.

[chrisdburr]

It may be best for you to demo this to me live so I can see the UI in action.

However, I will note that I think my preference is going to be to group these (i.e. contexts, justifications, assumptions) all as "attributes".

[RichGriff]

@chrisdburr this is now in staging for review

[RichGriff]

@chrisdburr just pushing new UI updates for the Attributes into Staging.

I have left out the contexts as this will need a some design work for frontend and backend. But will keep this task open for those changes.

[chrisdburr]

Thanks, @RichGriff

Please let me know if you have any questions about possible UI options.