Comments (11)
However the tool seems to ignore the mappings (or at least I am not able to find the error) and I can see following entries in the log:
[I][15:13:38] Connecting to Jira...
[I][15:13:38] Retrieving Jira fields...
[I][15:13:38] Retrieving Jira link types...
[I][15:13:38] Export started. Selecting 1 items.
[I][15:13:38] Initializing Jira field mapping...
[W][15:13:42] Ignoring target mapping with key: 'System.History', because it is already configured.
[W][15:16:28] Ignoring target mapping with key: 'System.History', because it is already configured.
[W][15:16:32] Ignoring target mapping with key: 'System.History', because it is already configured.
[W][15:16:33] Ignoring target mapping with key: 'System.History', because it is already configured.
Migrating multiple source fields to the same target fields is not supported. I will mark this as a feature request.
:)
from jira-azuredevops-migrator.
OK, thank you. I need to think of a workaround here... Is a change required only on the export side or also on the import side?
from jira-azuredevops-migrator.
Pretty sure it would only be on the export side!
Sure! A temporary but rather annoying workaround would be to set the target field as a temporary token and then search-replace all such tokens with "System.History".
For example I could see you doing something like this:
{
"original-name": "Melder",
"source": "customfield_10160",
"target": "UniqueReplace1"
},
{
"original-name": "Fehlerart",
"source": "customfield_16324",
"target": "UniqueReplace2"
},
{
"original-name": "Fachbereich",
"source": "customfield_10460",
"target": "UniqueReplace3"
},
{
"original-name": "Anforderungsart",
"source": "customfield_16324",
"target": "UniqueReplace4"
},
Then after the Export, go inside an IDE like VS Code and do a folderwide search-replace in your folder (with regex enabled):
UniqueReplace\d+
->System.History
Finally go ahead with the Import.
This should take care of it in theory, but I have never tried before, so I cannot say with 100% certainty. You are welcome to try though!
from jira-azuredevops-migrator.
First thing I tried is to add another History entry in the exported Jira json file, like this:
{
"ReferenceName": "System.History",
"Value": "Value 1"
},
{
"ReferenceName": "System.History",
"Value": "Value 2"
},
And after the import just "Value 2" gets written in the Azure DevOps work item.
It doesn't seem to be a big code-change on the export side so I might take a swing at it but I haven't checked the import side yet...
from jira-azuredevops-migrator.
Correct, each update would need to be in it's own separate revisions! It can only write to any single Work Item Field once in each revision.
from jira-azuredevops-migrator.
Correct, each update would need to be in it's own separate revisions! It can only write to any single Work Item Field once in each revision.
I see... In this case it is a bigger code-change, but I can only say for sure after I understand the code bahind revisions. 😄
from jira-azuredevops-migrator.
@Alexander-Hjelm
I am trying to make this work and have made following changes in the code to make this work:
Added the option to mapping configuration in the config.json file (additional "customFieldsList" with the list of my custom fields, mapped to "System.History" with the new "MapMultiple" mapper):
{
"source": "multiple",
"customFieldsList": [
"Melder",
"Fehlerart",
"Fachbereich",
"Anforderungsart"
],
"target": "System.History",
"mapper": "MapMultiple"
}
Then I added the "customFieldsList" as a property in the Field class:
[JsonProperty("customFieldsList")]
public List<string> CustomFieldsList { get; set; }
Added the handling of the "MapMultiple" mapper in JiraMapper::InitializeFieldMappings:
case "MapMultiple":
value = r => FieldMapperUtils.MapMultipleValues(r, item.CustomFieldsList, item.Target, _config, _jiraProvider);
break;
Implemented the concatenation of custom field "name: value" pairs in the MapMultipleValues method:
public static (bool, object) MapMultipleValues(JiraRevision r, List<string> customFields, string targetItem, ConfigJson config, IJiraProvider jiraProvider)
{
if (r == null)
throw new ArgumentNullException(nameof(r));
if (config == null)
throw new ArgumentNullException(nameof(config));
var mappedValues = string.Empty;
var customFieldId = string.Empty;
var customFieldValue = string.Empty;
//go through the list of source fields
foreach (var customFieldName in customFields)
{
//fetch the Jira Custom Field ID via the Jira Rest API
customFieldId = jiraProvider.GetCustomId(customFieldName);
//fetch the field value from the list of fields in the Jira Revision
customFieldValue = r.GetFieldValue(customFieldId);
//add an entry only if the custom Field has a value in the Jira Revision
if (customFieldValue != null)
{
//add a breakpoint before every new key-value pair (except for the first one)
mappedValues += (mappedValues != string.Empty) ? "</br>" : "";
//put name and value together as "name: value"
mappedValues += customFieldName + ": " + customFieldValue;
}
}
return (true, mappedValues);
}
I've probably butchered the code a lot and left some loose ends unhandled but this is as far as I got so far to get multiple custom fields mapped to the System.History field.
What I am experiencing at the moment is that all the original Jira comments get overwritten by those same custom field values:
Before I go and lose a lot of time debugging the code, do you know where I got it wrong and where I might need to adjust the code (or maybe add some additional forks/checks)?
Thank you in advance for your support. 🙏
Cheers,
Marko
from jira-azuredevops-migrator.
My best guess is that it would be the JiraMapper blocking the old field mapping for System.History because it contains the same target
property as your new field mapping. This will cause one to override the other. Currently only one field mapping is allowed per field per Work Item Type.
jira-azuredevops-migrator/src/WorkItemMigrator/JiraExport/JiraMapper.cs
Lines 151 to 177 in 589c4ab
from jira-azuredevops-migrator.
Thank you, @Alexander-Hjelm. Yes, that's what I first thought as well - that it is caused by the limitation of the Dictionary to hold one mapping for each key (target work item type). What would you recommend as the easiest workaround?
from jira-azuredevops-migrator.
I can think of a simple workaround which would be best implemented as a post-migration task. I would have mapped Comment
to let's say "target": "System.History"
and your new aggregated field to a unique token like "target": "System.History1"
. You can then do a folder-wide search replace in the workspace folder using e.g. an IDE or a script. You would replace all ocurences of System.History1" with "System.History". I think that this should adequately solve your problem, unless there are any instances where the the Jira Comment and your aggregated field are updated on the same revision, which I assume is not the case.
We would probably need to do a major redesign of the JiraMapper component if we want to properly support this scenario, plus think about all possible conflict scenarios. I am thus leaving this issue as a Feature Request for when we can commit to it! :)
from jira-azuredevops-migrator.
That's a good idea and easy to implement - as one additional line of code before the WiItem gets serialized to the JSON file. Will do that... Thank you so much!
from jira-azuredevops-migrator.
Related Issues (20)
- Link to source Ticket in Jira HOT 4
- JIra Key not found exception HOT 3
- WorkItems get repeat after importing second time HOT 2
- Update HOT 1
- Custom fields assigned a value on creation and not changed are not exported HOT 10
- why we are using revsions while migration .. instead we could have used jira api which just fetches info straightforward HOT 1
- Import all the fields of Test case instead of few fields. HOT 1
- Is there a version of application which is supporting Jira with extension structure HOT 15
- Development / Releases are supported? HOT 6
- show round time in effort field HOT 12
- Jira Users are not getting migrated HOT 1
- Description Field Blank in ADO User Story HOT 3
- Flat Migration HOT 3
- Add support for development links to non-migrated GitHub repositories
- Support for Continuing an Import at a Specific Revision HOT 4
- Best way to migrate large amount of issues HOT 14
- how can I use the tool if I have issue types Test and Test Plan and I don't have Task or sub task or any issue types else on jira ? HOT 2
- Linked issue is lost during the import/export process HOT 1
- Workitem Linking not working as expected HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jira-azuredevops-migrator.