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
We are seeing more and more users (both FFC and Discourse) hitting issues around dashboard editing.
During development I first implemented this differently and feel we may wish to revisit this topic...
When I took over the great foundation Joe kicked off, I hit an issue with API tokens (similar to the one Paul had recently and TBH, there are probably a bunch more edge cases out there) so I changed the workflow to emit the edits to Node-RED WITHOUT deploying them. The user had switch back to Node-RED and press "Deploy" to apply the changes. That eliminated the majority of the friction around merging but would have introduced different UX friction. To get past that poor UX, in my head, the workfow needed to be something like:
User choses to edit a page - a shading overlay dialog covers Node RED and displays "Dashboard Editing Page xxx"
The page to edit is popped out to a separate window (as it is now)
User goes about edits and eventually saves or exits, which returned the user to Node-RED where they would see the shaded dialog once more
The shading dialog would now display the edits that are held in memory (e.g. "Page xxx has undeployed edits") and at this point the user choses to Deploy or Discard the edits.
This meant there would be ZERO back door deploys via API & zero merge issues - everything is handled by the normal Node-RED deploy mechanism.
Current Behavior
Expected Behavior
should save changes
Steps To Reproduce
open a FFC instance, edit a layout, hit save.
Environment
Have you provided an initial effort estimate for this issue?
I have provided an initial effort estimate
The text was updated successfully, but these errors were encountered: