STORY: Save & keep editing

Description

Currently

The linked data editor displays three actions to the cataloger when in edit mode:

  • Cancel - exit edit mode without making changes

  • Save & keep editing - save changes locally and stay in edit mode

  • Save & close - exit edit mode and save changes to back end

In this context - ‘save’ has two meanings: saving to the browser, and saving to the back end.

The end user, however, will likely assume that ‘save’ has a single meaning and that is saving work to the back end.

Accordingly, the purpose of this card is to modify the behavior of the ‘Save & keep editing’ option, so that the action books changes to the back end, while keeping the cataloger within edit mode.

This card does not change the function of automatically saving work to the browser.

1. Default state

GIVEN that a cataloger is editing or creating a resource in the linked data editor

WHEN the cataloger enters edit mode (for Work or Instance)

THEN the application displays three action buttons: Cancel, Save & keep editing, Save & close

AND Cancel is enabled by default

AND both Save & keep editing, and Save & close are disabled by default

2. Editing - Action buttons enabled

GIVEN scenario 1

WHEN the cataloger makes keys in any values into the new or selected resource

THEN all three action buttons are enabled

3. Save & keep editing

GIVEN scenario 2

WHEN the cataloger selects Save & keep editing

THEN changes made to the resource are booked to the back end

AND the cataloger remains in edit mode

4. Save & close and Cancel

GIVEN scenario 2

WHEN the cataloger chooses either ‘Save & close’ or ‘Cancel’

THEN the either action works as expected

5. Auto save

GIVEN scenario 2

AND that the cataloger has not selected either Save & keep editing or Save & close

THEN the system will automatically save the changes to the local browser

AND the changes will not be booked to the back end.

Environment

None

Potential Workaround

None

Checklist

hide

Activity

Show:

Yury BarsukouJune 25, 2024 at 12:24 PM
Edited

Tested on 290 build, ok for me. Cases added

Siarhei KarolJune 21, 2024 at 1:22 PM

Tips for QA:
regression testing is needed for saving, closing, navigating back to search results and loading a record.

Doug LoynesJune 21, 2024 at 9:48 AM

- let’s keep both buttons active. Its a good question. But I think it would create confusion / uncertainty for the cataloger if the ‘Save & close’ button were disabled after committing a save. What if the cataloger was finished cataloging and wanted to exit from edit mode and the ‘Save & close’ button were disabled? Then the cataloger might think the resource had to be edited again in order to get out of edit mode. To keep things simple, I think it will be OK / sufficient to keep the save buttons enabled.

Siarhei KarolJune 20, 2024 at 10:48 AM

There is a question regarding Case 3 (Save & keep editing):
Should the "Save & keep editing" and "Save & close" buttons remain active after saving? Or will they be disabled after every save until the user starts editing the form?

Could you please clarify this?

Punnoose Kutty Jacob PullolickalJune 18, 2024 at 11:47 PM
Edited

,

For new Work / Instances, the first click on “Save & keep editing” should make a POST API call and subsequent clicks on “Save & keep editing” should make PUT API calls.

When editing an existing Work / Instance, all clicks on “Save & keep editing” should make PUT API calls.

Note that ID of the resource could change after each click on “Save & keep editing”. So, UI should get the ID the resource from the API response and use that ID for the subsequent API call.

Done

Details

Assignee

Reporter

Priority

Story Points

Sprint

Development Team

Citation

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs

Created June 7, 2024 at 1:24 PM
Updated September 4, 2024 at 10:11 AM
Resolved June 27, 2024 at 11:51 AM
TestRail: Cases
TestRail: Runs