nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Can I search a repository by User instead of Author in Fisheye/Crucible?

charoco

In the search repository screen of Fisheye (and the Browse changeset screen in Crucible), the list of people is by author, not user.

Our repository is HG and most of our users have commited with slight username variants over time, leading to an unusable interface (especially for adding changesets)

The list looks like this:

Alex Jones alexjones <ajones@domain.com>

Alex Jones ajones

Alex Jones ajones@ajoneslaptop.domain.local

Alex Jones ajones <ajones@domain.com>

etc., etc.

Can we do anything about this?

Accepted answers

Foong

But if you want to search within the repository, each author is a separate entry:

Feature request: https://jira.atlassian.com/browse/FE-3999

You have to select all 4 entries for Alejandro B. if you want to see all of his activity, which is kludgy and annoying, but because the input element is a multi-select, technically doesn't impact functionality. What's funny here is that though there is an entry for each author, the user name is used as the display name for usability.

Feature request: https://jira.atlassian.com/browse/CRUC-6035

Workaround:

Rewrite the committers of the repository into another clone repository:

Get a copy of the repository and run the following command to list the current committer names:
```
hg log --template "{author}\n" | sort | uniq
```
Identify those you want to rewrite and add an entry into a authormap file to rewrite them to another address.
Run:
```
hg convert my-clone rewritten-clone
```
Strip the repository that FishEye is indexing and push the rewritten-clone into it. Make sure all your developers use clones of the new copy of the repository from now on, otherwise they will possibly push back all the old commits and the problem will reoccur).
Go to the administration console in FishEye for your repository and under the 'Maintenance' tab, select 'Re-clone and Re-index'.

Source: https://confluence.atlassian.com/display/FISHKB/Git+or+Hg+Repository+exceeds+number+of+allowed+Committers

All comments

Tini Good

Easily done, there are two methods. (1) have your administrator set them through Administration - User Mappings, or (2) have your users indvidually set their own User Mappings by clicking the drop-down menu next to their user name in the upper-right corner, then going to Settings - Author Mapping.

charoco

Sorry I wasn't clear enough -- we've done the mapping -- what I mean is that I'd like all of the different authors to be rolled up so there is one option per real person as opposed to one option per "author". There's no value in filtering on jsmith vs. \\mydomain\jsmith if I've mapped that each of those refers to the same John Smith.

Foong

Sorry I wasn't clear enough -- we've done the mapping -- what I mean is that I'd like all of the different authors to be rolled up so there is one option per real person as opposed to one option per "author". There's no value in filtering on jsmith vs. \\mydomain\jsmith if I've mapped that each of those refers to the same John Smith.

Please clarify more on this with an example

charoco

We have a mapping file that looks in part like this:

For commit activity, multiple committer names are rolled up for each user:

But if you want to search within the repository, each author is a separate entry:

You have to select all 4 entries for Alejandro B. if you want to see all of his activity, which is kludgy and annoying, but because the input element is a multi-select, technically doesn't impact functionality. What's funny here is that though there is an entry for each author, the user name is used as the display name for usability.

However the screen to browse changesets to add to a Crucible review only lets you select one *author*:

If someone wants to add a changest of Alejandro's, they may have to try up to 4 options until they find the one that he is currently using.

Clearly, we are aware of the mapping between user and author in this drop down (the first line for each entry is the user name). I don't understand why it would ever be of value to search on just one of a user's author mappings.

As it stands today, the two most likely places someone is to search activity by user are the two that don't take advantage of the user-author mapping feature.

I was unable to find a setting in the admin area to change this behavior. Is there a way for me to do so, or should this be submitted as a defect?

Foong

But if you want to search within the repository, each author is a separate entry:

Feature request: https://jira.atlassian.com/browse/FE-3999

You have to select all 4 entries for Alejandro B. if you want to see all of his activity, which is kludgy and annoying, but because the input element is a multi-select, technically doesn't impact functionality. What's funny here is that though there is an entry for each author, the user name is used as the display name for usability.

Feature request: https://jira.atlassian.com/browse/CRUC-6035

Workaround:

Rewrite the committers of the repository into another clone repository:

Get a copy of the repository and run the following command to list the current committer names:
```
hg log --template "{author}\n" | sort | uniq
```
Identify those you want to rewrite and add an entry into a authormap file to rewrite them to another address.
Run:
```
hg convert my-clone rewritten-clone
```
Strip the repository that FishEye is indexing and push the rewritten-clone into it. Make sure all your developers use clones of the new copy of the repository from now on, otherwise they will possibly push back all the old commits and the problem will reoccur).
Go to the administration console in FishEye for your repository and under the 'Maintenance' tab, select 'Re-clone and Re-index'.

Source: https://confluence.atlassian.com/display/FISHKB/Git+or+Hg+Repository+exceeds+number+of+allowed+Committers

charoco

Thanks,

I'll keep an eye on those feature requests. The workaround looks a little extreme, so I think we'll just live with the existing behavior for now