[GH-ISSUE #92] No indication for unsaved changes #59

Closed
opened 2026-02-26 10:35:54 +03:00 by kerem · 8 comments
Owner

Originally created by @cseres3 on GitHub (Jul 19, 2016).
Original GitHub issue: https://github.com/PowerDNS-Admin/PowerDNS-Admin/issues/92

There is no indication if there are unsaved changes. If you edit records and forget to click "Apply Changes" button, all changes are lost and you don't get a warning or notification.

Expected results: clear indication of unsaved changes such as "Apply changes" button being gray by default if there are no unsaved changes and getting colour after changes. Possibly a warning if you try to browse to other page with unsaved changes.

Originally created by @cseres3 on GitHub (Jul 19, 2016). Original GitHub issue: https://github.com/PowerDNS-Admin/PowerDNS-Admin/issues/92 There is no indication if there are unsaved changes. If you edit records and forget to click "Apply Changes" button, all changes are lost and you don't get a warning or notification. Expected results: clear indication of unsaved changes such as "Apply changes" button being gray by default if there are no unsaved changes and getting colour after changes. Possibly a warning if you try to browse to other page with unsaved changes.
kerem closed this issue 2026-02-26 10:35:54 +03:00
Author
Owner

@mathieumd commented on GitHub (Jan 8, 2017):

+1! Without such warning it's too easy to lost a lot of work. The edits should be highlighted (perhaps even a banner in the header with a summary of the waiting changes), and saved in a temporary buffer, so that the user could browser to other page and still get them when coming back to apply them.

The bottom line is that not a single edit/work of the user should be lost, at least not without a warning.

<!-- gh-comment-id:271178593 --> @mathieumd commented on GitHub (Jan 8, 2017): +1! Without such warning it's too easy to lost a lot of work. The edits should be highlighted (perhaps even a banner in the header with a summary of the waiting changes), and saved in a temporary buffer, so that the user could browser to other page and still get them when coming back to apply them. The bottom line is that not a single edit/work of the user should be lost, at least not without a warning.
Author
Owner

@sshipway commented on GitHub (May 27, 2019):

Yes, this should be a simple thing to add but would be soo useful.

<!-- gh-comment-id:496054473 --> @sshipway commented on GitHub (May 27, 2019): Yes, this should be a simple thing to add but would be soo useful.
Author
Owner

@falz commented on GitHub (Feb 8, 2021):

Just encountered this while evaluating PowerDNS-Admin, possibly a showstopper for us. Logically, I would expect one of the two behaviors:

  1. Changes apply when you hit save, have NO apply button at all.
  2. If you don't apply, you get a popup message preventing you from navigating away due to this, and perhaps even a 'do you want to apply now' button there.

I haven't dug in to the technical reason that Apply is required, could someone enlighten me?

Also, even a simple banner at the top indicating that you must apply would be an improvement.

<!-- gh-comment-id:775150828 --> @falz commented on GitHub (Feb 8, 2021): Just encountered this while evaluating PowerDNS-Admin, possibly a showstopper for us. Logically, I would expect one of the two behaviors: 1) Changes apply when you hit save, have NO apply button at all. 2) If you don't apply, you get a popup message preventing you from navigating away due to this, and perhaps even a 'do you want to apply now' button there. I haven't dug in to the technical reason that Apply is required, could someone enlighten me? Also, even a simple banner at the top indicating that you must apply would be an improvement.
Author
Owner

@sshipway commented on GitHub (Feb 8, 2021):

@falz Having the two-stage update (IE, you make the record changes, then Apply) makes sense because often you need to have a number of changes applied atomically. For example, remove the old A record and replace it with a CNAME all in one go. By having the Apply step, you can get everything looking right, then do one Apply action (and have one entry in the log). Ideally, this would then also be able to be reverted at a single click in the log, though that feature is not yet available...
I can see why its a bit of a PITA to have the two-stage apply when making a single change, though.
As an aside, other systems (e.g. pfSense firewall) have a similar change-and-apply system.
Possibly, it could be a configuration switch to toggle behaviour between apply-immediately and two-stage-apply?

