Skip to content

DEV: First pass at group_users step for Discourse converter #32907

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 3 commits into
base: dev/mt/intermediate-db-schema
Choose a base branch
from

Conversation

s3lase
Copy link
Contributor

@s3lase s3lase commented May 26, 2025

This change implements converter step for converting Discourse group_users to intermediate DB format needed for import into Discourse.

@github-actions github-actions bot added the migrations-tooling PR which includes changes to migrations tooling label May 26, 2025
@s3lase s3lase force-pushed the dev/mt/intermediate-db-schema branch 2 times, most recently from 4e7cc97 to 30518c1 Compare May 26, 2025 16:50
@source_db.query <<~SQL
SELECT *
FROM group_users
WHERE user_id >= 0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Depending on what we decide to do with automatic groups, we might need to filter automatic groups in here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My current thinking around this is that we still convert the automatic groups and their related entities (group_users in this case). During import, we can then map these automatic groups to the destination instance’s corresponding automatic groups without importing them as new. And then ensure group_users end up in the right automatic group.

So, for example, a moderator on the source site would automatically become a moderator on the destination site.

The unanswered question, here though, is what to do if the automatic group membership criteria differ between instances, such that a user who was eligible in the source site becomes ineligible on the destination site? I'm reviewing the core implementation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, definitely look at the core implementation to figure out what's the best course of action. I'm not familiar with that logic either. But I think it might make sense to exclude the TL groups.

user_id: item[:user_id],
owner: item[:owner],
notification_level: item[:notification_level],
first_unread_pm_at: item[:first_unread_pm_at],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we skip this? first_unread_pm_at feels like a calculated column.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch! I missed that. I tried to include as many columns as possible, only skipping computed columns. There are probably still a few others.

@s3lase s3lase force-pushed the dev/mt/intermediate-db-schema branch from 30518c1 to 681c53f Compare May 27, 2025 01:21
This change implements converter step for converting Discourse `group_users`
to intermediate DB format needed for import into Discourse.
@s3lase s3lase force-pushed the dev/mt/converter/discourse-group-users branch from 9529e31 to 44df073 Compare May 27, 2025 01:42
@s3lase s3lase force-pushed the dev/mt/intermediate-db-schema branch 2 times, most recently from 6a4ffb5 to f07383b Compare May 29, 2025 12:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
migrations-tooling PR which includes changes to migrations tooling
Development

Successfully merging this pull request may close these issues.

2 participants