Right now, in order to create a tag with the API, I create a temporary topic with the new tag, then delete the temporary topic. Is there a cleaner way?
I don’t know, but a slightly less painful solution would be to create a post in the staff category (where Assets for site design is) and just add the new tags there.
The reason is that you want to create a bunch of tags so that users can use them in the future, but your community doesn’t yet have posts with those tags?
Thanks @pfaffman.
You mean manually adding the new tag? Or is it possible to use the “Update a single topic” API to add a tag to an existing topic? But in that case I would have to store the topic id, which is painful…
I guess this would be a legit use case. But mine is less legit: I use tags to store metadata (object ids from an external app).
Yeah, that’s not a good idea, especially if each tag is only used once.
You should either have a separate database mapping the external IDs to Discourse topic IDs, or write a plugin and use topic custom fields (this is a problem since there’s no existing mechanism to deliver these to the client, I think).
Another solution is to store the value in the post text.
Since there is a legit use case, I believe adding a “new tag” API in the future would be a plus.
I can feel the danger of using tags the way I do. But as I need to display, in Discourse, a list of the topics that relate to a specific external object, the “tags.show” route seems the only way…
Well, what are the external objects? How many topics will one get? will a topic relate to multiple of these things?
You may be able to get away with using search.
The external objects are document subsections. One topic relates to one and only one subsection. A minimum guess is: 100 documents x 100 subsections per document = 10,000 subsections = 10,000 tags in a single Discourse instance. I know this is dangerous, but since I’m in the prototype phase, tags are good enough for me.
Now I didn’t think about the search page before… I’ve just done some tests, but sadly, the results are not formatted like a topic list (with the ‘Replies’, ‘Views’ and ‘Activity’ columns). I guess a “topics only” checkbox that turns the result page into a standard Discourse topic list would be exactly what I need. 
Consider not pre-creating that many topics - there’s often not much to discuss about the Bibliography. You can have a small service that takes a document & subsection ID and redirects you to either the existing topic or opens the composer pre-filled with the document link, subsection ID, etc.
title: Procedures for Smelling, section Keyboards
body: <https://link.to/document/1234#sec-26>
[write your text here]
lookup key: DISCUSS_1234_26
Then it polls /latest.json for new topics and checks them for the magic ID reference phrase I put in on the last line of the example.
Yes, I already have something like this. I don’t create the subsection tags beforehand when a document is created. I’ve changed the “tag not found” page of a subsection so that it looks like an empty topic list with a “New Topic” button at the top. When user clicks the button, I create the tag on the fly using the API and open the composer pre-filled with the generated tag.
네, 있습니다: 태그 그룹을 만들어 원하는 태그를 추가하면 됩니다(관련 API는 여기를 참고하세요).
위에서 설명한 API를 통해 태그를 생성하는 방법(태그 그룹을 생성하는 방식)에는 한 가지 단점이 있습니다. 관리자일 때만 작동하기 때문입니다.
API를 사용하여 태그를 생성하는 또 다른 방법(단, 여전히 관리자만 사용 가능): Upload Tags 메뉴에서 사용되는 문서화되지 않은 API /tags/upload.json입니다. 다음과 같이 사용하세요:
const tags = ['tag1', 'tag2']
const file = new Blob([tags.join('n')], { type: 'text/plain' })
const formData = new FormData()
formData.append('file', file)
$.ajax({
type: 'POST',
url: '/tags/upload.json',
data: formData,
contentType: false,
processData: false
})
태그가 수천 개에 달할 계획입니다. 이 경우에도 이 우회 방법, 즉 태그마다 그룹을 하나씩 만드는 것이 좋은 아이디어일까요? 태그 그룹은 태그만큼 유연한가요?
그렇다면 제 당면한 문제를 해결할 수 있겠고, 그렇지 않다면 태그와 태그 그룹(단 하나의 태그만을 위해)의 중복을 피하려 할 것입니다.
죄송하지만 잘 모르겠습니다.
API가 한 번의 작업으로 하나의 그룹에 여러 태그를 생성할 수 있도록 허용하는 것 같습니다.
감사합니다. 네, 같은 그룹에 여러 태그를 만들 수 있지만 생성 시에만 가능합니다. 업데이트는 가능하지만, 그ためには 그룹을 가져와서 태그를 추가한 뒤 다시 전송해야 합니다. 태그를 추가하는 전용 엔드포인트가 없거든요.
제안해 주신 두 번째 아이디어, 즉 /tags/upload.json 엔드포인트에 대한 건데요.
인터페이스의 업로드 버튼을 찾았습니다. 해당 버튼에서 정상적으로 작동하는 CSV 파일을 만들었습니다. 하지만 Postman이나 Golang에서는 작동하지 않습니다. (아시는 분이라면 csv.NewWriter를 사용했습니다.)
어떤 아이디어가 있을까요?
죄송합니다. 그 도구들로 blob을 생성하고 게시하는 방법을 알지 못합니다.
방법을 알아냈습니다.
필요한 사람이 있으면 저에게 연락 주세요. 여기에는 게시하지 않겠습니다. 내용이 길고 커뮤니티의 99.99%에게는 관련이 없을 가능성이 높기 때문입니다.