martin
(Martin Brennan)
2월 24, 2026, 11:07오후
23
지연된 점 사과드립니다. 이제 병합되었습니다.
4개의 좋아요
방금 문제가 여전히 조금 있다는 것을 발견했습니다. 모바일 Edge 브라우저와 PC용 Edge 브라우저를 사용하여 관리자만 권한을 가질 수 있도록 설정했습니다. 페이지에는 설정이 성공적으로 완료되었다고 표시되었지만, 새로고침하면 다시 “없음” 상태로 돌아가고 있습니다.
martin
(Martin Brennan)
2월 26, 2026, 1:20오전
25
여기서 약간 혼란스럽습니다. 만약 당신의 사이트(https://tracker.discourse.group/ 맞죠?)에 로그인하면 목록에서 Staff 옵션을 볼 수 있는데, 당신은 이 옵션이 없거나 (또는 더 정확하게 말하면 번역되어 있는 것 같습니다:
이것을 선택하고 새로고침하면 유지됩니다. 제가 올바른 사이트에서 테스트하고 있는 건가요?
Moin
2월 26, 2026, 7:09오전
26
재현할 수 있습니다. 문제가 스태프 그룹이 저장되지 않는 것이 아니라, 재로드 후 다가오는 변경 사항에서 "선택됨"으로 표시되지 않는 것 같습니다.
즉, 여기서 “Team”(스태프)을 선택한 후 재로드하면 인터페이스에 "없음"으로 표시됩니다. 하지만 "특정 그룹"을 선택하면 예상대로 팀 그룹에 이미 활성화되어 있음을 확인할 수 있습니다. 따라서 "staff"는 저장되어 있고 스태프에 대해 정상적으로 작동하지만, 다가오는 변경 사항 테이블에서 이를 확인할 수 없습니다.
수정:
브라우저 개발 도구를 확인해 보니 JSON 페이로드에 다음이 포함되어 있음을 알게 되었습니다:
“enabled_for”: “staff”
드롭다운 값은 enabled_for에서 초기화되지만, select의 “Staff” 옵션은 실제 스태프 그룹 이름(예: "Team")을 값으로 사용합니다.
"staff"는 드롭다운 옵션 값 중 하나가 아니기 때문에, 재로드 후 select가 이를 매칭할 수 없어 "없음"으로 표시되도록 폴백됩니다.
1개의 좋아요
자체 VPS에 배포한 웹사이트에서 이 문제가 발생하며, https://tracker.discourse.group/ 가 아닙니다.
martin
(Martin Brennan)
2월 27, 2026, 3:15오전
28
음, 알겠어요. 감사합니다. 다시 재현해볼게요
2개의 좋아요
Moin
7월 1, 2026, 1:46오후
31
오늘 “보고서 개선” 변경 사항에서도 비슷한 문제를 발견한 것 같습니다. 곧 제거될 예정이라는 것은 알고 있지만, 원인이 무엇인지 확실하지 않아 일단 보고합니다. 드롭다운에서 “전체 사용자” 대신 "스태프"와 "사용자 정의 그룹"만 제공되는 유일한 변경 사항이기 때문일까요? 그렇다면 유사한 구성을 가진 향후 변경 사항에도 영향을 미칠 수 있습니다.
ajax.js:233 PUT https://forum.discourse.group/admin/config/upcoming-changes/toggle 422 (Unprocessable Content)
send @ jquery.js:9940
ajax @ jquery.js:9521
i @ ajax.js:233
$ @ ajax.js:252
toggleChange @ upcoming-change-item.gjs:192
enabledForChanged @ upcoming-change-item.gjs:264
handleInput @ d-select.gjs:51
handleMouseUp_ @ (unknown)
2개의 좋아요
@Moin 감사합니다 - 곧™ 수정될 예정입니다
main ← fix-staff-enable-when-everyone-excluded
merged 06:34PM - 01 Jul 26 UTC
Fixes a bug reported at https://meta.discourse.org/t/issue-with-enabling-upcomin… g-changes/395881/31
### What
When an upcoming change's `allow_enabled_for` excludes `everyone` (for example `[staff, specific_groups]`, as the former `reporting_improvements` change had), selecting **Staff** in the *Enabled for* dropdown failed with a `422` and the selection snapped back to *No one*.
### Why
`enabledForChanged` toggled the setting on **before** persisting the staff group. On the server, `UpcomingChanges::Toggle#allowed_enabled_for_target` treats "enabled with no group configured" as targeting `everyone` — which these changes disallow — so the toggle was rejected and the change was never enabled.
Changes that allow `everyone` (the common case) weren't affected, because the initial toggle passes the policy and the staff group is saved a moment later.
### Fix
Persist the staff group **before** toggling, mirroring the existing "specific groups" path (which already saves groups first and only then enables the change). By the time the setting is toggled on, it is already scoped to staff, so the policy passes.
### Tests
- **Component** (`upcoming-change-item-test.gjs`): asserts the request order is `groups` → `toggle` for the staff selection on an `everyone`-excluded change, and that everyone/no-one still toggle first then clear groups.
- **System** (`admin_upcoming_changes_spec.rb`): enabling for staff on an `everyone`-excluded change now succeeds and persists the staff `SiteSettingGroup`.
### Screenshots
Before / after — selecting **Staff** on an `everyone`-excluded change (Horizon, light, desktop):
<img width="1664" height="466" alt="reporting-improvements-before-after" src="https://github.com/user-attachments/assets/085d9e7d-f61b-47bc-a683-5792e72a7217" />
3개의 좋아요
Moin
7월 1, 2026, 5:03오후
33
고맙습니다. 변경 사항이 이미 제거되었기 때문에 확인이 불가능합니다.
1개의 좋아요