모두에게 감사드립니다!
저는 여러 개의 Discourse 인스턴스를 실행하고, 배경에서 Discourse가 아닌 종합적인 관리/조정 시스템을 운영할 예정입니다. 토픽은 두 가지 방식으로 Discourse에 추가됩니다. 사용자가 일반적인 Discourse 토픽 생성 메커니즘을 통해 추가하거나, 관리/조정 시스템이 API를 통해 추가하는 방식입니다.
API를 통해 토픽이 생성되는 경우, 해당 토픽은 이미 자체적인 비-Discourse ID를 가진 작업 또는 유사한 워크플로 항목을 나타내는 경우가 많습니다. 이를 "외부 ID(External ID)"라고 부르겠습니다.
사용자가 Discourse 내에서 토픽을 생성하는 경우, 웹훅을 사용하여 Azure 함수를 트리거하여 중앙 시스템 내에 스텁과 같은 복제본을 생성할 것입니다(이로써 Discourse 메시지가 더 넓은 콘텐츠, 작업 등의 흐름에 연결되도록 합니다). 따라서 이 경우에도 Discourse 토픽은 간접적으로 고유한 "외부 ID"를 가지게 되며, 우리는 이를 API를 통해 토픽에 업데이트하는 것을 제안합니다.
우리는 각 토픽이 로드될 때 Ajax를 사용하여 중앙 시스템에서 비-Discourse 중심 정보를 검색하고 토픽 화면에 표시하는 자체 개발 Discourse 테마 컴포넌트를 가지고 있습니다.
Discourse 토픽 ID를 Ajax 호출의 매개변수로 사용하여 일치하는 데이터를 찾을 수도 있지만, "외부 ID"를 사용하는 것이 더 효율적입니다(여러 가지 이유로 더 깔끔합니다 - 조회 과정 등을 피할 수 있기 때문입니다).
우리는 "외부 ID"를 커스텀 필드에 쉽게 저장할 수 있습니다 - 다른 데이터를 위해 이미 하나를 가지고 있기 때문입니다 - 하지만 토픽 API에 정확히 우리가 필요한 것처럼 보이는 “external_id” 필드가 있다는 것을 알게 되었습니다. 그리고 여러 가지 이유로 이 필드를 사용하는 것이 더 좋습니다 .. 이는 다소 핵심적인 이 필드를 보고서, 내보내기, 아마도 미래의 검색 등에 더 쉽게 통합할 수 있게 해주기 때문입니다.
Discourse API Docs 의 스크린샷을 참조하십시오.
이것은 비교적 새로운 필드인 것 같습니다 - 포럼의 대부분의 조언은 User의 external_id 필드에 관한 것으로, 이는 지금 제가 필요한 것이 아닙니다. 위에서 언급했듯이, 저는 토픽의 Ember 모델을 검색하고 있습니다(제 자체 테마 컴포넌트 내에서) 그리고 이를 통해 토픽에 대한 거의 모든 정보를 얻을 수 있습니다 … 하지만 external_id 필드는 제외됩니다.
(위와 같이 - 저는 이 사이트 어딘가에서 가져온 이 코드를 사용하여 토픽을 가져오고 있습니다, 지금은 어디서 가져왔는지 모르겠습니다:
const topicController = api.container.lookup("controller:topic");
if (topicController) {
const thisTopic = topicController.get("model");
따라서 요청 사항입니다 - 토픽 전용 external_id 필드가 모델(“thisTopic”) 어딘가에 숨겨져 있는지, 아니면 제가 이 개념들을 오해하고 있는 것이며 이 외부 ID를 저장하기 위해 그냥 커스텀 필드를 사용해야 하는지(이 방식이 작동하는 방법과 어떻게 작동하는지는 알고 있습니다 .. 하지만 실제로 사용 가능한 경우, 개별적인 external_id를 사용하는 것의 깔끔함과 미래 지향성을 더 선호합니다).
다시 한번 도움을 주셔서 감사합니다, 정말 감사합니다!