Univention Bugzilla – Bug 50704
Improve DHCP Frontend in UMC
Last modified: 2020-07-27 11:45:48 CEST
The DHCP configuration causes a high load of support tickets as the customers are having severe difficulties in configuring the service through UMC. I am fully aware the UMC follows the LDAP rules from ISC DHCP but shouldn't the frontend offer a USEABLE way to configure the service? Customers expect to configure DHCP (more or less) as follows: Enable or disable DHCP for a network Configure Ranges, Gateway, Domain and DNS for every network separately Easy way to configure static DHCP clients (here I could imagine to match/display entries with the computers-module) Customers do NOT expect policies to be inherited from an upstream configuration item. For them DHCP networks are all equal rights. Even if then a lower item should be able to overwrite parent rules... Again, I am aware how DHPC LDAP works. But this is really confusing for customers.
Another example for confusion can be seen in bug #49837
Priorities: - display DHCP settings from "network" point of view, not the LDAP structure - remove/hide "pools" (use only "ranges") - remove/hide "server" objects (create them automatically) - allow multi-edit, remove/hide policy based settings
A customer complained yesterday in the course of another ticket about the standstill in the processing of the DHCP interface. Progress in sight? btw I was not able to add the ticketnumber 2020061721000631 as the field is allready full...
There is currently no big change planned in the roadmap, this can be done once we are closer to UCS 5.0. The challenge here is that this Feature Request is very generic. it would be very helpfull to have individual Feature Requests for the various ideas and measure the customer feedback there. A general remark: we made bad experiences in "hiding" the real data structure in the frontend, because users won't understand why there are some behaviours, defaults or constraints. To ease the management we should also change the data structure.
(In reply to Ingo Steuwer from comment #4) > > The challenge here is that this Feature Request is very generic. it would be > very helpfull to have individual Feature Requests for the various ideas and > measure the customer feedback there. I do not see why (and how!) this can be split in several feature requests. There are a lot of customers having issues with this structure. Is the number of tickets attached not enough measurement from customer point of view? Why (and how?) another metric? > A general remark: we made bad experiences in "hiding" the real data > structure in the frontend, because users won't understand why there are some > behaviours, defaults or constraints. To ease the management we should also > change the data structure. Currently most of the uses (I would say 90%) do *NOT* know the LDAP structure of ISC-DHCP. So implementing a frontend which behaves similar to 99% of all DHCP frontends (including MS) on the market should match the customers expectations. I am well used to DHCP and troubleshooting but up to this bug I had no clue about the LDAP structure behind it. When using text files as backend you simply add clients to a network and that's it....
example usecase that confuses: creating a new network which has free IP ranges - this needs currently several LDAP Objects