-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
firewall: Show any included services on a service #12385
Conversation
Cool stuff :) |
@marusak yea I wasn't sure about the design at all. More consistency there would be good I agree. |
This is really cool. I've always thought it's a little odd to have 1 tab for details. I wonder if it makes sense to remove the tabs altogether and show all the information below. Is there a service that pulls in more services than FreeIPA currently? |
@garrett I think freeipa-4 includes quite a lot. Most are about 4-5. |
Needs to rebase to master since #12367 changed tests names |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice! Just one fixme in the tests, the rest looks good.
} | ||
// We can't use Promise.all() here until cockpit is able to dispatch es2015 promises | ||
// https://github.com/cockpit-project/cockpit/issues/10956 | ||
// eslint-disable-next-line cockpit/no-cockpit-all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should actually be obsolete now. But let's keep it here, and we can drop all cockpit.all() in a separate PR.
addService('freeipa-4') | ||
b.click("tr[data-row-id='freeipa-4']") | ||
b.click("tbody.open a:contains(kerberos)") | ||
b.wait_present("tbody.open .listing-ct-body:contains(Included service)") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please do an "else:" here, so that we have a reminder (failing test) once firewalld 0.7 trickles into distros. For example, debian-testing already has 0.7, so please add it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think our debian-testing is still buster?
But i will add the else!
@garrett Would the updated photo's design work better? |
What if the we ditched the tabs entirely and had the services listed under the details text? Something like this:
It's just a heading (probably an h4 or h5 — whatever is 1 more than the previous heading), which would be styled to be no larger than the row's text (so we'll probably need to do I don't think it would be too tall to do it this way. As there's nothing but informative text, I'd like it if we could keep it all together in the details. If we eventually add more features, we could then we could reconsider tabs. But I'm not sure what features that would be. For example: Editing is about which zone the service is in really... or if it's a custom rule, then the ports selected too. (In other words: editing would be in a dialog, not inline in an expanded row.) So if not editing, then what? This is why I don't think we need tabs here, either in the present or the future. TL;DR: Bulleted list with a heading. Names of services would be in a |
Looks great now! :) Both debian stable and testing failed in |
</ul> | ||
</div> | ||
{tabs} | ||
{ tabs && heading } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this tabs
just tests if tabs is defined and if is, then it shows heading? Wouldn't it make sense to just show heading when defined? ({ heading }
)
Or wouldn something like simpleBody || (heading && tabs)
work? (reading like "set simpleBody or heading followed by tabs")
I am afraid that tests are broken on debian. I've seen 4 results and all 4 failed the same way on testFirewallPage. Unfortunately needs work |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! This is much more elegant.
Too many flakes, retrying a bit. Please self-land when all firewall tests pass. |
Fixes rhbz#1721548 Closes cockpit-project#12385
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
}) | ||
.then(path => firewalld_dbus.call(path[0], | ||
'org.fedoraproject.FirewallD1.config.service', | ||
'getSettings2', [])) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Follow-up: Start with this call, and if it fails, fall back to the old one and set includes to empty. Saves one call on new firewalld, and on older versions there's no change (one succeeding and one failing call).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, that would make a lot more sense. I'll do it as a followup, this one has been in the pipeline too long :p
Fixes rhbz#1721548 Closes #12385
@Gundersanne : can you please send a PR against the rhel-8.1 branch with this backported? |
@martinpitt sure, will be my first backport :D |
@Gundersanne: Sorry, can you please do the screenshot slightly wider (to avoid the label wrap) and have some more context? Right now it's hard to see from where this actually happens. |
@martinpitt