Skip to content

URI handling for templates #64

@niallroche

Description

@niallroche

Discussion 🗣

Templates have Uris but also ids to identify them, this can cause some issues.

Templates have a URI but also a separate id field that is assigned by the server when templates are created. This separation is useful as, depending on the storage mechanism used by the APAP server, URIs may not be valid identifiers for the storage mechanism used (e.g. filename/database field).

We have the issue around potential conflicts where the same uri scheme could be used for different templates, and these would have different ids and the same uri and we need to define the appropriate behaviour for managing this.

In the current implementation agreements refer to templates by URI, not id so there is an issue here if more than one template shares the uri. Therefore if this is the desired behaviour, then a validation rule will need to be added where a uri is checked to be unique when creating templates and a 409 Conflict response returned.

Agreements also have URIs, so presumably similar consistant logic will need to apply here too.

There is a related concern where a user tries to create an agreement that refers to a valid uri, but one that they did not create. Maybe we need a public flag for some templates? I am conscious that this can get tricky with access control groups and template/agreement sharing within an organisational group.

As mentioned on the working group call, thoughts are welcome @dselman

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions