udaykiran19491/user-stories-from-tawos-for-llm-fine-tuning huggingface dataset:
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "*Acceptance*    Augment the self-repair/consistency task so that it will re-create component metadata entries for this format.   * Every operation should be logged to the new long-running task log.   ** Creating a new component db record   ** Conflicts (e.g. there's an unreferenced blob, but there's already an asset record that exist at the implied coordinate, but it refers to a different blob)   * Conflicts never overwrite existing Orient metadata; they're only logged.   * All operations should have a 'do no work' mode as per ---NEXUS-12390---   * -Restore should work if only components are dropped- (while true we have a ticket for this elsewhere)   * Restore should work if only assets are dropped   * Restore should work if both component and asset are dropped"
Answer: 837943.0

User story: "*Background*    There are a number of long-running tasks whose specifics we need to audit (self-repair tasks being a good example, but also purging releases, snapshots, etc.), but we don't want to a) fill the nexus log with a million line items, or b) lose information at the whim of a customer's log levels. Support frequently gets requests from users asking to understand what happened to specific artifacts.    *Acceptance*   * Create a service that can accept all these detailed actions, in large volumes   * One log file per run of a given scheduled task   * Output files should be dated, clearly indicate which task was run   * Emit the log file location into the log at the start and end of the scheduled task   * Include task logs in the support tools zip "
Answer: 39373.0

User story: "Create privileges via the provisioning API."
Answer: 1079839.0

User story: "Create new content selectors via the scripting API."
Answer: 1079835.0

User story: "Currently if a user makes a REST API request for components or assets in a repository they cannot access, they get an empty set. They should probably receive an error code. This occurs with the following resources:   * GET {{/service/siesta/rest/v1/assets}}   * GET {{/service/siesta/rest/v1/components}}    Technical note: What error code do we want to return? 403 vs 404."
Answer: 22929.0

User story: "The role definition screen appears to display the contained roles in an arbitrary order (maybe db insertion order). This makes them <USER>to grok, and is a usability regression from NX2.    Acceptance  * Order the roles in the role list alphabetically "
Answer: 19563.0

User story: "(This should probably get broken into a couple of issues.)    *Acceptance*    During read-only mode, NXRM won't accept writes. In this situation, it would be ideal if:   * Rejected requests return 503 specifically (rather than other 500-level responses).   * The reason code should specify that the cluster is in read-only mode   * This covers REST endpoints, and repository write access"
Answer: 235988.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "When integrating Nexus into an environment where Authentication is handled externally (e.g. for SSO), it is nice to have the option to redirect to a new URL (e.g. your SSO logout page) after a user logs out of Nexus.  Currently when a user logs out it just remains on the page as the logout in an Ajax call.    Additionally when using the RUT plugin where the username is passed over in the header, after a user clicks the logout button, they get logged out, but then they get logged back in since the header appears in the token and there is no way to redirect from that page.    See this Nexus users post for reference - https://groups.google.com/a/glists.sonatype.com/forum/?utm_medium=email&utm_source=footer#!topic/nexus-users/3qM1uwKKY1o"
Answer: 1490192.0

User story: When configuring an NPM proxy repository "HTTP Authentication" allows for "Authentication type" of "Username" (I guess that means HTTP Basic Auth) and "Windows NTLM".   It would be useful to also support the NPM specific "npm login" AKA "npm Bearer Token" authentication method.    *Acceptance*   * NXRM administrators can configure npm proxy repos to use _npm bearer token_ the authentication method with the upstream repository
Answer: 1359692.0

User story: "Similar to Nexus 2.x support article:    https://support.sonatype.com/hc/en-us/articles/213465208-What-do-the-scheduled-tasks-in-Nexus-do-and-how-often-should-I-run-them-    We should offer the same guidance focusing on how, when, why for Nexus 3 tasks.    https://groups.google.com/a/glists.sonatype.com/d/msgid/nexus-users/CAC16qPi7HKOESeFsBuBep_p40vWBRJ3KXFqABD2H2f3Hs6-_bA%40mail.gmail.com?utm_medium=email&utm_source=footer"
Answer: 604574.0

User story: "*Background*   The repair/rebuild task first introduced in NEXUS-11213 has the potential to make quite a few changes to data and/or blobs, especially in a post-restore situation.    *Acceptance*   * Add a mode to the rebuild/repair task that causes it to log the changes it would make, but not actually make any changes to blobs and/or metadata.   * Line items should still be made in a long-running task log for the run.   * Each task log entry should clearly indicate it was possible but not actually performed. (Some clear prefix?)"
Answer: 312375.0

User story: "*Background*   An unwise sequence of backup and restore actions can produce a database that refers to missing blobs. (Example, drop a repository, restore the component database to an earlier state, start the system.)    *Acceptance*   * Blob store compaction does not delete blobs that are still referenced by component metadata.   * Mass deletions/compactions (e.g. dropping a repo) should still be performant.   * Make an entry in the long-running task log to record:   ** Every blob deletion that happens in compact   ** Every blob we choose NOT to delete due to a reference from component metadata"
Answer: 212999.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "*Background*   In the case of a damaged/ill-timed blobstore backup/restore, it's possible there are some missing blobs.    *Acceptance*   * If a blob in a proxy repo is missing, rather than immediately returning a 500 error, Repo attempts to refetch it.   * If the content is available in the remote, it is downloaded.    *Notes*   We should ensure we're only trying this for 'missing blob' situations that correspond to proxied artifacts. If it's a missing blob for cached metadata, there will be nothing to refetch."
Answer: 103710.0

User story: "*Background*  Once we've built NEXUS-12360, we need a way to backfill data from the (hidden) blob creation dates and [asset owner fields|https://issues.sonatype.org/browse/PE-165] in the blob store.    *Acceptance*  * There is a way for an admin user to populate Asset.blobCreated from the blob created dates in the blob store.  * {{blobUpdated}} should be set to the same date (since we don't know if it's been updated since then).  * Since one-off, user-visible, version-specific upgrade tasks aren't good, consider rolling this behavior into a general metadata/blob store reconciliation task (e.g. the same task from NEXUS-11213).  * Update documentation to describe the new scheduled task/behavior of the scheduled task."
Answer: 392793.0

User story: "*Background*  The 'last updated' field of Asset is confusing users, who think it shows when the content arrived. It doesn't, it indicates when the record itself was last updated (just like the same field on Component).    The information they care about isn't actually available - NXRM has it, but it's buried in blob store metadata.    *Acceptance*  * Remove the 'lastUpdated' field from the Asset metadata summary. This is an internal field that tracks when the metadata record has changed, and users don't care about it.  * Add two new Date fields to asset:  ** {{blobCreated}} - touched when a blob is first attached to the asset  ** {{blobUpdated}} - touched on creation, and when a new blob (i.e. different hash) is attached to the asset  ** Rename {{lastAccessed}} to {{lastDownloaded}} for clarity (e.g. it refers to when the content was downloaded, not when someone last had a look at the asset metadata through search/browse)  * Add the two new fields to the Asset summary.  * Update the book documentation to explain the fields.  ** Currently the [field descriptions|https://books.sonatype.com/nexus-book/reference3/using.html#_search_results] don't add value.    *Notes*  * Looking ahead to fabric, these fields still are 1:1 with the Asset - multiple blob_refs don't require us to have multiple created/updated fields, because the expectation is that the blobs will all be identical (barring corruption). These dates represent when they arrived in NXRM, rather than in a particular blob store. (The blob stores will continue to record that.)    *Technical Notes*  * blobCreated and blobUpdated will need to be nullable for situations like NuGet assets that don't have blobs.  "
Answer: 22984.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Java 9 is released. This public improvement is about adding server runtime support for it."
Answer: 634909.0

User story: *Background*  1. A user creates a hosted repository, and a content selector permission based on a groupId, e.g. {{format == "maven2" and coordinate.groupId =^ "my.test"}}  2. The user attempt to upload a .jar, via  {code}  mvn org.apache.maven.plugins:maven-deploy-plugin:deploy-file \    -Dfile=testing.jar -DrepositoryId=testing -Durl=$TESTURL \    -DgroupId=my.test -Dversion=1.0 -Dartifact=testing -Dtype=jar  {code}  3. Deployment fails:  {code}  Access denied to:  http://nexus-lab.home.bardicgrove.org/repository/maven-releases/my/test/testing/maven-metadata.xml,  {code}    The reason for this is that maven-metadata.xml files don't have any coordinates associated with them for the purposes of content selector evaluation. The workaround is that users can create a more complicated content selector that ORs the groupId with a path, but that's unnecessarily fiddly.    *Acceptance*  * maven-metadata.xml files have partial component coordinates assigned to them (just {{groupId}} and {{artifactId}}, I guess?) so that the scenario, above, works correctly and the client can update metadata.
Answer: 1030224.0

User story: On a component or asset page in a Maven repository, the "Delete" button is enable even if I have only "nx-repository-view-maven2-myrepo-browse" privilege.    Clicking the button and confirming the deletion leads to a org.apache.shiro.authz.AuthorizationException, but ideally the button should be disabled to make permissions checks easier.    *Acceptance*  * Make the error message user friendly.  ** (The permissions might have changed since the control rendered.)  * Drive the button's state depending on the permissions.  ** Since 'delete (single) component' is atomic, we should enable the button only if the transaction will go through.  ** Ensure there's a tool tip to explain why it's disabled.
Answer: 900017.0

User story: "*Background*  Customers want to use Amazon EFS with Nexus 3. Our performance testing has associated significant slowdowns with EFS, and ElasticSearch documentation recommends against it. (See below.)    *Acceptance*  * Update documentation and/or KB articles to make it clear EFS is potentially troublesome.  * Consider putting this on the Sonatype system requirements.        "
Answer: 833748.0

User story: "Nexus 2 Legacy URL activation support ( content/ ) was added in Nexus 3 as per NEXUS-9976    Support for /service/local/nuget/<repoid> style urls was omitted however. This means that NuGet repository clients must change their repository URLs to the new Nexus 3 style before Nexus 3 can work. ( repository/<repoid> )    h4. Expected    NuGet was the only repository format that required special URLs in Nexus 2. Add support for these special URLs in Nexus 3 to make upgrade more seamless.    *Note*  We should address site repos when we do this as well, since they're mapped under {{content/sites}} in NXRM2.  "
Answer: 434918.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "*Background*   Currently, there's a gap in terms of how NX3 backups can be orchestrated. We want admins to export the database (i.e. via the scheduled task), and keep the export files safe, and synchronize this with a blob store/rest of Nexus backup. This is tricky because the scheduled task is controlled inside Nexus, while blob stores are often backed up using an externally controlled rsync.    *Acceptance*   * There is a mechanism to list configured scheduled tasks, query their run status and invoke them (as if they were being manually invoked).    *Technical Notes*   * Perhaps the right way to do this is as part of beefing up the Provisioning API to cover scheduled tasks (including finding and triggering them).   * We'll defer configuration-specific endpoints (and this can currently be done with the provisioning API).   * Consider that some tasks may not come from our own plugins."
Answer: 348378.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "*Background*  A number of customer bug reports have been traced to the fact that the NX2->NX3 migration REST API is using encoded slashes in requests. This causes problems with reverse proxies, and so far our recommendation is to fine tune the reverse proxy settings. This will continue to be problematic in the future, so let's adjust to eliminate the encoding.    The problem manifests itself when the HTTP download option is used during upgrade to Nexus 3, and Nexus 3 is sending requests for artifacts to Nexus 2. Nexus 3 sends requests to Nexus 2 with encoded slashes like   {{<base url>/service/siesta/migrationagent/repository-content/npmproxy/which%2F-%2Fwhich-1.0.9.tgz}}, those decoded slashes need to arrive at the Nexus 2 instance unaltered/undecoded in order for migration to work.    *Symptoms*    Requests by the Nexus migration agent to Nexus 2 will fail with 404 not found. Example stack trace from your nexus.log:    {noformat}  2016-11-08 08:39:26,510+0100 ERROR [plan-executor-5-thread-6] admin com.sonatype.nexus.migration.repository.ProcessChangesStep - Failed processing of CREATE /package/-/package-2.0.1.tgz, will ignore and move on. HTTP 404 Not Found  javax.ws.rs.NotFoundException: HTTP 404 Not Found          at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.handleErrorStatus(ClientInvocation.java:201) [na:na]          at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.extractResult(ClientInvocation.java:174) [na:na]          at org.jboss.resteasy.client.jaxrs.internal.proxy.extractors.BodyEntityExtractor.extractEntity(BodyEntityExtractor.java:59) [na:na]          at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invoke(ClientInvoker.java:104) [na:na]          at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientProxy.invoke(ClientProxy.java:64) [na:na]          at com.sonatype.nexus.migration.client.$Proxy193.get(Unknown Source) [na:na]  {noformat}    This can happen with any repository type.    *Acceptance*  * Remove slash encoding from the NX2 migration REST API so that we don't have problems with reverse proxies.  * Revert note added by https://github.com/sonatype/nexus-book-internal/pull/55 which will become obsolete    *Workaround*    - configure Nexus 3 to send requests to Nexus 2 directly instead of going through an intermediary reverse proxy  - configure the httpd in front of Nexus 2 with the directive {{AllowEncodedSlashes NoDecode}} and the option {{nocanon}} for your ProxyPass directive - do a similar change for nginx if using that server  - upgrade to 2.14.3/3.2.1 once released  "
Answer: 39210.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: *Background*   This feature serves as a handy bridge between searching for things and downloading them. Having a download sub-resource means that clients can make simple HTTP calls for artifacts that may or may not exist, and download them without parsing any JSON.    *Acceptance*   * This sub-resource builds on NEXUS-14603 (asset search json api), but returns:   ** A 302 redirect to download the asset bytes   *** Rationale: This has the benefit of leaving a trail in build tools' logs that explains what specific artifact was suggested as the thing to download (e.g. in the case of a "latest" search), rather than simply returning bytes.   *** It's fine to reuse existing format-specific content-serving endpoints, if that's expedient (as with the asset download sub-resource)   ** If there are no search results, HTTP 404   ** If the search isn't sufficiently precise to pick a winning asset (i.e. there's no sort order and there's more than one search result), then we should return HTTP 400 (client error)   ** Request logs should make it easy to tell whether users were searching for content vs. trying to download content (e.g. because downloading is a sub-endpoint or uses a 'download' param or whatever)    *Questions/Notes*   * Partial fetch/HEAD support is of course desirable, but that will be handled by the format-specific content bytes endpoint  
Answer: 483619.0

