Skip to content
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

Add Deprecation section of the Manage Package page #6912

Merged
merged 41 commits into from
Feb 26, 2019
Merged

Conversation

scottbommarito
Copy link
Contributor

@scottbommarito scottbommarito commented Feb 21, 2019

#6773
#6848
#6849

Future PRs:

  • CVE/CWE autocomplete
  • tooltips (the (i) icons in the spec)

Tons of screenshots below:

image

image

image

image

image

image

image

image

image

image

image

image

// Bootstrap doesn't set the container width when the screen is xs.
// We want the container width to be the width of the viewport on xs screens.
// Otherwise, elements that depend on the width of the container could behave oddly on xs screens.
.container {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

For more context--I had to add this to fix a UI bug with the multi-select dropdown on XS screens. The dropdown's button text is the list of every selected version, and when this list is greater than can display in the button, it relied on the container's width to properly overflow. At SM widths and above, the container width is set by Bootstrap, but at XS and smaller, it is set to "auto", so its width becomes equal to the longest item inside it, which caused it to take the width of the un-overflowed dropdown button. By setting the XS container width to the viewport's width, the dropdown button would then properly restrict itself to the size of the viewport.


model.VersionSelectList = new SelectList(
Copy link
Contributor Author

@scottbommarito scottbommarito Feb 21, 2019

Choose a reason for hiding this comment

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

For more context, I made this change because I discovered that our use of SelectList was fairly unclean.

SelectList provides nothing other than a way to construct a IEnumerable<SelectListItem> using reflection. We have no reason to use it because we can easily just rewrite our code to create the IEnumerable<SelectListItem> directly. I think this approach is much cleaner because it avoids the reflection and dynamic objects we currently use.

I discovered this while updating the SelectList in ManagePackageViewModel and updated it here as well because it was the only other place we used it.

})
</label>
</div>
<label for="input-select-readme" id="readme-version-label">Select version</label>
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This change was a minor UI fix I noticed while working on the page. The select list in the documentation section is bolded because it is inside the label. None of our other select lists are bold, so I made this change to align it with the others.

var cves = _deprecationService.GetCvesById(cveIds);
if (cveIds.Count() != cves.Count)
{
return DeprecateErrorResponse(HttpStatusCode.NotFound, Strings.DeprecatePackage_MissingCve);
Copy link
Member

Choose a reason for hiding this comment

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

Per offline discussion, we need to cover for the scenario where vulnerability data is not up-to-date.

A CVE/CWE info may not be available in the autocomplete API due to the following reasons:

  1. Data staleness on NuGet Gallery – We refresh every 24 hours to begin with.
  2. Data staleness on the CVE/CWE repository – This could happen too as sometimes the ID is provided upon report but the corresponding data record is absent till the vulnerability is being explored/validated.

In these cases, we should visually warn but accept the input from the package publisher

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was originally going to postpone doing this until a future PR, but I think it probably wouldn't be too much work.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

After looking into it more, I will postpone this to the future CVE/CWE autocomplete integration PR to reduce the size of this one.

var cwes = _deprecationService.GetCwesById(cweIds);
if (cweIds.Count() != cwes.Count)
{
return DeprecateErrorResponse(HttpStatusCode.NotFound, Strings.DeprecatePackage_MissingCwe);
Copy link
Member

Choose a reason for hiding this comment

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

Same here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will do in the PR that integrates your CVE/CWE autocomplete work with this form.

.Where(p => p.PackageStatusKey == PackageStatus.Available)
.ToList()
.OrderByDescending(p => NuGetVersion.Parse(p.Version))
.Select(p => NuGetVersionFormatter.ToFullString(p.Version));
Copy link
Member

Choose a reason for hiding this comment

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

This is parsing twice, right? You should be able to both sort and get a full version string from NuGetVersion.

Also, why full version? Does this look reasonable with, say, the build metadata that client team puts on their packages?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Rewrote it to only parse once.

We use full version in all of our other version select lists, so I chose it here to be consistent. I don't mind making it normalized, but I feel like more information is better. I don't think it would look reasonable with how the client uses build metadata, but I would prefer to see how other users use build metadata as well before changing this.

Copy link
Contributor

@shishirx34 shishirx34 left a comment

Choose a reason for hiding this comment

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

This is one gigantic PR. It is very difficult to thoroughly review so much changes.

Why not create separate PRs with smaller changes? Just from overview I would break this PR into

  1. Deprecation Service
  2. Feature flag
  3. CSS/view changes.

src/NuGetGallery/App_Start/AppActivator.cs Show resolved Hide resolved
Text = PackageHelper.GetSelectListText(versionWithSymbols),
Value = Url.DeleteSymbolsPackage(new TrivialPackageVersionModel(versionWithSymbols)),
Selected = package == versionWithSymbols
});
Copy link
Contributor

Choose a reason for hiding this comment

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

Please ensure the delete symbols work flow runs fine after this change.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yup!

}
});

this.escapeKeyCode = 27;
Copy link
Contributor

Choose a reason for hiding this comment

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

Javascript has constants, if I am not mistaken. Why do we need a property?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Does it? I can't find the constant online...

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh I see, I thought you meant that there was a constant for the escape keycode built into the language. I'll look into consts.

self.addId('');
};
this.addKeyDown = function (data, event) {
if (event.which === 13) { /* Enter */
Copy link
Contributor

Choose a reason for hiding this comment

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

13 [](start = 28, length = 2)

Consider adding a keycode like the escape key on the dropdown page

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants