TP - delivery service form layout redesign#3658
Conversation
|
Refer to this link for build results (access rights to CI server needed): |
4a15c2a to
35e102c
Compare
|
Refer to this link for build results (access rights to CI server needed): |
35e102c to
d1f58eb
Compare
|
Refer to this link for build results (access rights to CI server needed): |
d1f58eb to
d5e1695
Compare
|
Refer to this link for build results (access rights to CI server needed): |
d5e1695 to
2d867ba
Compare
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
6a3ab73 to
93ad7f6
Compare
|
Refer to this link for build results (access rights to CI server needed): |
|
retest this pleaase |
93ad7f6 to
6d35890
Compare
|
Refer to this link for build results (access rights to CI server needed): |
6d35890 to
9050d01
Compare
|
Refer to this link for build results (access rights to CI server needed): |
ocket8888
left a comment
There was a problem hiding this comment.
Still need to check out the UI test updates.
By the way, as long as we're re-doing the DS forms, it'd be neat to use input[type="checkbox"] instead of select option[ng-value="true"], select option[ng-value="false"] for inputs that represent boolean concepts. Though that may be out of scope for this PR.
There was a problem hiding this comment.
Maybe this isn't the time to change this, but you can do this whole loop thing in one line:
const URLstring = ds.exampleURLs.join('<br/>');which has the added benefit of not including a trailing <br>. Unless you want that, in which case you can append it with + on that same line. But that shouldn't be necessary, because paragraphs should force a line break between them anyway.
There was a problem hiding this comment.
Instead of two ngShow listeners on two separate <i> tags, you could accomplish this by toggling the state of exactly one chevron like so:
<i class="fa" ng-class="showGeneralConfig ? 'fa-caret-down' : 'fa-caret-up'></i>
You may also want to consider the HTML5 <details> tag - although that isn't supported by Edge and I'm never really clear on which browsers TP is purported to support.
There was a problem hiding this comment.
this ng-show could be combined with the ng-if - since that's what the other buttons do
There was a problem hiding this comment.
This ng-show could be an ng-if
There was a problem hiding this comment.
This should probably no longer be autofocused now that it's not the first control encountered by the user.
There was a problem hiding this comment.
This URL no longer works - if you want to fix it it would be https://traffic-control-cdn.readthedocs.io/en/latest/overview/delivery_services.html#ds-types. Or you could just remove it entirely.
There was a problem hiding this comment.
i'll fix it. i think it's probably helpful
There was a problem hiding this comment.
hrefs that use AngularJS string interpolation should instead use the ngHref directive.
There was a problem hiding this comment.
i'm guessing there are a lot of places where this could be fixed...is this issue part of your TP best practices issue?
There was a problem hiding this comment.
Not currently - you think it's common enough to be added?
There was a problem hiding this comment.
i'm guessing it probably is
There was a problem hiding this comment.
The readthedocs page will redirect this to HTTPS automatically - but it'd be nice to let users skip that step by taking them to the HTTPS page from the start.
There was a problem hiding this comment.
confused. is this not correct?
See <a href="https://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_router.html#tr-ngb" target="_blank">GeoLimit Failure Redirect</a> feature...
There was a problem hiding this comment.
The issue is with http://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_router.html#pattern-based-consistenthash - but because you updated your PR (several times) while I was reviewing, GitHub became very confused about where certain comments are anchored.
There was a problem hiding this comment.
i'll look for all instances of http on the ds forms
There was a problem hiding this comment.
A lot of these routing configuration changes don't get used by ANY_MAP Delivery Services - should they still be presented to the user? e.g. Geolocation Provider is used by TR to route client requests, but since TR doesn't route ANY_MAPs, the field has no effect on them.
There was a problem hiding this comment.
good point. these fields have always been present on the any_map form and like you said, probably ignored.
There was a problem hiding this comment.
can you create a separate issue for this as these fields have been present on the any map form for so long and i'd like to address their removal separate from this PR. good catch!
There was a problem hiding this comment.
oh wow. look at that. :)
There was a problem hiding this comment.
This link no longer exists. If you want to fix it, the new location is: https://traffic-control-cdn.readthedocs.io/en/latest/overview/delivery_services.html#ds-multi-site-origin. Or you could just get rid of it.
9050d01 to
076da45
Compare
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
ocket8888
left a comment
There was a problem hiding this comment.
UI tests pass, page looks good.
3baabd3 to
d257642
Compare
|
Refer to this link for build results (access rights to CI server needed): |
|
I see @ocket8888 reviewed the hell out of this.. merging.. |
What does this PR (Pull Request) do?
The delivery service forms for HTTP*, DNS*, Steering and any map delivery services have been reorganized into 3 groups - general config, cache config and routing config. Unlike before, none of the fields are hidden, however, each group can be collapsed if desired. This should help communicate the purpose of each delivery service attribute.
Which Traffic Control components are affected by this PR?
What is the best way to verify this PR?
Run the UI tests - https://github.com/apache/trafficcontrol/tree/master/traffic_portal/test/end_to_end
Note (tests): there are no new UI tests as functionality did not change. However, running the existing UI tests will ensure that the changes made to the ds forms do not prevent create, update or delete of a ds.
Note (docs): There are currently no docs that show what the ds forms looks like, therefore, none to update.
Note (changelog.md): I do not believe a changelog.md entry is required as functionality did not change in any way.
The following criteria are ALL met by this PR