Skip to content
This repository was archived by the owner on Nov 24, 2025. It is now read-only.

Feature/tp refetch#6325

Merged
ocket8888 merged 6 commits intoapache:masterfrom
tcfdev:feature/tp-refetch
Nov 5, 2021
Merged

Feature/tp refetch#6325
ocket8888 merged 6 commits intoapache:masterfrom
tcfdev:feature/tp-refetch

Conversation

@tcfdev
Copy link
Copy Markdown
Collaborator

@tcfdev tcfdev commented Nov 3, 2021

This is a continuation of the work in (PR 6118) as defined in the (Refetch Blueprint). These changes allow Traffic Portal to take advantage of the changes to the Traffic Ops API and Invalidation Jobs.

The table listing invalidation jobs has been modified to show the TTL explicitly (rather than Parameters) and the create form has been modified to account for the new Invalidation Type field. Traffic Portal integration test was updated to account for these changes as well.

There was also a minor change cleaning up the roles that were defined in some tests that may have been conflicting (read-only user should be read-only).


Which Traffic Control components are affected by this PR?

  • Traffic Portal

What is the best way to verify this PR?

Manually, to launch and run Traffic Ops and Traffic Portal. Navigate to the Invalidation Content page under the Tools menu in Traffic Portal. Note the Parameters column is now titled TTL (Hours) as well as the addition of the Invalidation Type.

Manually, create an Invalidation Request. Note the new required field for Invalidation Type, which defaults to REFRESH.

Repeat the same observation and test as above, however navigate to Delivery Services. Select a Delivery Service. In the upper right drop down menu More -> Manage Invalidation Requests. The difference here is that the table and create form are specific to this particular DS.

Automatic integration tests must pass.

PR submission checklist

@shamrickus shamrickus self-assigned this Nov 3, 2021
@ocket8888 ocket8888 added improvement The functionality exists but it could be improved in some way. Traffic Portal v1 related to Traffic Portal version 1 labels Nov 3, 2021
@zrhoffman zrhoffman added this to the 6.1.0 milestone Nov 3, 2021
Comment thread traffic_portal/app/src/common/modules/form/job/form.job.tpl.html Outdated
@zrhoffman
Copy link
Copy Markdown
Member

In order for CI to pass, #6325 needs to be rebased onto the apache:master branch now that the CI fix in #6329 is merged:

git remote add apache git@github.com:apache/trafficcontrol.git
git fetch apache
git rebase apache
git push your-fork your-branch --force

@tcfdev tcfdev force-pushed the feature/tp-refetch branch from af0e12c to 8ebcafb Compare November 4, 2021 21:19
Copy link
Copy Markdown
Member

@shamrickus shamrickus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

<small class="input-error" ng-show="hasPropertyError(jobForm.ttl, 'maxlength')">Too Long</small>
<small class="input-error" ng-show="hasPropertyError(jobForm.ttl, 'pattern')">Whole Number</small>
<span ng-show="hasError(jobForm.ttl)" class="form-control-feedback"><i class="fa fa-times"></i></span>
<input name="ttlhours" type="number" class="form-control" placeholder="Number of hours until the invalidation request expires" ng-model="job.ttlhours" min="1" max="999" required autofocus>
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, "Number of hours until the invalidation request expires" is not a an appropriate placeholder value for an input[type="number"].

From the MDN section on input labeling:

The placeholder should never be required to understand your forms. It is not a label, and should not be used as a substitute, because it isn't. The placeholder is used to provide a hint as to what an inputted value should look like, not an explanation or prompt.

So it's supposed to be an example input, and this looks more like a label. Traditionally we'd put that in the "helptext" tooltips for the input labels, though for all I care it could just be the entire label text content. The title attribute might also be appropriate, though whether or not any user would encounter that is very implementation-dependent (and since we use form[novalidate]s no non-screen-reading user would ever see them unless they decide to hover it in a Chromium or Gecko engine browser).

@ocket8888 ocket8888 merged commit ad4b800 into apache:master Nov 5, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

improvement The functionality exists but it could be improved in some way. Traffic Portal v1 related to Traffic Portal version 1

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants