Collaborator Server operation with Java 17
The IT department has performed a Java update on the server, as it is necessary for the operation of other software on the server. Unfortunately, the operation of the CollabServer 14.4.14400 is now no longer possible. It would be nice to have a CollabServer installation that supports Java 17. Furthermore it would be desirable to know how many users are active and how many users are logged in but without activity for x minutes.
AWS Code Commit Support
Howdy, Please add Code Collaborator support for AWS Code Commit repository integrations to the web client. Example of this current functionality can be found here: https://support.smartbear.com/collaborator/docs/source-control/git.html https://support.smartbear.com/collaborator/docs/source-control/repo-hosting/index.html In the same way that Github, Bitbucket, and Azure can easily be integrated to the Collaborator, I would like for this process to also function with AWS Code Commit Repos. I may currently use Code Collab and AWS Code Commit via the client gui and local changes, but I would also like to have direct repo integration like the hosted repos do. Thanks.
Archiving to a different Network location
I am using Collaborator Enterprise 13.6 and trying to archive my nearly 1 TB of data in my Content Cache folder on my server. We have tried to archive off to a separate network location (to free up space on my server) and it will not copy the files. We have to do this the brute force method and archive to a location on the same server (small increments) then copy that archive to the other network location. We will have to do this with each incremental archive. Then they are not together, but they are still individual archives. I would like to request that the ability to archive to another network location be added so that when an archive is done, the data is all together in one Content Cache folder, and I don't have to look through a bunch of separate archives to find the review I want to restore.
Add Reopen Permission
We would like only specific non-admin users to be able to reopen reviews. This could be a user-specific permission or allow all group admins to reopen. The current template level open either allows all participants or system admins to reopen. We cannot allow all participants to reopen but it is a burden on admins to perform these.
OIDC providers
OIDC is much simpler to set up than SAML and having support for other OIDC providers besides GitHub and Atlassian would be beneficial. Enterprises that have their own internal OIDC provider and don't (or cannot) use GitHub or Atlassian Crowd would benefit from a simpler A&A configuration.
have the re-open review setting be based upon limited admin settings
currently the ability to re-open reviews is based upon the review templates. It would be better to have this setting be at (or included in) the limited admin level. It is not typically a setting we desire everyone to have, but having a limited team (quality) be able to re-open is highly desirable.
