Redmine Plugin Spec

So, after yesterday’s demo, I found that Redmine can actually already do all of what I showed in my plugin via Custom Fields :man_facepalming:. The approach hasn’t changed though, it’s still a case of “migrate data to custom fields, remove backlogs”. Here’s my current proposal:

  • Custom fields can do multi select, so lets use that
  • Can use Target Version, or hide it and use single-valued Fixed-in to indicate a target release
    • We can play with this, the data is easy to migrate around
  • A small plugin added to enhance the Version show page, and possible add some API extensions we might still need (TBC)

In terms of migrating data, my plan would look like this:

  • Sprint & Backlog data (currently seen here:
    • create custom field “Backlog” as a list-select
    • One value per team, multiselect allowed
    • Migrate issue.fixed_version_id (displayed as Target Version) => the new custom_field
      • Repeat this for each backlog that needs migrating
cf = CustomField.where(name: 'Backlog').first
version = Version.find(name: 'Team Tom - Iteration 16').first #example
issues = Issue.where(fixed_version_id: version.id)
issues.each do |i|
  CustomValue.create(customized_type: 'Issue', custom_field_id: cf.id, value: version.id.to_s, customized_id: i.id)
done

PAUSE HERE - we’ll want to ensure all backlogs are correct via the custom field and team leads are happy with this part of the workflow. Then:

  • Clean up old Versions, create missing releases as needed (e.g. 1.17.1 isn’t there right now)
    • We already have “Found in Release”
      • Rename to “Found in Releases”
      • Make multivalued to match “Fixed in”
      • No migration needed
  • Create “Fixed in Releases” custom field
    • Migrate issue.release_id (Backlogs field) to Fixed In Release
cf = CustomField.where(name: 'Fixed In Release').first
issues.all do |i|
  next if i.release_id.nil?
  CustomValue.create(customized_type: 'Issue', custom_field_id: cf.id, value: i.release_id.to_s, customized_id: i.id)
end

This completes the data migration (I think), although we may need to re-set fixed_version_id on closed issues to be the lowest value of the Fixed in Release custom field mutli-select. This can be investigated later as it’s not so critical (only historical).

Then we can update the plugins:

  • Add version_extensions plugin to enhance the version page with fixed/found issues
  • Remove backlogs

The version_extensions plugin just enhances the Version page to show the related custom fields:
image

However we can iterate on this plugin to add any other Version-related api/ui extras we need.

I’ll leave this here for a week, for comments, and then we’ll see about actually starting this migration some time soon :slight_smile: