This is not and should be in the package.json:

  "engines": {
    "node": ">=16.0.0",
    "npm": ">=8.0.0"
  },

Create a Management UI for functionality described in TAMULib/ProjectManagementService/issues/62 .

1. As Manager, Go to Remote Project Managers Tab.
2. Clock Add a Remote Project Manager button.
3. Partially fill out form, only selecting Name and Type (do not fill out URL, Username, etc..).
4. Click Create button.

What happens is an error occurs (behind the modal) and (also behind the modal) an incomplete/invalid RPM gets created. Modal remains open.
Then you can fix the model, create and there are two copies, an invalid one and the valid one.

The invalid one breaks numerous aspects of the system.
In particular, if at this point the Service is ever shut down then it can never come back up without explicit database changes. The invalid RPM causes an error java.lang.reflect.InvocationTargetException and the Service refuses to start.

Additional problems or different aspects of the same problems seem to be that when type is VERSION_ONE and url is not specified, then a 500 error occurs but only after the data is saved. This results in invalid data being saved.
This can also create a situation coincidentally solved in TAMULib/ProjectManagementService#97 whereas the server will not start on invalid data. However, there may be more conditions that need to be handled that those described in the mentioned PR.

Furthermore, the <validationmessage results="remoteProjectManagerForms.getResults()"></validationmessage> on the modal does not catch this 500. The only way to catch this 500 would be to add something like <alerts seconds="45" channels="remote-project-manager" types="ERROR" exclusive></alerts> to the modal in addition to the validationmessage. There may need to be a more complex validation created that handles these complex conditions, if such a thing is possible.
At the very least it probably should not save anything when a 500 would otherwise occur.

There are some dependabot reported security issues that may or may not be reported by npm audit.

Dependebot doesn't always report the security issues but when cross-references other projects, such as SAGE, one can find the issues. Cross-reference the issues.

Review these and see if it is possible to safely update these.
These may require using overrides.
If that is the case be sure to perform extra checks for regressions.

Such cases would be, for example, minimatch where some dependencies need a 5.x version of minimatch but the overrides is set to ^3.0.0.

Cursory invetigation on patterns like "minimatch": ">=3.1.2", or "minimatch": "^3.1.2 || >=3.1.2", result in always using a 5.x version and patterns like "minimatch": "^3.1.2", result in always using a 3.x version.

When there are dependencies requiring different versions there does not seem to be a way to allow a 3.1.2 to match for 3.x version and a 5.1.1 to match for a 5.x version.

When the Product is saved, it waits to update the associated active sprints before closing. This should be done asynchronously to make the modal more responsive.

• Upgrade Weaver-UI-Core (use "@wvr/core": "2.2.2-rc.8" until release is available)
• Upgrade all dependencies with vulnerabilities
• Passes CI (all tests if no CI configured)
• Provides a Dockerfile based on this (rough) spec
• Replace grunt with webpack - at least requires to add or modify .wvr/build-config.js, package.json, and index.html (blocked by TAMULib/Weaver-UI-Core#182)

If a certain dependency upgrade or deprecated code replacement ends up being large in size, create an issue.

Document procedure followed to do the upgrades on the app - insofar as it varies from the previously documented apps

These tasks should be confirmed/performed on each Weaver Client. This note should be a template for comments of each PR into staging.

• 1. Standardize the multiple forms of gitignore
• 2. Standardize README
• 3. Standardize LICENSE, update date and package.json
• 4. Standardize PR and Issue templates
• 5. Update karma.config.js for consistency
• 6. Update karma.config.js preprocessors to include index.html app/**/*.html
• 7. Update karma.config.js using single quotes
• 8. Remove version and any references from appConfig.js.template
• 9. Update Dockerfile for consistency
• 10. Update Dockerfile to combine RUN commands for better layer caching
• 11. Update Dockerfile to use --non-unique to both useradd and groupadd commands
• 12. Update default.conf.template with latest NGINX location regex location ~ ^${BASE_PATH}(.*)
• 13. Refactor NPM_REGISTRY_URL to NPM_REGISTRY as not an actual URL
• 14. Update GitHub workflow step versions

gitignore

https://github.com/github/gitignore

1. Default JavaScript gitignore plus common docker and weaver ui files to ignore
2. Standalone apps (CAP, SAGE, Vireo) with Java, JavaScript gitignore plus common docker and weaver ui files to ignore
3. Standardize sections for .gitignore (community by project type, docker, application specific)

README

Create multiple md files next to primary README.

1. README.md

• badges
• name
• overview
• app repo
• deployment
• license

2. DEPLOYMENT.md

• running for development
• docker for development
• docker for deployment

PR templates

Template defined for clients

Issue templates

Issues regarding intended purpose of client repositories.

1. bug template
2. feature template

16 09 2022 17:25:59.048:INFO [coveralls.io]: uploading...
16 09 2022 17:25:59.048:INFO [coveralls.io]: 422 --- {"message":"Couldn't find a repository matching this job.","error":true}

All of these will include badges:

• Build
• Test Coverage
• Ensure PR checks are active

Where it is possible we should reuse workflows between repos.

The UI part of TAMULib/ProjectManagementService#115 .

Table is currently showing empty cells, should show associated remote product managers and their remote products.

Add a tooltip for the name while you're at it.

This can be reproduced by attaching some Internal Request to the Product to prevent the delete from working.

The resulting error message appears twice.
The first at the top of the page, below the banner.
The second underneath the tabs, above the "Add a Product".

1. upgrade dependencies
2. update auth service
3. update/verify build and ci

Update Weaver UI Core:

"@wvr/core": "2.0.7"

Should be deployed to pre this sprint.

relates to TAMULib/ProjectManagementService#134

• create a product filling in locations
• create another product
• location fields will be populated from the first product creation

This can be reproduced by having some Product utilize the Remote Project Manager to prevent the delete from working.

Suggested Resolutions:

1. Be consistent and close the modal, even on error, like is done with the Product.
2. Show the error inside the modal.

URLs should be able to be tagged with deployment locations such as Dev, Pre, Prod, Other.

Should all locations be repeatable, or only one Dev location?

https://github.com/TAMULib/ProjectManagementUI/blob/master/app/views/modals/addProjectModal.html#L10

validation results should come from either a model or the repo