On 05/20/2019 10:21 AM, Bernhard Bitsch wrote:
[snip]
If you plan to change any behaviour of the CGI file, that is a matter open for discussion first and then work should start.
When is this discussed? I made a suggestion of changes of behaviour; yet:
- Adding a new fixed lease adds this directly, without having to click a second time.
That is already the case.
That's not true! Adding a new entry must retain the existing entries, what isn't the case ( see postings in forum ).
I must chime in here that clicking the button add a dynamic lease shouldn't require a second click, IMHO. Add the dynamic lease as fixed, then present the user the option to change things, such as name, address, etc. after it has already been added.
- Adding a dynamic lease to the fixed leases should work in two steps: first the data from dynamic leases is copied to the edit fields, user can change and complete the definition and adds this by clicking "add". A check for disjunction of sets of fixed and dynamic leases would be possible.
If you add it from the DHCP leases list, the static lease is meant to be added right away, but you can still edit it to give it a better name or so. This what currently seems to be broken.
Maybe this the intention of the actual implementation. The misfunction lays in the bug, indeed. But my suggestion goes one step further. It isn't desirable to mix up static and dynamic leases. This is based on the mechanics, how dynamic leases are found by dhcpd ( see man page ). IMHO, the problem with this is not shining up immediately, but some times later ( with no modifications meantime ). A two step process with check if the two sets are disjoint avoids this problem.
[snip]
While I would agree that keeping the dynamic and fixed leases physically distinct is a good goal, that is a separate change from the newly introduced bug, and should be handled separately. IPFire has allowed the user to add fixed leases that overlap with the dynamic address scope for as long as I have used the product, and it's not really a high-priority issue IMHO, so mixing it up with the fix for the new bug seems like a bad idea to me.
Here is the bug I opened on that subject a number of years back: https://bugzilla.ipfire.org/show_bug.cgi?id=10629
Tom