안녕하세요,
#231에서 제거된 동작을 다시 가져오면 좋겠습니다.
구체적으로, ical 클라이언트를 events.ics 또는 동등한 경로로 지정하여 사이트의 모든 이벤트를 가져올 수 있도록 하는 기능입니다.
또한, download-calendar.js 대체 파일에서 DESCRIPTION, URL, ORGANIZER 필드가 누락되어 있습니다. 이 중 앞의 두 필드가 저에게는 더 중요합니다.
#169를 반영하여 “토픽별” 이벤트 내보내기를 추가해 주시면 더 좋겠지만, 이는 선택 사항입니다.
캘린더에서 이벤트를 구독할 수 있다면 정말 기쁠 것 같습니다.
/upcoming-events를 반영하여 /upcoming-events.ics를 볼 수 있으면 좋겠습니다.
하지만 특정 카테고리(혹은 단일 태그?)로만 가져올 수 있는 방법도 좋은 추가 기능이 될 것 같습니다.
예를 들어 카테고리 ID로 필터링하기 위해 /upcoming-events.ics?category=12 같은 형식이 어떨까요?
토픽별로 필터링된 전체 ICS 피드에 +1합니다.
개인정보 보호 문제로 인해 이것이 어렵다는 것은 알고 있습니다. 일반적인 방식은 사용자별 피드를 나타내는 무작위 해시 피드가 생성되는 것입니다.
음, 뭐… 우리가 쓰는 달력과 상관없이 공적인 URL은 맞긴 한데…
저도 이 기능에 대한 지지를 표명하고 싶습니다. 이미 이 주제에 대해 투표했습니다.
전체 사이트 또는 사용자별 ICS 내보내기 기능을 복원하면 우리 커뮤니티의 워크플로우에 매우 큰 도움이 될 것입니다. PR #231에서 제거된 내용을 재검토할 계획에 대해 업데이트가 있나요?
개인정보 보호 또는 구현과 관련된 우려 사항이 있다면, 사용자별 비공개 ICS 피드를 대안으로 고려해 볼 수 있을 것입니다.
검토해 주셔서 감사합니다!
.json 엔드포인트가 이미 존재하므로 개인정보 보호에 대한 우려는 없을 것 같습니다. 이는 단순히 다른 형식의 포맷일 뿐입니다.
@cvx / @j.jaffeux 이벤트 인덱스 라우트에 .ics를 다시 도입하는 것에 대한 의견이 있으신가요 (제거됨: DEV: Remove old ics code - Pull Request #231 - discourse/discourse-calendar - GitHub)? 제 생각에는 쉬운 개선 사항인 것 같습니다.
이미 다음을 수행하고 있습니다:
DiscoursePostEvent::EventFinder.search(current_user, filtered_events_params)
그리고 MAX_RESULTS(최신순 정렬)를 설정하여 이 부분과 .json 파일이 너무 커지지 않도록 할 수 있습니다.
GET /discourse-post-event/events.ics를 통한 ICS 내보내기 기능을 다시 추가했습니다 (DEV: add ical format response for discourse-post-events index route - Pull Request #35143 - discourse/discourse - GitHub 기준). 이 엔드포인트에는 이벤트 200개라는硬性 제한이 있습니다. 사이트에 이벤트가 200개를 초과하며 전체 내보내기를 원하신다면, 날짜 문자열을 받는 before 및 after 쿼리 파라미터를 사용하여 반복 처리(iteration)할 수 있습니다. 해당 엔드포인트에서 허용되는 전체 파라미터 목록은 추후 API 문서에 추가할 예정입니다.
PR #35143 병합해 주셔서 감사합니다. .ics 내보내기가 공식적으로 복원되어 정말 기쁩니다.
한 가지만 확인하고 싶은 것이 있습니다. Discourse가 비공개 RSS/Atom 피드(/topics/feed.rss?token=…)를 처리하는 방식과 유사하게, 사용자 토큰이나 API 키를 사용하여 이 피드를 인증할 수 있는 가능성(또는 향후 계획)이 있을까요?
현재 /discourse-post-event/events.ics는 공개 이벤트에서만 작동하는 것 같습니다. 이로 인해 Outlook / Google 캘린더에서 비공개 카테고리에 구독할 수 없습니다.
경로 프록시(external script)를 통해 피드를 중계해야 하는 번거로움 없이, 캘린더 클라이언트에서 비공개 이벤트를 안전하게 노출할 수 있도록 경량화된 토큰 기반 접근 방식(사용자별 또는 사이트별, 읽기 전용)만으로도 충분할 것입니다.
추가될 수 있는 기능인가요, 아니면 제가 놓친 기존 매개변수를 통해 이미 가능한 것일까요?
이것은 별도의 기능 요청으로 보입니다. API 키를 사용하여 기술적으로 구현 가능할 것 같으므로, 쉽게 이를 어떻게 진행할 수 있을지가 질문의 핵심인 것 같습니다.
이 이슈를 닫고 이 주제에 대해 새 항목을 열어주시기 바랍니다.