Dashboard: Allow editing Local DNS records inline

[brazier]

What does this PR aim to accomplish?:
Allows editing DNS records instead of manually deleting and re-adding

How does this PR accomplish the above?:
Added an edit button that that inserts Inline fileds with the content already inserted, alowing it to be changed, then saved.

Notes:

• Im not to happy with the width of the icons as they differ, fa-fw makes them to wide(1.25 em) would preferd to set them to 1 em but wanted input here.

• As i was working with this i did notice that some tend to use i while others span for fa icons so i didnt think so much about which to use for consistency. Can rewrite if there is a new preferred one.

---

By submitting this pull request, I confirm the following:

1. I have read and understood the contributors guide, as well as this entire template. I understand which branch to base my commits and Pull Requests against.
2. I have commented my proposed changes within the code and I have tested my changes.
3. I am willing to help maintain this change if there are issues with it later.
4. It is compatible with the EUPL 1.2 license
5. I have squashed any insignificant commits. (git rebase)
6. I have checked that another pull request for this purpose does not exist.
7. I have considered, and confirmed that this submission will be valuable to others.
8. I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
9. I give this submission freely, and claim no ownership to its content.

---

• I have read the above and my PR is ready for review. Check this box to confirm

[yubiuser]

I went with v as both the master and dev branched used that in settings-dns-records.js prior.

This is reverted in dev with #3778

[rdwebdesign]

I have a lot of Local DNS records and always felt the the 2 column layout was small and didnt match the rest of Pi-hole.

Note:

This only happens when using the "boxed layout".

Your new layout will be too wide on big screens.

[brazier]

I have a lot of Local DNS records and always felt the the 2 column layout was small and didnt match the rest of Pi-hole.

Note:

This only happens when using the "boxed layout".

Your new layout will be too wide on big screens.

I have never noticed that before after using pi-hole for so many years. Thanks! and reverted. And now rocking the non-boxed mode.

[brazier]

Ill fix the failures first.

[rdwebdesign]

Just one more question:

I also tend to change records often for testing or other purposes. Delteting and then re-adding felt uneccesary.

Did you try to use the Advanced settings page to edit this?

If you need to change the list too often, using the advanced settings would be a lot easier:

[brazier]

Just one more question:

I also tend to change records often for testing or other purposes. Delteting and then re-adding felt uneccesary.

Did you try to use the Advanced settings page to edit this?

If you need to change the list too often, using the advanced settings would be a lot easier:
....

yes, but it wasnt what i wanted. there is no way to sort that list, subdomains that are added later end up in the incorrect spots. If i were to edit them in advanced i may aswell edit the file directly on the filesystem instead.

[DL6ER]

Thanks for reverting the layout - the inline edit feature is the valuable part here. A few things before this can go in:

1. The edit is a non-atomic DELETE-then-PUT and can lose data. updateHostsRecord and updateCnameRecord both DELETE the old record first and only then PUT the new one:

$.ajax({ url: deleteUrl, method: "DELETE" })
  .then(() => $.ajax({ url: putUrl, method: "PUT" }))

If the DELETE succeeds but the PUT fails (e.g., the API rejects the new value), the original record is gone for good, while the .fail branch shows Error while updating ... <oldTag>, which reads as if nothing changed. Since there is no atomic rename endpoint, please reverse the order: PUT the new record first, then DELETE the old one. The worst case then is a harmless duplicate the user can remove, instead of silent data loss.

2. Clearing the TTL silently drops it. In buildCnameRecord, an empty or non-numeric TTL simply omits the segment, so editing a record that had a TTL and blanking the field reverts it to the default with no indication. Please confirm this is intended, or keep the existing TTL when the field is left empty.

3. Description is now stale. I have updated the PR title (the "1column layout" part was reverted). Could you also trim the struck-through layout rationale from the description so it matches what the PR actually does now.

Minor, non-blocking: type="numeric" on the TTL edit input is not a valid input type (it falls back to text), it matches the existing #Cttl field. Both should be fixed together to number

For the record, the env-var handling is a nice catch: the old const setByEnv = false meant the row buttons were never disabled for env-set records, and this fixes that.

[brazier]

@DL6ER Thanks for the input.

1. I have been using this for a while without any issues, but a sample size of one is not good enough as to say it never will happen. I also dont seem any issues with inverting that.

2. This is definitly not intended, and just something i just havent tested as honestly i dont use the CNAME that much, i will look into that.

3. Description is done.

I will also go over the minors once i have a time to sit down. I will need to clone it again and to the changes as i have done further changes, including a better sort, that sorts asc/desc on tld first -> the sld -> subdomain, and the parents are infront of the children. instead of a pure alphabeticly sort, but that is better saved for a second PR.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.