Ghost: Staff profile editing incorrectly show "Saved" state

Created on 28 May 2020  路  4Comments  路  Source: TryGhost/Ghost

Issue Summary

When you're editing a staff profile in the admin, edits to the slug make the "Save" button to change to "Saved" even though nothing is saved yet until the "Saved" button is clicked.

To Reproduce

  1. Log in as an administrator.
  2. Go to "Staff" section from the sidebar.
  3. Edit an author profile.
  4. Change the ~name~ slug.
  5. Click outside the input to unfocus it.
  6. Notice the blue "Save" button changes to green "Saved". At this point, most would consider that it has autosaved the changes.
  7. Navigate to another page, you will get prompt if you're sure as changes are not saved.
  8. If you reload the page, you are not prompted and changes are indeed not saved.
  9. You are able to click the green "Saved" button to actually save changes.

Potential solutions:

  • introduce actual autosaving on every form 馃槈
  • make the "Save" / "Saved" buttons on the author edit page behave like everywhere else - keep the blue "Save" button until data is indeed saved.

Other considerations:

When the form is not saved, reloading the page could also trigger a prompt from the browser to confirm the navigation during that dirty state.

Technical details:

  • Ghost Version: 3.17.1
  • Node Version: 12.16.2
  • Browser/OS: Google Chrome Version 84.0.4143.7 (Official Build) dev (64-bit)
  • Database: local install using ghost install local
admin client bug

All 4 comments

Can reproduce this issue on both 3.17.1 and the latest version, but only on changing the user slug field and not on changing the name. Working on a fix for the slug change, though if there is a reproduction scenario I am missing for changing name triggering save button please shout.

I can confirm I was indeed changing the slug, but when writing up the issue I didn't test whether the problem was field-specific. Updated the steps to mention editing the slug. Thanks!

Weirdly, it seems ember-concurrency seems to be triggering all the tasks in a task group as in this case we are explicitly passing down the save task to task button but its states are still triggered when the updateSlug task in the same task group is called, although from the docs i couldn't find anything that suggests this or how to bypass this.

I added a fix in linked PR for task buttons to always check if the last task's name is same as the task name passed down before updating state, which takes care of group tasks and also shouldn't cause any side-effects imo, but will run this by for review from @kevinansfield in case I missed anything that this will break or if there is a better way to handle this before merge

Just waiting on the final review on approach (details 猬嗭笍 ) before merge :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

albizures picture albizures  路  3Comments

RadoslavGatev picture RadoslavGatev  路  3Comments

ArthurianX picture ArthurianX  路  4Comments

marcuspoehls picture marcuspoehls  路  4Comments

HenryMarshall picture HenryMarshall  路  4Comments