User story: "The current analytics event data definition (which I believe is shared with some analytics tools hosted by OPS) doesn't include the nodeId where the UI event occurred. This story will look at adding nodeId to analytics events. Whoever works on this task should check with OPS to find out whether adding this new field will cause any issues with their downstream analytics tools.    Open questions:   * should we also look at versioning the analytics data definition?   * does the local sequence counter provide much value in HA?   * existing records should leave the nodeId unspecified"
Answer: 404948.0

User story: "*Background*  If administrators are provisioning Nexus instances, they need a way to make sure the instances come up as Pro edition.    *Acceptance*  * Nexus admins can use Provisioning scripts to register Pro licenses.    *Questions*  * Is anything special (e.g. restart?) required to pick up the new bundles?  * Shall we script license _removal_ while we're in there?"
Answer: 1349357.0

User story: "On large installations, the periodic Orient database backups generated by NXRM could potentially get unwieldy, or fill the <USER>drive. Should NXRM have a retention/deletion policy?"
Answer: 1664265.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "This initial collection of work makes available a base set of staging suite features in the Nexus Repository Manager PRO product line. The staging functionality is exposed by way of a set of REST APIs and includes support for tagging components and moving components between repositories.     This set of APIs and capabilities provides a set of flexible building blocks that can be combined and orchestrated as needed to accomodate your organization's software build and release pipeline and can be easily integrated into CI/CD systems to support established workflows.    Additionally, new security permissions and a schedulable task have also been provided to support staging activities.    "
Answer: 746037.0

User story: This is optional, but we should investigate supporting it in the future:  <FunctionImport Name="GetUpdates" EntitySet="Packages" ReturnType="Collection(NuGetGallery.V2FeedPackage)" m:HttpMethod="GET"> <Parameter Name="packageIds" Type="Edm.String" Mode="In"/> <Parameter Name="versions" Type="Edm.String" Mode="In"/> <Parameter Name="includePrerelease" Type="Edm.Boolean" Mode="In"/> <Parameter Name="includeAllVersions" Type="Edm.Boolean" Mode="In"/> <Parameter Name="targetFrameworks" Type="Edm.String" Mode="In"/> </FunctionImport>  Description taken from latest metadata at [http://nuget.org/api/v2/$metadata|http://nuget.org/api/v2/%24metadata]
Answer: 1058567.0

User story: "There is currently no way to clean up old docker images from a hosted repository.    Docker images can be very large, and are often deployed in environments where access to older versions of an image is not necessary.    There should be a scheduled task to clean up old hosted docker images, and to also clean up layers which are no longer used by any hosted images.    *Acceptance Criteria*   * A user will be able to purge Docker images older than X days from a Docker hosted repository   ** Since Docker images share layers we can't remove all of the layers attached to the image, we have to remove them after we know they aren't used anymore   ** As a part of removing the old images, we should clean up all orphaned layers    NOTE:   * More info on how Docker is handling deletes: [https://github.com/docker/distribution/blob/master/ROADMAP.md#deletes]"
Answer: 986615.0

User story: "Implement an S3-backed blob store for AWS-based deployments of NXRM.          "
Answer: 816262.0

User story: "Provide a supported path for using Docker Content Trust in NXRM Docker repos/registries.    [https://blog.docker.com/2015/08/content-trust-docker-1-8/]"
Answer: 1693334.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "*Background*  https://hub.docker.com/r/sonatype/docker-nexus3/ is now the automated official build?    https://hub.docker.com/r/sonatype/nexus3/ is some manually created thing.    The descriptions for each of these projects do not make it clear which should be avoided and which should be relied upon. This causes customer confusion and support headaches.    Please clearly change the descriptions of each of these projects and/or remove the https://hub.docker.com/r/sonatype/nexus3/ one if that is going to remain a deprecated one.    Leaving the old {{nexus3}} one around without very clear instructions and some clear deprecation is NOT a good option.    *Acceptance*  * Gut the {{nexus3}} project and leave it with a README that points to {{docker-nexus3}}."
Answer: 105079.0

User story: *Background*    Consider a hypothetical npm package 'bezor' version 1.0.0 (with no namespace), which lives in an npm hosted repo in Nexus.  Various client npm projects use this package, and the dependency version is "~1.0.0" which signifies that the latest minor point release is acceptable.    The hosted repo is the first member of a group, which also contains a proxy for npmjs.org. One day, 'bezor' 1.0.5 shows up on npmjs.org, no relation to the hosted package.  Suddenly, builds start failing as the unrelated package is pulled down.    This is an inevitable consequence of a lack of namespacing with tilde-style dependency versioning, and it's also a blocker for a client adopting NX3 from a home-rolled npm repo.    *Acceptance*  * Administrators can set a system property that prevents npm groups from merging package metadata on a request-by-request basis.  * This only applies to the default namespace. Namespaced components continue to have their metadata merged, regardless of the system property's value.    If this property is set for the example, above, when a client requests metadata for package 'bezor' the client will only be shown metadata from the hosted repo. This contains 'bezor' 1.0.0 and nothing else.    *Notes*  This change won't affect the 'all' endpoint. Clients who request 'all' will still be able to see the multi-member merged metadata for a given package. We believe the exposure to this is minimal since the client doesn't use this to resolve dependencies.
Answer: 5768.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: https://docs.docker.com/registry/spec/manifest-v2-2/    There are some new optional fields in this version of the manifest. If nexus encounters these, it does not handle them well.    Example below shows what happens when Nexus sees the os.features property in the manifest:    {noformat}  2016-10-27 09:18:43,056+0300 ERROR [qtp1943158415-194] jenkinspublisher org.sonatype.nexus.repository.docker.internal.DockerHostedFacetImpl - Manifest refers to missing layer: sha256:5496abde368a3dd39999745bf998c877ddc6a390a943bc3fd99ffaabf728ed88 for: sonet/pushtest/latest in repository docker-internal  2016-10-27 09:18:43,057+0300 ERROR [qtp1943158415-194] jenkinspublisher org.sonatype.nexus.repository.docker.internal.DockerHostedFacetImpl - Manifest refers to missing layer: sha256:94b4ce7ac4c7c7d4ed75ac2bd9359a87204ad2d5a909759d8e77953874d8e7c2 for: sonet/pushtest/latest in repository docker-internal  2016-10-27 09:18:43,060+0300 WARN [qtp1943158415-194] jenkinspublisher org.sonatype.nexus.repository.docker.internal.V2Handlers - Error: PUT /v2/sonet/pushtest/manifests/latest: 400 - org.sonatype.nexus.repository.docker.internal.V2Exception: Invalid Manifest  2016-10-27 09:26:50,784+0300 WARN [qtp1943158415-244] admin org.sonatype.nexus.repository.docker.internal.V2Handlers - Error: GET /v2/helloworldimage/manifests/latest  com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "os.features" (class org.sonatype.nexus.repository.docker.internal.V2ManifestConfig), not marked as ignorable (11 known properties: "container_config", "container", "config", "architecture", "os", "created", "docker_version", "author", "rootfs", "metaClass", "history"])  at [Source: java.io.BufferedInputStream@12af6124; line: 1, column: 850] (through reference chain: org.sonatype.nexus.repository.docker.internal.V2ManifestConfig["os.features"])  at com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException.from(UnrecognizedPropertyException.java:62) [com.fasterxml.jackson.core.jackson-databind:2.7.1]  {noformat}    And here's another example that occurred using 1.13.0-rc 3 for Mac:    {quote}  Unrecognized field "comment" (class org.sonatype.nexus.repository.docker.internal.V2ManifestConfig), not marked as ignorable (11 known properties: "container_config", "container", "config", "architecture", "os", "created", "docker_version", "author", "rootfs", "metaClass", "history"])  {quote}    
Answer: 116706.0

User story: *Background*   When we created a single OSS/Pro binary, we inadvertently dropped all language associated with Nexus Repository OSS being a free product to use. This has caused user confusion and consternation.    *Acceptance*   * The about box should shows either the OSS or Pro license, depending on whether there is a license installed.   ** "PRO OSS" licensed instances should show the Pro license.   * The OSS license should make it clear that Nexus Repo OSS is licensed under the EPL.   * The 'license installation' dialog should show the Pro license.
Answer: 504048.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Because deleting a repository or blob store can be an expensive operation, we should mask the UI until it completes. [@<USER>https://sonatype.aha.io/users/6143649298277051488] noticed that things can blow up otherwise."
Answer: 30957.0

User story: The authenticated userid and IP address of the client which uploaded a component to the hosted repository is valuable auditing information.    *Use Case:*  - regression from Nexus 2 if omitted - Nexus 2 stored and exposed this information on the artifact details tab  - As a user, it is valuable for me to know who uploaded an asset.  - As a customer, I hope fields in NX2 remain in NX3 unless intentionally removed due to refactoring or lack of use.    *Acceptance Criteria:*  - record the authenticated username that added a component to a hosted repository using any method  - record the client IP address/host name ( do not attempt to DNS resolve it ) as interpreted from the upload request  - show "Uploaded By" details in the asset section of the UI in NX3    *Considerations:*  - make it configurable to display this info in the UI? Would some customers find exposing the userid / ip address sensitive information?    *Questions*  - What do we do about migration? If we pull this over, do we potentially run into weirdness with different user domains?
Answer: 554453.0

User story: "There are commonly customized configuration options that are currently stored in the installation folder and a user needs to remember to copy these over every time.    As an admin, I want to be able to store the commonly customized property files inside the data folder so that I don't have to remember to reapply them or copy them every time I upgrade.    This should include things like the jetty config, port, webapp context, logging, jvm options, ha (hazelcast, orient), ehcache.xml etc.    Acceptance Criteria    * Create a single property file with commonly-changed properties  ** this lives in the data folder, which is read and pushed into other configuration via templates/property placeholders, so that (e.g.) jetty configuration files can still change structure version-to-version  ** a similarly structured default properties file provides values for properties not set by the user (e.g. in cases where Nexus 3.(n+1) adds a new user-configurable property)  ** When NX3 first boots, if the property override file does not exist, NX creates it  *** (No overrides are set in this NX-created file, but comments explain the available configuration properties)   * Subdivide the /etc directory into sub-directories to separate routinely changed configuration from rarely/never-changed configuration files   * Documentation exists to explain this, including the different manual steps needed to upgrade from pre-3.0 to 3.1   * Circulate the proposed layout with the NX team and Support prior to implementation"
Answer: 50313.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Users would like to have anonymous read (pull) access to docker repositories in Nexus. This helps consume and share docker images more easily by not requiring a specific login. This is analogous to the benefits offered by anonymous access by other formats.    As an end user, I don't want to have to configure authentication for read only access to docker repositories.  Docker hub does not require this, and neither should Nexus Repository Manager.    According to this comment from a Docker developer the correct way to do this would be to implement token authentication, and to have Nexus hand out tokens for anonymous access:    https://github.com/docker/docker/issues/24129#issuecomment-230610547    There might also be a simpler implementation that should be considered for blanket anonymous access to a repository.  "
Answer: 533026.0

User story: "We’ve designed our UI to work at 1024x768. Thus, the ability to collapse the feature menu isn’t really needed, and can be disabled. This will also eliminate any confusion about how the collapse arrow relates to the breadcrumb.    !https://issues.sonatype.org/secure/attachment/72950/72950_Assets+-+Nexus+Repository+Manager+2016-08-31+16-58-57.png!"
Answer: 238960.0

User story: In the UI, if you expand the Search option all types that Nexus supports are listed even if there are no repositories for a type configured.  I think it would be good if only those types that are are repos set up for in the instances are listed. Listing types that are not supported by this specific Nexus instance could possibly make the user think that there should be support. Which could cause support tickets for the Nexus admin.  For example, a user seeing "Docker" listed could (as Docker is hype) think that it would proxy Docker hub and try to use it. When it doesn't work (as not proxy is set up) he/she could think something is wrong in this setup starting a internal support ticket to solve this.    Acceptance criteria:    * When no repositories have been configured for a given repository format, that format should not appear as a search option.
Answer: 184353.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Nexus 2 and Nexus 3 support basic reverse proxying scenarios by way of X-Forwarded-\* headers.    The supported configuration enabled out of the box is:    1. Host header - host name and port are read from here by default - Host header is required by HTTP spec.  2. AbstractConnector(Nexus2) jetty config set hostHeader value - this is used in place of inbound host header, no x-forwarded headers are consulted if set  3. X-Forwarded-Host header- This overrides Host header values for host name and port, if config is not set  4. X-Forwarded-Server header - This overrides **server name** value , if hostHeader config and x-forwarded-host is not set in a request  5. X-Forwarded-Proto header - if set, this overrides what url protocol is being used during the request. ( http or https )    In summary, all that could be changed by the above is host name, port and protocol.    Similarly related is the server Base URL value in Nexus: This URL is only used to produce base URLS to the Nexus instance, outside the context of an active incoming HTTP request ( think scheduled task emails ), where incoming HTTP headers cannot be consulted.    When reverse proxying Nexus, our current requirement is that the webapp and context path parts of the request must remain intact and unmodified and must be passed through as received by reverse proxy. The reason is that some metadata returned by some repository formats include absolute and relative links to other locations in the server. Since the server code cannot know if a reverse proxy is remapping the URL path parts, then its only option is to believe it is being accessed on the repository path that Nexus exposes directly.    Customers want to reverse proxy Nexus instances at URLs that may include differences in the other two parts of request - these are:    - webapp context path  - defacto content path    h3. Example Desired Use Cases:    ||URL Part||Reverse Proxy|| NX2 Repository Manager||  |URL|https://mvn.example.com/|http://nexus.local:8081/nexus/content/repositories/central|  |proto|https|http|  |host|mvn.example.com|nexus.local|  |port|80|8081|  |webapp context path|/|/nexus|  |repo content path|/|content/repositories/central|    ||URL Part||Reverse Proxy|| NX2 Repository Manager||  |URL|https://npm.team.example.com/|http://nexus.local:8081/nexus/content/groups/npm|  |proto|https|http|  |host|npm.team.example.com|nexus.local|  |port|443|8081|  |webapp context path|/|/nexus|  |repo content path|\[empty string\]|content/groups/npm|    ||URL Part||Reverse Proxy|| NX3 Repository Manager||  |URL|https://npm.team.example.com/nexus|http://nexus.local:8081/repository/npm-group|  |proto|https|http|  |host|npm.team.example.com|nexus.local|  |port|443|8081|  |webapp context path|/nexus|/|  |repo content path|\[empty string\]|repository/npm-group|    "
Answer: 1795889.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "We withhold important information about repositories from non-admins. Specifically, the repository status and URL fields.  * The repository status field is useful to see when a repository cannot be used by build tools.  * The URL field is necessary for folks to understand how to connect their build tools.   We should make both of these fields available in browse mode."
Answer: 23339.0

User story: When npm clients send requests to the remote server ( ie. the registry URL ) it needlessly encodes slashs as %2f. Sonatype has filed an npm issue about this because it seems improper that npm client url encodes forward slashes: [https://github.com/npm/npm/issues/16380]    Other clients ( not npm ) may also send URLs with encoded slashes.    Unfortunately this encoding of slashes conflicts with the default settings of Apache httpd which by default DOES NOT ALLOW THEM and WILL RETURN a 404 response.    From [https://httpd.apache.org/docs/2.2/mod/core.html#allowencodedslashes]  {quote}With the default value, Off, such URLs are refused with a 404 (Not found) error.  {quote}  However, if you are running Apache httpd 2.0.52 to 2.2.8 and you set:  {noformat:title=DO NOT DO THIS in Apache httpd 2.0.52 to 2.2.8}  AllowEncodedSlashes On  {noformat}  Then you will trigger a bug that incorrectly decodes encoded slashes when they should not be:    [https://bz.apache.org/bugzilla/show_bug.cgi?id=35256]    The workaround to allow encoded slashes through Apache httpd involves 2 settings:  {noformat:title=DO THIS: Prevent Apache httpd from decoding %2f URL Encoded slashes}  AllowEncodedSlashes NoDecode  {noformat}  *and*    The ProxyPass directive may also need nocanon option. From [https://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypass] :  {quote}Normally, mod_proxy will canonicalise ProxyPassed URLs. But this may be incompatible with some backends, particularly those that make use of PATH_INFO. The optional nocanon keyword suppresses this and passes the URL path "raw" to the backend. Note that this keyword may affect the security of your backend, as it removes the normal limited protection against URL-based attacks provided by the proxy.  {quote}  {noformat:title=DO THIS: Example use of nocanon option}  ProxyPass / http://localhost:8081/ nocanon  {noformat}      Basically Sonatype server products do not rely on Apache httpd to filter out suspect URLs containing path info with encoded values, so it is OK and sometimes required to let these through to the backend servers.     Additional Reference: [http://stackoverflow.com/a/9933890/235000]
Answer: 1046898.0

User story: "We should upgrade to the latest release line of orientdb. This will get us a fix for a known issue: [http://www.prjhub.com/#/issues/7245]  It should also put us back on track for support until we re-up our contract in the September timeframe; plan there is to upgrade to Production support and avoid any issues about backwards support."
Answer: 35895.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Users of Nexus 2 may be using or want to convert Nexus 2 plugins to Nexus 3 bundles.    The bundle development guide at https://help.sonatype.com/display/NXRM3M/Bundle+Development does not talk in the context of migrating/rewriting Nexus 2 plugins, it just presents some high level details.    There appears to be demand for a guide which walks through converting a Nexus 2 plugin to a Nexus 3 bundle.    "
Answer: 909018.0

User story: The Nexus installation is temporary, once you upgrade it becomes obsolete. The data directory is permanent, it needs to be preserved across all upgrades. The default data folder should be "../sonatype-work/nexus3/data"    We learned the <USER>way a very long time ago that it is a therefore good idea to have the default location of the data directory be outside of the installation directory (under "../sonatype-work/"). Doing this will prevent two common errors:    1. Users unpacking new installations directly on top of existing installations  2. Users mistakenly deleting or damaging work directories when they try to move them out of old installations.    An empty sonatype-work/nexus3 folder needs to be included in the bundle so the resulting folders have the correct permissions    We must call out in the release notes and upgrade notes that the data folder has been moved. At this time, we expect the move to be done one time manually by the end users, this is not being automated.    Users upgrading from pre-3.1 will need to either:    * manually move (recommended) or symlink the data folder to expose it to where pre-3.1 stored it   * configure Nexus 3.1 to point to the existing data folder inside the pre-3.1 layout (not recommended)    **Users:** Please consult the official upgrade documentation for upgrade instructions pertaining to this move
Answer: 109402.0

User story: "Acceptance    * Blob store name uniqueness checks should be case insensitive"
Answer: 150468.0

User story: "Nexus 3 has no default log that captures stdout/stderr. This means that the most reliable way to get a thread dump from a hung instance (kill -3) will not work.    This is a regression from Nexus 2, and has serious implications for support. Other methods of getting thread dumps such as jstack require that a JDK is available, and even when these tools are available they are not as reliable as sending a SIGQUIT.    *Acceptance*     Output written to stdout and stderror are written to the standard logs"
Answer: 212904.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "After doing the Paid/OSS Bundle work, we noticed that our experience was a bit funny :). We'd like to address that through the following improvements for a user's experience.   Acceptance Criteria:  * If a user license becomes invalid or expired in Nexus Repository Manager Pro  ** Send all users to a lightweight UI  ** Lightweight UI should only allow login/logout and the ability to install a license  ** All APIs should quit working (Maven, Docker, etc...)  * If a user installs a valid license Repository Manager Pro will start functioning again without a restart  * If a user's license is about to expire (30 days) we should provide a warning message in the UI to all Users (including anonymous) that shows the license is about to expire   NOTE:  * Ability to remove a user license in NX3 was removed. If they can figure out how, it will revert down to OSS. Changed original AC to match this updated (intentional) behavior."
Answer: 56028.0

User story: "As a developer, so that I can create and share internally created YUM packages, I need to be able to create a YUM hosted repository via Nexus.  "
Answer: 847680.0

User story: "*Acceptance*     * Nexus 3 maven2 proxy repo configuration should have an option for supporting circular redirects (as NX2 does)   * This setting should be migrated from NX2 during maven2 proxy repo migration.   * This feature should be documented in the book.     I configured my maven-oracle repo after migration to have the right credentials but I am not sure how to configure the rest of the setup so it continues to work as it did in 2.x.    See    [http://maven.oracle.com]   and [https://support.sonatype.com/hc/en-us/articles/213465728-How-to-configure-a-proxy-repository-to-maven-oracle-com]   for more info.    At the very least it should throw some sort of warning during the migration if this circula redirect is configured for a repo."
Answer: 392693.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "According to the requirements in ----NEXUS-9976---- a migrated 3.x installation should automatically support the old legacy URL patterns. For v2 content URLs to work, however, a system property must be defined org.sonatype.nexus.repository.httpbridge.internal.HttpBridgeModule.legacy=true, and this isn't happening automatically.    *Acceptance*   * 2x-3x upgrade should automatically enable the v2 content URLs   * implementing this as a capability that gets injected and activated in Nexus 3 on migration start would be great! - otherwise if a property is used, inject it into nexus.properties under the work directory. Support still needs to have a way to tell this is enabled ( currently we just look in nexus-default.properties or nexus.properties ) and the end user still needs to have an easy way to tell as well ( presence of property in nexus.properties or capability in UI )   * Minimize upgrade impact to users that have already migrated and made decisions about turning this feature on or off    *Notes*   * There's value in having this as a capability   * While you're in there, make a mental note if you spot any obvious signs that a given NXRM3 instance (or individual repos) were migrated from NXRM2"
Answer: 834552.0

User story: "I created a new raw hosted repository and then created a new role with read and edit repository view privileges to that new repository. Then I created a new user and gave it that new role.  I noticed that I was able to add a file to that raw repository despite not having add privilege. As far as I know, add is not contained in edit and this seems a bug.  I did not back check older NX3 or NX2 at this time. NX2 did use CRUD rather than BREAD which is testable however not sure the comparison is worth it unless to regression check."
Answer: 2015790.0

User story: "I saw this on stack overflow today:    http://stackoverflow.com/questions/35733455/whats-assets-in-the-new-nexus-3/35749272#35749272    When I looked, I couldn't find a good explanation of components vs. assets in the Nexus book. Assuming there isn't one already, we should add one."
Answer: 218.0

User story: "Every time I create a repository I have to select the blobstore, which is pretty annoying.  Granted, if there are multiple blobstores defined this isn't easily avoidable.  But I'm betting 90% of our users will only ever have one.      If there is only one blobstore available we should just select it in the new repository screen, rather than forcing the user to do it."
Answer: 102196.0

User story: "I recently created new advice for using SSL with Docker.    https://support.sonatype.com/hc/en-us/articles/217542177    Now we need to rewrite the book section    https://books.sonatype.com/nexus-book/3.0/reference/docker.html#_tips_for_ssl_certificate_usage"
Answer: 25756.0