<!-- gh-comment-id:775380227 --> @sshipway commented on GitHub (Feb 8, 2021): @falz Having the two-stage update (IE, you make the record changes, then Apply) makes sense because often you need to have a number of changes applied atomically. For example, remove the old A record and replace it with a CNAME all in one go. By having the Apply step, you can get everything looking right, then do one Apply action (and have one entry in the log). Ideally, this would then also be able to be reverted at a single click in the log, though that feature is not yet available... I can see why its a bit of a PITA to have the two-stage apply when making a single change, though. As an aside, other systems (e.g. pfSense firewall) have a similar change-and-apply system. Possibly, it could be a configuration switch to toggle behaviour between apply-immediately and two-stage-apply?
Author
Owner

@falz commented on GitHub (Feb 8, 2021):

That example of a multiple stage apply makes sense to me. I'm not necessarily advocating for an apply-immediately, just trying to understand why, and that's sound reasoning.

Indeed, the issue is that you can navigate away without applying, without warning, and your changes are lost, and you may not notice, so definitely hoping something can be addressed with this part.

<!-- gh-comment-id:775388164 --> @falz commented on GitHub (Feb 8, 2021): That example of a multiple stage apply makes sense to me. I'm not necessarily advocating for an apply-immediately, just trying to understand why, and that's sound reasoning. Indeed, the issue is that you can navigate away without applying, without warning, and your changes are lost, and you may not notice, so definitely hoping something can be addressed with this part.
Author
Owner

@sshipway commented on GitHub (Feb 8, 2021):

Yes, I do agree that it should be clearer when there are unapplied changes. Possibly the 'apply changes' button shouldn't even be displayed if there's nothing pending, and when it is it should be in a nice big red banner with "Pending changes not yet applied: in it

<!-- gh-comment-id:775401431 --> @sshipway commented on GitHub (Feb 8, 2021): Yes, I do agree that it should be clearer when there are unapplied changes. Possibly the 'apply changes' button shouldn't even be displayed if there's nothing pending, and when it is it should be in a nice big red banner with "Pending changes not yet applied: in it
Author
Owner

@falz commented on GitHub (Feb 23, 2021):

Additional note when looking at this again: the code has some error checking warning if you hit apply before save, which shows a big red warning:

https://github.com/ngoduykhanh/PowerDNS-Admin/blob/master/powerdnsadmin/templates/domain.html#L207

Something equally scary (big red warning) seems ideal if one attempts to navigate away.

OR possibly something in button_save put something less scary on screen to tell you to hit apply - less of a popup and more of an 'unsaved changes' warning somewhere.

https://github.com/ngoduykhanh/PowerDNS-Admin/blob/master/powerdnsadmin/templates/domain.html#L267

It appears that Datatables is being used for the legwork behind the scenes here, they have some sample code in various languages for this scenario here:

https://editor.datatables.net/examples/api/confirmClose.html

There is also a 'save state' example that perhaps could help keep the staged changes?

https://datatables.net/examples/basic_init/state_save.html

<!-- gh-comment-id:784305265 --> @falz commented on GitHub (Feb 23, 2021): Additional note when looking at this again: the code has some error checking warning if you hit apply before save, which shows a big red warning: https://github.com/ngoduykhanh/PowerDNS-Admin/blob/master/powerdnsadmin/templates/domain.html#L207 Something equally scary (big red warning) seems ideal if one attempts to navigate away. OR possibly something in `button_save` put something less scary on screen to tell you to hit apply - less of a popup and more of an 'unsaved changes' warning somewhere. https://github.com/ngoduykhanh/PowerDNS-Admin/blob/master/powerdnsadmin/templates/domain.html#L267 It appears that Datatables is being used for the legwork behind the scenes here, they have some sample code in various languages for this scenario here: https://editor.datatables.net/examples/api/confirmClose.html There is also a 'save state' example that perhaps could help keep the staged changes? https://datatables.net/examples/basic_init/state_save.html
Author
Owner

@jbe-dw commented on GitHub (Apr 25, 2022):

Hello,

We are cleaning the issue tracker and closing your issue. You can follow the status here: #1178

Regards
PowerDNS Admin Team

<!-- gh-comment-id:1108706423 --> @jbe-dw commented on GitHub (Apr 25, 2022): Hello, We are cleaning the issue tracker and closing your issue. You can follow the status here: #1178 Regards PowerDNS Admin Team
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/PowerDNS-Admin-PowerDNS-Admin#59
No description provided.