The solution is literally in the post above yours. 
We should fix the script. Maybe you can create a PR that resolves the issue for everyone?
Thanks, that fixed it, sorry about that. In penance for my inability to read I opened Added duplication to name to prevent modification of frozen string exception by adam-skalicky · Pull Request #30325 · discourse/discourse · GitHub to save anyone else the shame of asking a dumb question.
1개의 좋아요
Does this import script make Discourse replicate Mailman 2 email threading in any way (eg using the little Discourse arrow to signify "In-Reply-To) or is it purely chronological (for each thread based on Message-ID, In-Reply-To and References)?
1개의 좋아요
Yes, it does
3개의 좋아요
Cool. Quite a few of my mailing list emails haven’t got the In-Reply-To and References headers that they should have, so might be imported as new topics rather than just replies. From memory, the script uses those headers or subject headers (not both).
I think I might have asked this in the distant past, but are there any non-manual ways of adding these headers to the MBOX file and/or otherwise rearranging the emails before or after importing to Discourse?
It’s possible now to merge topics and keep chronological order so maybe that’s the answer. They’d just be missing the little Discourse arrow to signify who the message was in reply to.
1개의 좋아요
The mbox import script has two phases. The first one is indexing and outputs a SQLite database. You could either modify the data in the SQLite before the import, or you modify the Ruby script.
All the magic of sorting/grouping by subject or headers happens here:
You could add your own logic of grouping if you know how you want to group emails.
3개의 좋아요
It’ll be a while before I even consider something so complex!
At https://bazaar.launchpad.net/~mailman-coders/mailman/2.1/view/head:/Mailman/Archiver/pipermail.py#L669 Mailman 2’s Pipermail seems to look for the following in order of preference:
- In-Reply-To.
- References.
- Oldest email with matching subject.
That combination of approaches seems ideal. In the third case, it might make sense for Discourse not to use the “in reply to” arrow.
From memory, Mailman 3’s Hyperkitty didn’t consider subject at all, which was not as good.
2개의 좋아요
Pardon me chiming in with a possibly stupid question, but I could not find a clear answer here. I would like to know if the import process creates a new Discourse user for each email, with de-duplication of course, or if they all go in as one system user. I have a mailing list with 20 years of posts and it’s pretty big and hard to experiment with. Abd also, what about replies in the original list? Do they get threaded in?
Yes, the users get created, one per email address.
Google Groups의 데이터를 Google Takeout으로 내보낸 뒤, .mbox 파일을 업로드하고 가져오기를 수행했습니다.
data/folder를 기존 카테고리에 매핑하는 데 이 단계들이 도움이 되었지만, 이 작업은 import 컨테이너에서 수행해야 합니다. 이 글처럼 app 컨테이너에서 수행하면 안 됩니다:
./launcher enter import
rails c
# URL에 표시된 카테고리 ID를 사용하세요. 예를 들어
# 카테고리 경로가 /c/soccer/16처럼 보이면 ID는 16입니다.
category = Category.find(16)
# mbox 파일이 저장된 디렉터리 이름을 사용하세요. 예를 들어,
# 파일이 import/data/foo에 저장되어 있다면 디렉터리 이름으로 "foo"를 사용해야 합니다.
category.custom_fields["import_id"] = "soccer"
category.save!
이미 Discourse에 자체적으로 마이그레이션한 사용자들이 있어, 가져오기 스크립트가 이 사용자들의 연락처를 생성하지 못했습니다(아마도 나쁜 일은 아닐 것입니다). 하지만 이 기존 Discourse 사용자가 관여한 가져온 메시지들은 발신자가 이름 대신 system으로 표시됩니다.
기존 사용자를 가져온 메시지에 매핑하는 방법이 있을까요?
아직까지는 최근 백업에서 복원하여 모든 것을 되돌렸습니다. 기존 Discourse 사용자와 그들의 가져온 메시지를 처리하는 방법에 대한 지침을 얻어 다시 시도할 준비가 되어 있습니다.
업데이트:
Claude가 기존 사용자 매핑 문제를 해결하는 데 도움을 주었습니다. 위 코드 외에 다음 루프를 rails 콘솔에서 실행해야 합니다:
User.where("id > 0").find_each do |u|
email = u.email.downcase
unless u.custom_fields["import_id"].present?
u.custom_fields["import_id"] = email
u.save_custom_fields
end
end
1개의 좋아요