If we are going to move issues to git.drupalcode.org, then we lose the data to integrate them with the rest of Drupal.org. Issues have an entity reference field to issues in the parent field and in the related field (multiple values), which will have to be replaced somehow.
Issue content type (/admin/structure/types/manage/project-issue/fields/)
* field_issue_parent
* field_issue_related
Deployment instructions
- #3265112: Decouple change records from www.drupal.org issues need to be merged first and the deployment instructions of those applied.
- Merge this and make sure that the new link fields do show up in the "Issues" content type.
- Review the field group settings ("/admin/structure/types/manage/project-issue/fields") and put the new fields next to the old ones in the same order (this wouldn't go into the feature).

- Features should appear as "Default" and a new view called "Drupalorg Issue relations blocks" should be present in the views section.
- Go to "/admin/structure/block" and bring to the second sidebar the four new blocks starting with "Drupalorg: ". These mirror the same four blocks that start with "Project issue: ".

- The visibility configuration should be the same as the ones of the following point, so just copy the URL pattern and the content type where it should be shown from those.
Pattern: All pages except those listednode/*/* // Content types: Issue
- Go to "/admin/structure/block" and remove from the second sidebar the four old blocks starting with "Project issue: ". The new ones should be in the same position and order as the old ones were.
- Run the insert-select queries below (and clear field caches after??)
INSERT INTO field_data_field_issue_parent_link (entity_type, bundle, deleted, entity_id, revision_id, language, delta, field_issue_parent_link_url, field_issue_parent_link_title, field_issue_parent_link_attributes)
SELECT entity_type, bundle, deleted, entity_id, revision_id, language, delta, CONCAT("https://www.drupal.org/node/", field_issue_parent_target_id) as field_issue_parent_link_url, NULL as field_issue_parent_link_title, "a:0:{}" as field_issue_parent_link_attributes
FROM field_data_field_issue_parent
WHERE bundle = 'project_issue';
INSERT INTO field_revision_field_issue_parent_link (entity_type, bundle, deleted, entity_id, revision_id, language, delta, field_issue_parent_link_url, field_issue_parent_link_title, field_issue_parent_link_attributes)
SELECT entity_type, bundle, deleted, entity_id, revision_id, language, delta, CONCAT("https://www.drupal.org/node/", field_issue_parent_target_id) as field_issue_parent_link_url, NULL as field_issue_parent_link_title, "a:0:{}" as field_issue_parent_link_attributes
FROM field_revision_field_issue_parent
WHERE bundle = 'project_issue';
INSERT INTO field_data_field_issue_related_links (entity_type, bundle, deleted, entity_id, revision_id, language, delta, field_issue_related_links_url, field_issue_related_links_title, field_issue_related_links_attributes)
SELECT entity_type, bundle, deleted, entity_id, revision_id, language, delta, CONCAT("https://www.drupal.org/node/", field_issue_related_target_id) as field_issue_related_links_url, NULL as field_issue_related_links_title, "a:0:{}" as field_issue_related_links_attributes
FROM field_data_field_issue_related
WHERE bundle = 'project_issue';
INSERT INTO field_revision_field_issue_related_links (entity_type, bundle, deleted, entity_id, revision_id, language, delta, field_issue_related_links_url, field_issue_related_links_title, field_issue_related_links_attributes)
SELECT entity_type, bundle, deleted, entity_id, revision_id, language, delta, CONCAT("https://www.drupal.org/node/", field_issue_related_target_id) as field_issue_related_links_url, NULL as field_issue_related_links_title, "a:0:{}" as field_issue_related_links_attributes
FROM field_revision_field_issue_related
WHERE bundle = 'project_issue';
Comments
Comment #2
fjgarlin commentedComment #3
fjgarlin commentedComment #4
drummLooks like these will migrate cleanly to GitLab, https://docs.gitlab.com/ee/user/project/issues/related_issues.html. So we need to figure out what will best support incremental migration. I think we might have to use a link field, and also put in some extra work on display formatting, to pull in the issue title whether its on GitLab or Drupal.org, since the migration will take weeks to get to all projects.
Comment #5
fjgarlin commentedWhen it comes to the issue migration, it'll be easy with the "related_issues" feature, although we will lose the concept of "parent/child", they will all be "related".
If we change entity references to links (as we are doing in the related issues), then the following blocks will be affected:

Comment #6
drummParent/child could be blocks/blocked-by. That’s how I usually interpret parent/child on Drupal.org anyway.
(GitLab has epics too, I haven’t spent much time looking into them. I’m guessing GitLab might not have a way to convert an epic to an issue or vice versa. Wouldn’t want to migrate them to something that boxes them into a different data type. And sticking to issues is straightforward.)
Comment #7
drummFor the reverse entity references - we’ll have to keep track of those to complete the migration anyway, so cross-project issue relations can be reconstructed once both projects are migrated. It doesn’t necessarily have to look perfect, especially since this is mainly for less-common cross-project references. Maybe we could append the un-migrated issue relations with a views alter hook.
Comment #8
fjgarlin commentedI managed to find an easy way to replicate the child and referenced by blocks.
All the blocks do have a 1 to 1 equivalent with the new link fields.
See this page where all four blocks are present:
https://fjgarlin-drupal.dev.devdrupal.org/project/drupal/issues/3306216
Both parent and related issues are now links. Note that the code has been built on top of #3265112: Decouple change records from www.drupal.org issues and #3295357: Migrate drupal.org issues to GitLab issues, so the MR shows the changes there too as those two issues aren't deployed yet.
Comment #10
fjgarlin commentedComment #11
fjgarlin commentedDiff from the changes added just for this issue on top of the two mentioned above.
Comment #12
fjgarlin commentedComment #13
fjgarlin commentedComment #14
fjgarlin commentedComment #15
fjgarlin commentedComment #16
fjgarlin commentedComment #20
fjgarlin commentedRebasing was a bit of a mission, so I created a new branch and brought the code changes from the other one: https://git.drupalcode.org/project/drupalorg/-/merge_requests/272
This is not deployed yet to any dev environment, so I will assign to myself until it's ready for test/reivew.
Comment #21
fjgarlin commentedComment #22
fjgarlin commentedComment #23
fjgarlin commentedMR rebased. This will be needed before starting to migrate issues to GitLab.
Comment #24
fjgarlin commentedComment #25
fjgarlin commentedUpdated deployment instructions and added supporting images.
Comment #26
fjgarlin commentedComment #27
fjgarlin commentedTest new side blocks:
- https://fjgarlin-drupal.dev.devdrupal.org/project/ai_integration_eca/iss...
- https://fjgarlin-drupal.dev.devdrupal.org/project/field_encrypt/issues/3...
Comment #28
fjgarlin commentedComment #29
fjgarlin commentedComment #30
drummIf we remove the old fields, I believe that will remove the per-comment history of changes like comment #2 on this page. I fully expect that will be something that people will miss. Migrating this history for the new field would be a nontrivial task, nodechanges stores data as quite an unserialized blob.
Does the migration to GitLab issues preserve nodechanges, as in when someone added a parent/related issue, tag, etc? If it does not, then we don’t need to worry about the data loss as much, we’ll lose it in the end anyway. Or if this is a requirement, we might have some more work to do.
Comment #31
fjgarlin commentedThat is correct. Removing those fields will likely make those disappear.
> Migrating this history for the new field would be a nontrivial task, nodechanges stores data as quite an unserialized blob.
This would require a lot more processing per comment, which will add to the total migration time. We'd need to build logic to process the nodechanges field into a sensible "markup".
> Does the migration to GitLab issues preserve nodechanges
No, it only uses nodechanges to detect when the issue was closed or when a file was uploaded, nothing else.
Comment #32
fjgarlin commentedUpdated deployment steps as we no longer need the drush command.
Not a blocker for this, but I will clean up the code not needed.
Comment #33
fjgarlin commentedThe cleanup is now done. All ready for review.
Comment #34
drummI realized this probably needs a validator to make sure the links are a Drupal.org domain, production or dev/staging. That will remove the possibility of messiness ahead of migration, and give people updating issues a notice when they mis-paste. We probably should have had this for change records, too.
Comment #35
fjgarlin commentedGood suggestion. Validation added for issues and change records link fields.
Comment #37
drummThis is now deployed!