-
Notifications
You must be signed in to change notification settings - Fork 8.5k
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
base: dev/mt/intermediate-db-schema
Are you sure you want to change the base?
DEV: First pass at group_users
step for Discourse converter
#32907
Conversation
4e7cc97
to
30518c1
Compare
@source_db.query <<~SQL | ||
SELECT * | ||
FROM group_users | ||
WHERE user_id >= 0 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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], |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
30518c1
to
681c53f
Compare
This change implements converter step for converting Discourse `group_users` to intermediate DB format needed for import into Discourse.
9529e31
to
44df073
Compare
6a4ffb5
to
f07383b
Compare
This change implements converter step for converting Discourse
group_users
to intermediate DB format needed for import into Discourse.