Bug 40191 - Design pattern: Redirect user to a view of the record after saving instead of list
Summary: Design pattern: Redirect user to a view of the record after saving instead of...
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: ERM (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Jonathan Druart
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-06-20 09:16 UTC by Katrin Fischer
Modified: 2025-06-24 09:25 UTC (History)
9 users (show)

See Also:
GIT URL:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Katrin Fischer 2025-06-20 09:16:06 UTC
In the ERM module (and admittedly some other parts of Koha) we redirect the user to the full list of records after a change to a record is saved. This means they need to search again to check the changes and seems counter intuitive. 

For us it would seem more intuitive to redirect the user to a "view" of the data instead.

An example: 
1. Add an agreement to the ERM module
2. Confirm: when you save you are redirected to the list of agreements
   https://staff.next.bsz-bw.de/cgi-bin/koha/erm/agreements
3. Edit the agreement, make a litle change and save again
4. Confirm: you are redirected to the list of agreements again

Our suggestion would be to redirect to the view of the agreement on saving:
https://staff.next.bsz-bw.de/cgi-bin/koha/erm/agreements/1
Comment 1 Katrin Fischer 2025-06-20 09:35:03 UTC
Further testing revealed: 

Editing data providers works like this already, so we have a "mixed" situation.
Comment 2 Pedro Amorim 2025-06-20 10:00:34 UTC
This is an interesting topic.
Other software applications sometimes use 2 different buttons for these actions. Like a 'Save' button that saves the record and redirects to the full list, and an 'Apply' button that saves the record and reloads the same form.
Personally, I feel like the above use case is not 100% clear on what each button does exactly, before clicking, but just sharing how other software apps handle this.

Alternatively, we could have:
1) 'Save' // redirects to table list
2) 'Save and continue editing' // stays in form 
3) 'Save and show %resource_name%' // redirects to 'show' page (if exists)

With 2 and 3 perhaps being expandable option buttons?

The above are just my brainstorming ideas.
I really don't think we should set for one or the other behavior only, as inevitably someone will advocate for why the other way is preferable.
Comment 3 Julian Maurice 2025-06-20 10:33:56 UTC
(In reply to Pedro Amorim from comment #2)
> Alternatively, we could have:
> 1) 'Save' // redirects to table list
> 2) 'Save and continue editing' // stays in form 
> 3) 'Save and show %resource_name%' // redirects to 'show' page (if exists)
> 
> With 2 and 3 perhaps being expandable option buttons?

The expandable option buttons could be annoying as it requires multiple clicks when we don't want the default option, but maybe this can be mitigated by having the default option controlled by a user setting, or maybe save & reuse the last option used, ...

But if we had to choose a fixed default, I'd choose 'save and show'. From the 'show' page you should be able to go in 1 click to either the list (breadcrumbs) or the edit form (toolbar button).
Comment 4 Michaela Sieber 2025-06-20 11:25:23 UTC
Perhaps I should add that this request comes from our colleagues who work with the ERM module on a daily basis. So this bug is based on user feedback.

I think for consistency of a product it should be standardized in all modules what happens when you save a record. 
In most soft product I know you are redirected to a "view record" page.

And also in Koha this is the majority in most modules:
- catalog (edit biblio record)
- patrons (edit borrower record)
- serials (edit subscription)
- course reserves (edit course)
- acquisition (edit basket)
- authorities (edit authority)

I absolutley agree with Julien regarding the expandable option button if there is no setting (user or instance) to define the default behavior.

> The expandable option buttons could be annoying as it requires multiple clicks when we don't want the default option, but maybe this can be mitigated by having the default option controlled by a user setting, or maybe save & reuse the last option used, ...
Comment 5 Katrin Fischer 2025-06-20 13:31:51 UTC
+1 for the default being "Save and show"

Usually on the edit forms we only have 2 options: Save, cancel
Maybe having a third button would still be reasonable here.