From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rymes To: development@lists.ipfire.org Subject: Re: Aw: Re: [PATCH] Fix for Bug #12050: Adding fixed leases with one 'add' click Date: Mon, 20 May 2019 12:03:32 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5937202181812761845==" List-Id: --===============5937202181812761845== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 op= en 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. >=20 > 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=20 shouldn't require a second click, IMHO. Add the dynamic lease as fixed,=20 then present the user the option to change things, such as name,=20 address, etc. after it has already been added. >>> - Adding a dynamic lease to the fixed leases should work in two steps: fi= rst the data from dynamic leases is copied to the edit fields, user can chang= e and complete the definition and adds this by clicking "add". A check for di= sjunction 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 a= dded right away, but you can still edit it to give it a better name or so. Th= is what currently seems to be broken. >> >=20 > 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 stati= c 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 u= p 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=20 distinct is a good goal, that is a separate change from the newly=20 introduced bug, and should be handled separately. IPFire has allowed the=20 user to add fixed leases that overlap with the dynamic address scope for=20 as long as I have used the product, and it's not really a high-priority=20 issue IMHO, so mixing it up with the fix for the new bug seems like a=20 bad idea to me. Here is the bug I opened on that subject a number of years back:=20 https://bugzilla.ipfire.org/show_bug.cgi?id=3D10629 Tom --===============5937202181812761845==--