• Icon: Suggestion Suggestion
    • Resolution: Unresolved
    • None
    • Repositories
    • None
    • 7
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Imagine the scenario where you have 20+ repositories. If a user has committed in the past with a different email, you'd have to create mappings 20+ times, once per repo.

      Can we specify a global user mapping, and only have it overwritten if there's a specific repo mapping?

          Form Name

            [FE-3606] Support global user mappings

            Atlassian Update – 13 September 2021

            Hi everyone,

            We have recently reviewed this issue and the overall interest in the problem. Taking into account that Fisheye and Crucible are currently in the maintenance mode it's very low on our priority list. That's why we've decided to resolve it as Not being considered.

            Although we're aware the issue is still important to those of you who were involved in the conversations around it, we want to be clear in managing your expectations. The Fisheye&Crucible team is focusing on issues that have broad impact and high value, reflected by the number of comments, votes, support cases, and customers interested. Please consult the Implementation of New Features Policy for more details.

            We understand how disappointing this decision may be, but we hope you'll appreciate our transparent approach and communication. Atlassian will continue to watch this issue for further updates, so please feel free to share your thoughts in the comments.

            Regards

            Marek Parfianowicz
            Development Team Lead
            Fisheye/Crucible Team

            Marek Parfianowicz added a comment - Atlassian Update – 13 September 2021 Hi everyone, We have recently reviewed this issue and the overall interest in the problem. Taking into account that Fisheye and Crucible are currently in the maintenance mode it's very low on our priority list. That's why we've decided to resolve it as Not being considered . Although we're aware the issue is still important to those of you who were involved in the conversations around it, we want to be clear in managing your expectations. The Fisheye&Crucible team is focusing on issues that have broad impact and high value, reflected by the number of comments, votes, support cases, and customers interested. Please consult the Implementation of New Features Policy for more details. We understand how disappointing this decision may be, but we hope you'll appreciate our transparent approach and communication. Atlassian will continue to watch this issue for further updates, so please feel free to share your thoughts in the comments. Regards Marek Parfianowicz Development Team Lead Fisheye/Crucible Team

            Atlassian Update – 19 May 2020

            Hi everyone,

            thank you very much for reporting this suggestion and your involvement in the conversations around it. This suggestion is in the 'Reviewing' state which means it awaits assessment by our team.

            As Fisheye and Crucible have entered basic maintenance mode, our team currently focuses more on bug-fixes and platform updates rather than on feature development. We may still deliver some small improvements if they fit into the maintenance theme. However, suggestions which have been assessed already and are in the Under consideration state have higher priority.

            It means it may take time until we review this suggestion and decide whether to put it on the roadmap or reject it. You can expect an update from us in couple of months. Atlassian will continue to watch this issue for further updates, so please feel free to share your thoughts in the comments.

            Kind regards
            Marek Parfianowicz
            Development Team Lead
            Fisheye/Crucible Team

            Marek Parfianowicz added a comment - Atlassian Update – 19 May 2020 Hi everyone, thank you very much for reporting this suggestion and your involvement in the conversations around it. This suggestion is in the 'Reviewing' state which means it awaits assessment by our team. As Fisheye and Crucible have entered basic maintenance mode , our team currently focuses more on bug-fixes and platform updates rather than on feature development. We may still deliver some small improvements if they fit into the maintenance theme. However, suggestions which have been assessed already and are in the Under consideration state have higher priority. It means it may take time until we review this suggestion and decide whether to put it on the roadmap or reject it. You can expect an update from us in couple of months. Atlassian will continue to watch this issue for further updates, so please feel free to share your thoughts in the comments. Kind regards Marek Parfianowicz Development Team Lead Fisheye/Crucible Team

            If anyone wants i created a nodejs script to sync users username's to their displayname.

            This can be run hourly or how ever you see fit. It requires read and write access to the mysql database, and read access to the config.xml file in the fisheye home folder.

            https://github.com/ludjer/fisheye-user-mapping

            Ludger Peters added a comment - If anyone wants i created a nodejs script to sync users username's to their displayname. This can be run hourly or how ever you see fit. It requires read and write access to the mysql database, and read access to the config.xml file in the fisheye home folder. https://github.com/ludjer/fisheye-user-mapping

            jjozwik added a comment - - edited

            Have a ugly work around but still saved thousands of hours for mapping bad user emails to each repo..
            Jam it in the DB.

            Work around for MySQL

            INSERT IGNORE INTO cru_committer_user_mapping (cru_committer_name, cru_repository_name, cru_user_name)
            SELECT
              users.commitauthor,
              repos.cru_content_root_rep,
              users.cru_user_name
            FROM (SELECT DISTINCT
                     cru_content_root_rep
                   FROM cru_content_root) repos,
                 (SELECT DISTINCT
                     (cru_committer_name) AS commitauthor,
                     cru_user_name
                   FROM `cru_committer_user_mapping`) users
            

            jjozwik added a comment - - edited Have a ugly work around but still saved thousands of hours for mapping bad user emails to each repo.. Jam it in the DB. Work around for MySQL INSERT IGNORE INTO cru_committer_user_mapping (cru_committer_name, cru_repository_name, cru_user_name) SELECT users.commitauthor, repos.cru_content_root_rep, users.cru_user_name FROM (SELECT DISTINCT cru_content_root_rep FROM cru_content_root) repos, (SELECT DISTINCT (cru_committer_name) AS commitauthor, cru_user_name FROM `cru_committer_user_mapping`) users

            100+ repos and counting, setting up a tool on user / repo basis is not an option.

            Christoph Hagenbrock added a comment - 100+ repos and counting, setting up a tool on user / repo basis is not an option.

            +1

            I just had the same problem, it would help a lot with support for global mappings. I have about 200 mappings to add manually now, so not an impossible situation but annoying still.

            Daniel Bengtsson added a comment - +1 I just had the same problem, it would help a lot with support for global mappings. I have about 200 mappings to add manually now, so not an impossible situation but annoying still.

            Sorin Sbarnea (Citrix) added a comment - - edited

            We are just investigating FishEye as a possible code review tool at Citrix and we have more than 400 repos only few hours after putting the test instance up, probably will see thousands quickly and I do not see how it would be possible to deal with user mappings if people are not able to add global mappings, a clear deal-breaker.

            What would be so hard about clashings? If someone adds a repository specific mapping, this will overload the general one, nothing more.

            What worries me even more is that this feature is not even planned to be implemented in a version, which means that we should not expect to get it fixed in the next couple of years.

            Sorin Sbarnea (Citrix) added a comment - - edited We are just investigating FishEye as a possible code review tool at Citrix and we have more than 400 repos only few hours after putting the test instance up, probably will see thousands quickly and I do not see how it would be possible to deal with user mappings if people are not able to add global mappings, a clear deal-breaker. What would be so hard about clashings? If someone adds a repository specific mapping, this will overload the general one, nothing more. What worries me even more is that this feature is not even planned to be implemented in a version, which means that we should not expect to get it fixed in the next couple of years.

            It automatically maps the users who used exactly same name in commits and crucible account, but there's no option to create users automatically. I.e. you have to manually or with script to create all users or integrate to ldap. Also if an user has used multiple names in the commits across multiple repositories, there is no way to create a global mapping from all repositories, but you have to manually map the name per repository.

            Additional features that would help are:

            • Option to create automatically a user account for mapping
            • Mapping of committer name from any repository to specific username in crucible (instead of per repository)

            Matti Oikarinen added a comment - It automatically maps the users who used exactly same name in commits and crucible account, but there's no option to create users automatically. I.e. you have to manually or with script to create all users or integrate to ldap. Also if an user has used multiple names in the commits across multiple repositories, there is no way to create a global mapping from all repositories, but you have to manually map the name per repository. Additional features that would help are: Option to create automatically a user account for mapping Mapping of committer name from any repository to specific username in crucible (instead of per repository)

            Simon Stücher added a comment - Isn't this feature available in Crucible? See https://confluence.atlassian.com/display/CRUCIBLE/Configuring+User+Managed+Mappings

            1 MUST! I have to write a script for this because I have 180 repos and 100+ users..

            Matti Oikarinen added a comment - 1 MUST! I have to write a script for this because I have 180 repos and 100+ users..

            Yes please.

            Chad Beaudin added a comment - Yes please.

            Dominik Bartholdi added a comment - - edited

            +1 a must!

            Dominik Bartholdi added a comment - - edited +1 a must!

            +1

            Rune Engseth added a comment - +1

            Yes, please support it!

            Arkadiy Shapkin added a comment - Yes, please support it!

            Same situation here but with 180 git repositories, some with 20 years of history.
            The global mapping seems like a sensible solution to me
            But if it is not feasible, my question is:
            Is there a way to batch/automate this? with a script ordirectly adding them to the FE database?

            Deleted Account (Inactive) added a comment - Same situation here but with 180 git repositories, some with 20 years of history. The global mapping seems like a sensible solution to me But if it is not feasible, my question is: Is there a way to batch/automate this? with a script ordirectly adding them to the FE database?

            That seems to be a trivial non-issue. In the case of shared logins for things such as cvs/svn there is no effective way to map which user did what, in the case of bad configuration for Git/Mercurial this is again an issue of end user support. In our use case we have approximately 18 repositories with history that spans across CVS, SVN, and Git for the majority of repositories (These repos started in CVS and migrated over time.) This is an absolute must as each user has 5+ committers that they need to link, across 18 repos, x12 active users (not counting those who have left the company sense.) That's a lot of mapping that could very easily be handled by creating a global map that is then overwritten by a local map (to the repository.)

            Shawn Stratton added a comment - That seems to be a trivial non-issue. In the case of shared logins for things such as cvs/svn there is no effective way to map which user did what, in the case of bad configuration for Git/Mercurial this is again an issue of end user support. In our use case we have approximately 18 repositories with history that spans across CVS, SVN, and Git for the majority of repositories (These repos started in CVS and migrated over time.) This is an absolute must as each user has 5+ committers that they need to link, across 18 repos, x12 active users (not counting those who have left the company sense.) That's a lot of mapping that could very easily be handled by creating a global map that is then overwritten by a local map (to the repository.)

            AntonA added a comment -

            The slight compication here is that global mappings could lead to clashes.

            So if the same committer name was used in different repositories by different users, this would lead to a clash.

            AntonA added a comment - The slight compication here is that global mappings could lead to clashes. So if the same committer name was used in different repositories by different users, this would lead to a clash.

              Unassigned Unassigned
              a38518e05741 David Yu
              Votes:
              37 Vote for this issue
              Watchers:
              28 Start watching this issue

                Created:
                Updated: