You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the React migration, we improved the recordedit multi-edit result page by adding "Explore" and "Bulk edit" links. This would allow us to go to the recordset page of the edited record or go back to the initial recordedit page.
Given that bulk edit is also available for the related entities, we would like to explore adding a button to allow users to return to the record page they came from.
Details
If users open the link on the same tab, we can easily just go back one step in the history to get to the record page. For other cases, we could use document.referrer, but based on my understanding, it might not be accurate, and it's also not reporting the URL fragment (so we don't know the table name, etc).
This also gets back to the conversation about buttons vs. links. If we want this feature but we cannot easily do this for links, should we change it to be a button?
We had a conversation about this, and the following is the summary of it:
While allowing users to go back to the main record page after bulk edit of related entities makes sense, if there's only one row, chaise will not show any result page. Instead, we're redirecting to the related record page. Should we also show the result page in the single edit/create case then?
Instead of jumping to make a change just for this case, we should think about this broadly. In general, chaise apps do not retain the context, and users get lost. Similar to how in the "buttons vs. links" issue we created a sheet and listed all the buttons, we should list all the navigational button/links in chaise, and see if we can come up with a general solution.
In some cases, going back one step in history works, while in some, it won't work. Maybe instead of allowing users to go back to the original page, we should figure out how we can add "breadcrumbs"?
Therefore, the following is the list of tasks for this issue:
Create a spreadsheet and list all the navigation button/links throughout chaise.
For each one, see if we can offer a "back"/"cancel" button. Or if we were to show breadcrumbs, what would we show? and where would that go?
The text was updated successfully, but these errors were encountered:
Summary
With the React migration, we improved the recordedit multi-edit result page by adding "Explore" and "Bulk edit" links. This would allow us to go to the recordset page of the edited record or go back to the initial recordedit page.
Given that bulk edit is also available for the related entities, we would like to explore adding a button to allow users to return to the record page they came from.
Details
If users open the link on the same tab, we can easily just go back one step in the history to get to the record page. For other cases, we could use
document.referrer
, but based on my understanding, it might not be accurate, and it's also not reporting the URL fragment (so we don't know the table name, etc).This also gets back to the conversation about buttons vs. links. If we want this feature but we cannot easily do this for links, should we change it to be a button?
We had a conversation about this, and the following is the summary of it:
While allowing users to go back to the main record page after bulk edit of related entities makes sense, if there's only one row, chaise will not show any result page. Instead, we're redirecting to the related record page. Should we also show the result page in the single edit/create case then?
Instead of jumping to make a change just for this case, we should think about this broadly. In general, chaise apps do not retain the context, and users get lost. Similar to how in the "buttons vs. links" issue we created a sheet and listed all the buttons, we should list all the navigational button/links in chaise, and see if we can come up with a general solution.
In some cases, going back one step in history works, while in some, it won't work. Maybe instead of allowing users to go back to the original page, we should figure out how we can add "breadcrumbs"?
Therefore, the following is the list of tasks for this issue:
The text was updated successfully, but these errors were encountered: