luci-mod-network: DHCP tabs redesign phase 2 #7178
Conversation
| _('Options to be added for this tag.')); | ||
| so.rmempty = true; | ||
| so.optional = true; | ||
| so.placeholder = '3,192.168.10.1,10.10.10.1'; |
There was a problem hiding this comment.
Wouldn't it be nice to add a validation there so that a combination of wrong option doesn't crach the dnsmasq?
Or even better can we not abstract this further without having to look up in the documentation of dnsmasq what option for example '3' exactly means?
There was a problem hiding this comment.
Maybe code golf one day.
But the user is nevertheless expected to know what settings they need. (There are lots of them).
| so.rmempty = false; | ||
| so.optional = false; | ||
|
|
||
| so = ss.option(form.Value, 'networkid', _('Set this Tag')); |
There was a problem hiding this comment.
should we not replace this string Set this Tag with string ... To this matching Tag, then it would remain consistent.
There was a problem hiding this comment.
In short: no. That would change the meaning of how this tag tab works.
| ss.rowcolors = true; | ||
|
|
||
| so = ss.option(form.DynamicList, 'dhcp_option', | ||
| _('Apply these DHCP Options...'), |
There was a problem hiding this comment.
Since it is a table I would prefer that we change the following strings Apply these DHCP Options... and ... To this matching Tag. This text should not be seen as a sentence. Maybe this can`t be translated like this in other languages.
Apply these DHCP Options... -> DHCP options
... To this matching Tag -> Matching tag
There was a problem hiding this comment.
Other languages are very capable of expressing this. I want these settings to be abundantly clear, because tags are evidently tough to grasp.
| so.optional = true; | ||
| so.placeholder = '3,192.168.10.1,10.10.10.1'; | ||
|
|
||
| so = ss.option(form.Value, 'tag', _('...To this matching Tag')); |
There was a problem hiding this comment.
Change text ...To this matching Tag?
See above.
There was a problem hiding this comment.
That would confuse its meaning (implying how tags are used here)
| ss.modaltitle = _('Edit Match'); | ||
| ss.rowcolors = true; | ||
|
|
||
| so = ss.option(form.Value, 'match', _('Match this client option(+value)...')); |
There was a problem hiding this comment.
I'm not sure whether we can form a sentence from the table headings in all languages.
Match this client option(+value)... to Matching client option
...to Set this Tag to Setting tag
There was a problem hiding this comment.
I chose verb here as more concrete than gerund. Setting tag becomes very confusing. Is it a noun? No - it isn't. It is not an instantiation either. It needs to describe the action.
| so.optional = false; | ||
| so.placeholder = '61,8c:80:90:01:02:03'; | ||
|
|
||
| so = ss.option(form.Value, 'networkid', _('...to Set this Tag')); |
There was a problem hiding this comment.
...to: this is to say: in order to. There is a clear consequence. Cause and effect.
| ss.modaltitle = _('Edit UC'); | ||
| ss.rowcolors = true; | ||
|
|
||
| so = ss.option(form.Value, 'userclass', _('Match User Class...')); |
There was a problem hiding this comment.
I'm not sure whether we can form a sentence from the table headings in all languages.
Match User Class... to Matching user class
...to Set this Tag to Setting tag
There was a problem hiding this comment.
See previous comment about gerund vs verb.
| so.rmempty = false; | ||
| so.optional = false; | ||
|
|
||
| so = ss.option(form.Value, 'networkid', _('...to set this Tag')); |
There was a problem hiding this comment.
See previous :)
| ss.modaltitle = _('Edit VC'); | ||
| ss.rowcolors = true; | ||
|
|
||
| so = ss.option(form.Value, 'vendorclass', _('Match Vendor Class...')); |
There was a problem hiding this comment.
I'm not sure whether we can form a sentence from the table headings in all languages.
Match Vendor Class... to Matching vendor class
...to Set this Tag to Setting tag
There was a problem hiding this comment.
Translators do a fine job.
| so.rmempty = false; | ||
| so.optional = false; | ||
|
|
||
| so = ss.option(form.Value, 'networkid', _('...to set this Tag')); |
|
Thanks for the ideas @feckert. Tags are difficult... |
systemcrash
force-pushed
the
dhcp_redesign_phase2
branch
from
02fe101 to
c8acf94
Compare
| so.optional = true; | ||
| so.placeholder = '3,192.168.10.1,10.10.10.1'; | ||
|
|
||
| so = ss.option(form.Value, 'tag', _('...To this matching Tag')); |
There was a problem hiding this comment.
There is not 'tag' option, 'tag' is actually the section name: https://github.com/openwrt/openwrt/blob/a9ff3ba24b9466d9c06b9a9e1c2e9672bdd9f6f9/package/network/services/dnsmasq/files/dnsmasq.init#L461
|
What is the status of this PR? |
|
This looks good and I do agree that it's a very useful thing to be able to control via UI vs. manual config file updates. |
|
Any updates? |
systemcrash
force-pushed
the
dhcp_redesign_phase2
branch
from
c8acf94 to
512387b
Compare
This comment has been minimized.
This comment has been minimized.
systemcrash
force-pushed
the
dhcp_redesign_phase2
branch
from
512387b to
5b660b1
Compare
This comment has been minimized.
This comment has been minimized.
Signed-off-by: Paul Donald <[email protected]>
Signed-off-by: Paul Donald <[email protected]>
tag names shall not match: - network devices/interfaces - service names Signed-off-by: Paul Donald <[email protected]>
Signed-off-by: Paul Donald <[email protected]>
Signed-off-by: Paul Donald <[email protected]>
This regards the confusingly named 'match' entries. Signed-off-by: Paul Donald <[email protected]>
Signed-off-by: Paul Donald <[email protected]>
systemcrash
force-pushed
the
dhcp_redesign_phase2
branch
from
5b660b1 to
0bf2ea9
Compare
Failed checksIssues marked with an ❌ are failing checks. Commit 0bf2ea9
Commit 3bc9c11
Commit a82ac40
Commit f8e7f74
Commit ed2daac
Commit 8a78fbb
Commit 37d66d3
For more details, see the full job log. Something broken? Consider providing feedback. |
For use with dnsmasq tags Note that a MAC tab is possible but the same functionality is present in the leases tab which handles MACs and tags. A MAC tab has a 1:1 tag:MAC relationship, whereas the leases has a many:many relationship. The dnsmasq init file needs updating to use 'tag' in place of 'networkid', which is an older legacy format still understood by dnsmasq, but all documentation uses 'tag'. tag names shall not match: - network devices/interfaces - service names Three dnsmasq reserved tag names are: - known - !known - known-othernet Tag names can be prepended with '!' to invert their usage. Closes #7178 Signed-off-by: Paul Donald <[email protected]> (cherry picked from commit 3c8ff55)
6 participants
This is a continuation of the work done in #6705. It implements GUI for dnsmasq based tags. Tags can trigger DHCP options (to be sent in DHCP responses), and vice-versa: DHCP client options and properties e.g. MAC/Vendor/User Class can trigger creation of tags. Recommended for users who know what they are doing, since invalid
option:valuecombos can crash dnsmasq.To describe tags succinctly is a challenge, such that a newcomer understands them more deeply, since they operate in two domains: ingress and egress. I spent a while coming up with the current descriptions. Suggestions welcome, but modifier beware. Syntax and descriptions are terse since you are expected to know what options and values you need.
Note: tags are still called 'networkid' in the dnsmasq.init script, which is really old terminology and should be updated. Current dnsmasq manpage and docu details 'tags' as the current terminology with little more than a footnote mentioning networkid any more.
Signed-off-by: <[email protected]>row (viagit commit --signoff)<package name>: titlefirst line subject for packagesdhcp-phase2.mp4