-
Notifications
You must be signed in to change notification settings - Fork 644
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
Conversation
// 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 { |
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.
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( |
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.
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> |
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 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); |
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.
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:
- Data staleness on NuGet Gallery – We refresh every 24 hours to begin with.
- 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
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 was originally going to postpone doing this until a future PR, but I think it probably wouldn't be too much 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.
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); |
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.
Same 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.
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)); |
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 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?
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.
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.
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 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
- Deprecation Service
- Feature flag
- CSS/view changes.
src/NuGetGallery/Controllers/ManageDeprecationJsonApiController.cs
Outdated
Show resolved
Hide resolved
src/NuGetGallery/Controllers/ManageDeprecationJsonApiController.cs
Outdated
Show resolved
Hide resolved
src/NuGetGallery/Controllers/ManageDeprecationJsonApiController.cs
Outdated
Show resolved
Hide resolved
Text = PackageHelper.GetSelectListText(versionWithSymbols), | ||
Value = Url.DeleteSymbolsPackage(new TrivialPackageVersionModel(versionWithSymbols)), | ||
Selected = package == versionWithSymbols | ||
}); |
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 ensure the delete symbols work flow runs fine after this change.
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.
Yup!
} | ||
}); | ||
|
||
this.escapeKeyCode = 27; |
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.
Javascript has constants, if I am not mistaken. Why do we need a property?
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.
Does it? I can't find the constant online...
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.
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.
Oh I see, I thought you meant that there was a constant for the escape keycode built into the language. I'll look into const
s.
src/NuGetGallery/Scripts/gallery/common-multi-select-dropdown.js
Outdated
Show resolved
Hide resolved
self.addId(''); | ||
}; | ||
this.addKeyDown = function (data, event) { | ||
if (event.which === 13) { /* Enter */ |
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.
13 [](start = 28, length = 2)
Consider adding a keycode like the escape key on the dropdown page
#6773
#6848
#6849
Future PRs:
Tons of screenshots below: