wpoely86 / redmine-azure-devops-migrate

script to migrate redmine issue and wiki to azure devops work items and wiki
GNU General Public License v3.0
8 stars 5 forks source link

"To Do" state remains even after complete migration #2

Open krozbol100 opened 3 years ago

krozbol100 commented 3 years ago

Hi,

regarding to this part of migrate.py:

    # we always create in the 'to do' state and later change it to the real value
    # because it gives errors otherwise...
    JsonPatchOperation(op="Add", path="/fields/System.State", value="To Do"),

I've found out that all my issues are migrated but were left in this To Do state. Is it possible that I have to prepare states in Azure Devops to match ones in Redmine? Is it possible to make "map" as you created for authors? I used basic project template, and this script migrated all issues to "Issue" in Azure Devops project.

Also, since basic project template has hierarchy: Epic Issue Task

Would it be possible to map child items to Task, and parent items to Issue? Or to make it configurable (to define parent and child work item types in Azure Devops?

Thanks man a lot and br, Sadmir.

wpoely86 commented 3 years ago

For your first question, there is a mapping on top of the file:

state_map = {
    "Pending": "To Do",
    "In Progress": "Doing",
    "Completed": "Done",
}

What it does is:

    if issue.status.name in state_map and issue.status.name != "Pending":
        state = JsonPatchOperation(op="Add", path="/fields/System.State", value=state_map[issue.status.name])
        work_client.update_work_item([state], work_item_id, project)

Depending on your situation you might have to change that. I've put in a comment to clarify.

For your second question, yeah it is possible to let it create an epic.

JsonPatchOperation(op="Add", path="/fields/System.WorkItemType", value='Epic')

However, my problem was that I couldn't easily figure out if a issue has children in redmine. It's easy to find a parent but not a child...

krozbol100 commented 3 years ago

Hi,

somehow, I run this again and it populated some issues with the values predefined in state_map. Then, I changed the map to accommodate all states from redmine, and then created additional ones in Azure Devops, and everything was fine :-)

Regarding how to extract children, does this make any sense? status = all parent task = all subtask = none

This way, I can filter out all the children (those which have parent task and doesn't have subtasks). But child who has children would be then "parent task = all" and "subtask = all".

Does that make sense to you?

This way, I can manage to do two passes: one to extract children and migrate them to tasks; another pass to extract parents and migrate them to features (or epic or user story etc.).

Will report back once I sort this out.

Thanks and br, Sadmir.

krozbol100 commented 3 years ago

This is working:

issues = redmine.issue.filter(
    project_id="projectname",
    #status_id="*",
    tracker_id="2",
    parent_id='!*',
    child_id='*',
    #created_on=">=2017-01-01",
    sort="created_on",
    include="journals,attachments",
)

But it would require some logic to handle this parent/children separation inside the script, since multiple passes create new issues (you cannot create parents, and then add children in another pass).