TeamForge 17.4 has a lot of new features and enhancements. Here's a list of a few release-defining new features in TeamForge 17.4.
In the traditional client-server authentication model, client applications must have access to the Resource Owner's credentials in orderto request and access protected resources on the Resource Server. Sharing Resource Owner's credentials such as usernames and passwords to third party applications poses several problems, security being one of the major ones. Frameworks such as the OAuth 2.0 and OpedID Connect help in mitigating such security risks and hence TeamForge's authentication model has been completely rebuilt on top of OpenID Connect and OAuth 2.0 Authorization frameworks.
Federated Identity Management
Federated Identity Management refers to the process of storing user credentials with an IdP (such as TeamForge, SAML and so on) and having the Service Provider (SP) rely on the IdP to validate user credentials when a user tries to access its resources.
With the new TeamForge Identity Management built on OpenID Connect (OIDC) and OAuth 2.0 authorization frameworks, TeamForge can now act as an ID Provider (IdP). As an IdP, TeamForge can authorize a third-party client application to obtain limited access to its services either on behalf of a Resource Owner (user) or on behalf of the client application itself.
TeamForge supports federated identity. By default, federated login is disable in TeamForge. Site Administrators must enable federated login and select an IdP.
Both TeamForge REST and SOAP APIs use OAuth 2.0 access tokens for authentication. Clients can obtain access tokens from the token endpoint which is located at /oauth/auth/token.
For more information, see Identity Management: Set up TeamForge OAuth 2.0 Authorization Framework.
TeamForge-JIRA integration
This release brings a new feature for JIRA site administrators to disable active JIRA-TeamForge project mappings in bulk (
). The intended use case revolves around staging JIRA upgrades. When a JIRA server is mirrored into a staging/testing environment, any changes to issues in projects that are mapped to TeamForge will trigger events back to TeamForge, thereby polluting the production TeamForge event data store. Use this feature to disable all production JIRA-TeamForge mappings in stage environments and then test the TeamForge Associations add-on by creating a new mapping between a staging JIRA server and TeamForge server.For more information, see Remove TeamForge project mappings.
Nexus integration
CTF-Nexus-Integration-Plugin-2.1.1 is now available. To upgrade, see Upgrade the TeamForge-Nexus integration plugin.
TeamCity integration
TeamForge EventQ now supports TeamCity versions 9.0 and 10.0.
The Configure Application tool, added in TeamForge 17.4, makes TeamForge site level settings configurable via the user interface. This comes in handy for site administrators, who otherwise would have to work with the site-options.conf file and then recreate the TeamForge runtime for site level configuration changes. For more information, see Configure your site's settings.
The Configure Application tool is not loaded with all the available site configuration settings available in TeamForge. For settings that are not available in the Configure Application tool, Site Administrators must go the site-options.conf route as always.
The tagging functionality implemented for documents in TeamForge 17.1 has been extended to support tracker artifacts as well in TeamForge 17.4. Project members with CREATE/EDIT permissions can create new tags or add existing tags to tracker artifacts from the Create Artifact and Edit Artifact pages. You can add up to 10 tags to an artifact. You can add or remove tags to tracker artifacts when you search for artifacts within a single tracker or across trackers or during tracker mass update. You can also include "Tags" as one of the columns in the List Artifacts page.
For more information, see Create a tracker artifact and Edit a tracker artifact pages.
Repository Attachment Folder
You can now select a folder to upload code review and release notes file attachments. All the files attached to the repository are stored in the selected folder. For more information, see Create a source code repository.
Highlights of TeamForge-Git integration: 17.4.6-2.13.8
Highlights of TeamForge-Git integration: 17.4.11-2.13.9
Cause of the issue:
This issue is caused by the default configuration of RabbitMQ client which opens the dedicated thread pool (that spawns up to 2 * number of CPU threads by default) per connection. The issue manifests with large number of threads being spawned over time up to,Solution:
Highlights of TeamForge-Git integration: 17.4.14-2.13.9
For the vanilla based Gerrit release notes and the bug fixes, see Gerrit v2.13.9-11-gf25da13683 released on November 3, 2017.
Bug fixes
Critical upstream (stable-2.13) Gerrit fix is now available for SSH clone/fetch failure when server takes more than 30 seconds to compute its operation. To handle this, a new parameter sshd.waitTimeout has been included in the gerrit.config file. By default, the value of this parameter is 30 seconds.
EventQ Installation/Upgrade Changes
Starting from TeamForge17.4, you do not have to install EventQ separately on top of TeamForge. As long as you have your site's master configuration file (site-options.conf) specifying where your EventQ services (eventq, mongodb, redis and rabbitmq) are hosted, the TeamForge installer, by default, installs or upgrades EventQ services as part of TeamForge installation/provision.
In case you install or upgrade EventQ on a separate server, you must configure your TeamForge installation repository on the EventQ server and install EventQ using the teamforge-eventq meta RPM (yum install teamforge-eventq).
Obsolete site-options.conf tokens
Remove these tokens from the site-options.conf file while upgrading to TeamForge17.4 or later.
For more information, see TeamForge17.4 install/upgrade instructions.
A new XML to non-XML conversion based solution has been implemented to redefine the flex field data storage and retrieval mechanism. This new approach improves the performance of reporting queries used for retrieving flex field data from the Datamart. For more information, see Why do I get performance issues when retrieving flex field information from Datamart?
Default values for site-options.conf tokens
Default values have been assigned to the following site-options.conf tokens and are therefore removed from the default TeamForge 17.4 site-otpions-default.conf file.
# CTF Core SCM_ADMIN_PASSWORD=$auto$ IAF_DBPASS=$auto$ SCM_DEFAULT_SHARED_SECRET=$auto$ SOAP_ANONYMOUS_SHARED_SECRET=$auto$ # Database DATABASE_USERNAME=teamforge DATABASE_NAME=teamforge DATABASE_PASSWORD=$auto$ DATABASE_READ_ONLY_USER=teamforge_reader DATABASE_READ_ONLY_PASSWORD=$auto$ # Datamart REPORTS_DATABASE_USERNAME=teamforge_datamart REPORTS_DATABASE_NAME=teamforge_datamart REPORTS_DATABASE_PASSWORD=$auto$ REPORTS_DATABASE_READ_ONLY_USER=teamforge_datamart_reader REPORTS_DATABASE_READ_ONLY_PASSWORD=$auto$ # ETL ETL_SOAP_SHARED_SECRET=$auto$ # Gerrit GERRIT_DATABASE_PASSWORD=$auto$ # RabbitMQ RABBITMQ_APP_ADMIN_USER=guest RABBITMQ_APP_ADMIN_PASSWORD=$auto$ RABBITMQ_APP_CTF_USER=ctf RABBITMQ_APP_CTF_PASSWORD=$auto$ RABBITMQ_APP_SERVICES_USER=eventq RABBITMQ_APP_SERVICES_PASSWORD=$auto$ RABBITMQ_PERMISSION_PUBLISHER=permission_publisher RABBITMQ_PERMISSION_PUBLISHER_PASSWORD=$auto$ # Mongo MONGODB_APP_DATABASE_NAME=eventq MONGODB_ADMIN_DATABASE_NAME=admin MONGODB_APP_ADMIN_USER=admin MONGODB_APP_ADMIN_PASSWORD=$auto$ MONGODB_APP_BACKUP_USER=backup MONGODB_APP_BACKUP_PASSWORD=$auto$ MONGODB_APP_SERVICES_USER=eventq MONGODB_APP_SERVICES_PASSWORD=$auto$ # HAProxy HAPROXY_STATS_PASSWORD=$auto$ # Binary IAF_DBNAME=iafdb IAF_DBUSER=iafdbusr # James Admin (for management interface) JAMES_ADMIN_USER=admin JAMES_ADMIN_PASSWORD=$auto$
LISTEN_IP
By default, services bind to the IP address corresponding to the <host>:PUBLIC_FQDN token. However, you can override this using the <host>:<service>:LISTEN_IP site-options.conf token. You can use this <host>:<service>:LISTEN_IP token to control which IPs the services bind to so that you can make sure that services are not overexposed than necessary.
mypostgresserver:LISTEN_IP = 1.2.3.4 localhost:mail:LISTEN_IP = 1.2.3.4
snapshot.py
The snapshot.py script has been deprecated. The teamforge script subsumes the snapshot.py script's functions. For more information, see TeamForge script.