Account Configuration
As an organization admin, you can configure a variety of different settings in your minware account. This document describes the options that are available.
These pages are all accessible by navigating to the "Settings" link at the bottom of the left-side menu once you are logged in, and then viewing these options underneath the heading for your organization. If you do not not see your organization name in the settings menu, then you may not have administrative privileges, and should contact your minware organization's administrator for access, or contact support@minware.com for assistance.
Org Profile
Here you can set your organization's display name, as well as the unique org handle, which is the
URL path at which you will access your org in minware, e.g. minware.com/org/<Org Handle>.
Users
On the users page, you can invite people from your organization to minware. When inviting users, you can specify their role, which is described in further detail in the Roles section.
Note: This is only for people who will have access to minware itself. You do not need to invite people to be able to see their data in minware.
You can also configure SSO/SAML for your organization if you are an enterprise customer. For more information about setting up SAML, please see the SAML Configuration documentation.
Ticket Identity Linking
On the users page, you can also link minware users to identities in your ticketing system, such as Jira. To do this, simply click on "Link Identity" or "Change Identity" and select the identity in your ticketing system that corresponds to the user in question.
Once linked, ticket identities can influence which data a minware user is able to see in minware reports based on their role.
Note on Version Control Identity Linking
minware automatically links identities in version control systems with identities in ticketing systems using a variety of heuristics like name token matching and alias resolution based on the current ticket assignee of tickets linked to commits and branches. Additional configuration is normally unnecessary here, but you can contact support@minware.com if you encounter issues with how identities from GitHub, GitLab, Bitbucket, or Azure DevOps are linked to your ticketing system (e.g., Jira).
Roles
The roles page allows you to define data visibility for users in different roles.
Only users with the Admin role will have access to change organization settings in minware. These users will also be able to see all imported data.
The other three roles -- Executive, Manager, and Individual -- allow you to define the access level for people who are assigned these roles. (The roles start out with the exact same access and will only be different if you configure them differently.)
For each role, you can configure two types of access:
- User-Level View Rights - Permission to view report data at an individual level. All users will have permission to view their own data at an individual level (if they have a linked ticket identity). This setting can further grant access to the user's Own Team Members, or to All Users.
- Team-Level View Rights - Permission to view report data aggregated at a team level for other teams. All users will have permission to view aggregate data for their own team (if they have a linked ticket identity that is assigned to a team) and for the whole organization. This setting can further grant access to All Teams instead of just the user's Own Team.
These access levels will depend on the linked identity set on the Users page, and team access will further depend on team membership configured on the Teams page.
Teams
You can manually override team assignments on this page. By default, minware will automatically group people into teams based on who works together on projects or boards inside of your ticketing system (e.g., Jira). This is usually pretty accurate, but you may want to override team membership for specific people.
When you first connect data, minware will create teams automatically from projects and boards if you are using Jira.
Additionally, you can define teams in your version control system (e.g., GitHub teams), by connecting a directory source (e.g., Atlassian teams), or set them directly in minware. If you would like to use any of those other options, please contact us at support@minware.com and we will configure those teams in your account.
To override a team affiliation for a user, simply find their name in the list on this page, click Edit, choose Manual, and then select the team they are on from the list. Note that when you do this, it will be permanent until you change the setting again. minware will no longer automatically update their team if they start working on a different board or project.
Security (Login)
This page lets you configure the allowed sign-in methods for your organization. By default, you will have access to the following authentication methods:
- Password - Each user will set their own password for logging in. This is an option you most commonly want to disable if you allow other sign-in methods.
- Google - Members are allowed to log in with a Google account using single sign-on. Users must be invited to the org before they are allowed to join, and their email address will be verified during the Google OAuth process.
- GitHub - Members are allowed to log in with a GitHub account using single sign-on. Users must be invited to the org before they are allowed to join, and their email address will be verified during the GitHub OAuth process. Their GitHub account's email address must match the invited email address.
- (Other Enterprise SAML/SSO methods) - If enterprise SAML/SSO is supported in your organization, other login methods may be listed here.
For more information about SAML/SSO for enterprise customers, please see the SAML Configuration documentation
Integrations
Please see the Integrations documentation for more information about supported integrations.
On the integrations page, you can see a current list of your active integrations, and add new integrations for your minware organization.
Repositories
On the repositories page, you can select specific repositories that you would like to include in your data ingest.
At the top, you can also manually re-sync the repository list so that the latest data is shown on this page. Normally the repository list updates every night.
There are three options for repository ingestion:
- All Repositories - minware will ingest all current and future repositories from your version control system.
- All Repositories Excluding Forks - minware will ingest all current and future repositories from your version control system, but not include repositories that are forked and may have activity from outside of your organization (recommended if you have forked repositories).
- Select Specific Repositories - Choose which repositories are loaded into minware. This option is generally not recommended because it is easy to filter out repositories or contributors in minware reports. Furthermore, all repositories are ingested in parallel, so the number of repositories selected typically does not impact overall ingest time unless your organization has a particularly large repository that you don't want to include.
Ticket Projects
On the ticket projects page, you can select specific projects from your ticketing system that you would like to import into minware.
At the top, you can also manually re-sync the project list so that the latest data is shown on this page. Normally the project list updates every night.
There are two options for ticket project ingestion:
- All Projects - minware will ingest all current and future projects from your ticketing system.
- Select Specific Projects - minware will only load projects for particular teams. This option is generally not recommended and may negatively impact certain metrics in unexpected ways, like not counting code as having a ticket link if it was linked to a ticket in an unselected project. Instead, we recommend filtering out projects in minware reports.
Ingest Status
minware loads new data from each of your integrations on a nightly basis. This page shows you the last time your ingest succeeded and the typical runtime for a full update ingest.
You can also trigger a re-run of the overnight ingest process on this page, but that may take several hours depending on the size of your organization. If you just want to see more up-to-date results from changes to tickets, then we recommend clicking on the Sync Now button on an individual report page like Sprint Insights.
