-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update metadata templates when their components change #26
Comments
@egyedia @muakdogan As discussed last week, I've entered a short description for this task and moved it to the top of your In-Progress column. Please, start working on it and report status on Wednesday. Thanks! |
These are my thoughts as of now: Triggering conditions: If a field is updated, If an element is updated If a template is updated Only the artifacts that the user owns are shown for update There should be an overview screen, either a multipage wizard like, or a long scrolling page. An artifact which is candidate for update, has three options: The overview page actualizes it's state based on decisions taken at every point The instances can be rendered invalid after such a change. Or they can loose data. The wizard should do it's best to align the instances with the new template. These instances should be collected into a work package, a collection that the user later can access. |
In addition to Atti some thoughts of mine:
|
This is a plan to create the graph changes that are needed to implement the functionality: Graph changesA new relationship,
Initial Neo4j update task.
Keeping the graph up-to-dateEvery time a template or element is saved, the artifacts included at the first level are summarized, and the outgoing arcs from the current artifact are updated. This means deleting or creating arcs. Incremental Neo4j update taskIt is a possibility to run the |
Consider using two different relationships INCLUDES_ELEMENT and INCLUDES_FIELD instead of a single INCLUDES relationship. A single relationship might be the right approach, since it's easier to implement and maintain, and handles easily the use case "Retrieve all nested artifacts." However, if there's potential for the meanings or attributes of INCLUDES_ELEMENT and INCLUDES_FIELD to diverge in the future (I don't think so), different relationships would be a better idea. @matthewhorridge @martinjoconnor any thoughts? |
Proposed solution for the UI and REST endpoint. First request right after the update of an artifact (field or element) was successful:
Response:
The user is presented with two grids of elements to be updated, and two grids of templates to be updated. If the artifacts was an element: Once the user made changes in the tables, the view can be updated (either automatically, or with a "Refresh" button) The request should be:
This is practically the same data that was returned, with the operations changed. The whole data structure can be sent, but only the "@id" and the "operation" fields will be taken into account. The result will be the same structure with a different number of entries in each four blocks, depending on the choices made in the previous step. Once the user is content with the setup, they can click on the "Apply Changes" / "Propagate Changes" button. A call should be made to:
with the same datasatructure as before, only the "@id" and "operation" fields matter. At this stage we only handle the propagation of changes to artifacts that the current user (the one making the original modification) has write access. In a later stage we will update the model so that other users can update their artifacts as well as a result of a change. |
There are two ways:
or
The second case is somewhat redundant, because from the two endpoints of the arc the arc type can be deduced. |
Update
First call
First response
Second requestIf the user chooses to update
Second responsePlease note the element
Committing the changesThe above flow only previews what would happen if the user was to commit the changes. No real changes are applied to the graph or artifacts in the
The body should be the same structure as in the second request. This flow is stateless, the back-end does not keep track of any state, it always computes the affected artifacts based on the request body. At this implementation phase no change detection is in place. After applying changes the whole process could be restarted from the top, and it would result in a similar flow. |
List of things we agreed on after out meeting with @egyedia:
|
Thanks @muakdogan, please consider the following ideas:
|
@egyedia Could you please update the end date for this task with a reasonable new estimate? |
We are currently working on this task. To better understand our progress, I am outlining the backend subtasks here:
This issue also needs a frontend component, which presents the REST API responses in a human-interpretable way. This part is developed by @muakdogan , I will let him report the progress of that subtask. |
The update REST endpoint is done, and ready for integration.
@muakdogan let me know if you run into any issues during the frontend integration! |
We'll consider that this work is part of this task. |
RE: Apply changes UI/UX I suggest listing all the artifacts with the updated 'field1' and adding a checkmark next to each one. This will allow users to select which artifacts need the updated version (see image below). If users select an element item where it is being used by other artifacts, the system automatically selects the associated elements and templates. Users cannot modify these auto-selected items such that the checkboxes are disabled (see image below). However, in my opinion, the vice-versa should be different: if users select the template item first, it is not necessary for the associated element to receive the update. |
With respect to selectively pushing a field update, I think this can cause some serious consistency issues down the line after just a few updates. From the perspective where a I thought that strict versioning might be able to mitigate this problem, so that you could have |
We installed the feature branch onto our staging server to test it out. |
Design and implement a CEDAR feature to update metadata templates in response to modifications in their embedded template elements or fields. This work involves both backend and frontend effort.
Suggested workflow:
This issue focuses on the most basic version of this task.
@egyedia: Primary (Backend)
@muakdogan: Primary (Frontend)
@martinjoconnor: Reviewer
@matthewhorridge: Reviewer
The text was updated successfully, but these errors were encountered: