fix(proposal): 404 error for co-speaker

[SivanYeh]

Types of changes

Thanks for sending a pull request! Please fill in the following content to let us know better about this change.
Please put an x in the box that applies

• Bugfix
• New feature
• Refactoring
• Breaking change (any change that would cause existing functionality to not work as expected)
• Documentation Update
• Other (please describe)

Description

Resolve 404 error and strange style of table after co-speaker pressed accept/decline during reviewing stage, which "SLUG.proposals.editable" is false.

Steps to Test This Pull Request

Steps to reproduce the behavior:

1. Create 2 users: main speaker A and co speaker B.
2. Go to Django admin and set to cfp stage as doc
3. Sign in as speaker A into http://localhost:8000/en-us/dashboard/ and create a new proposal
4. Go to Django admin and set to review stage.
5. Found the proposal from speaker A and add B in "Additional Speakers" table.
6. Sign in as speaker B into http://localhost:8000/en-us/dashboard/ and press "accept" and "decline" on the request.
7. See error if page 404 shows up.

Expected behavior

404 happened in Step[7] disappear.

More Information

Screenshots

[SivanYeh]

@mattwang44 uncertain if it's a good solution: When I simply remove if/else statement in the dispatch function, 404 no longer shows up(of course) while speaker A remains unaffected(Did I miss anything?)

[mattwang44]

記得修改 test cases

[SivanYeh]

記得修改 test cases

賀! 研究中

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 73.99%. Comparing base (fca6fd2) to head (a018685).
Report is 46 commits behind head on master.

❗ Current head a018685 differs from pull request most recent head 6a6c2d5

Please upload reports for the commit 6a6c2d5 to get more accurate results.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1188      +/-   ##
==========================================
+ Coverage   71.19%   73.99%   +2.79%     
==========================================
  Files          84       81       -3     
  Lines        3451     3057     -394     
==========================================
- Hits         2457     2262     -195     
+ Misses        994      795     -199     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mattwang44]

這個 form 永遠都會被藏起來，這是我們想要的嗎？

[SivanYeh]

果然答案沒有這麼簡單. 我再摸摸.
方向上是做一個switch?

[mattwang44]

根據 discord 討論的 method 1，現況是後端已經有 switch（也就是 registry 存的 f'{settings.CONFERENCE_DEFAULT_SLUG}.proposals.editable'），方向是讓前端能根據這個 switch 現在是開或關來控制下列其一（可能需要先討論要選擇哪個）：
a. 這個 form 上能夠調整共同講者狀態之按鈕的 disabled 與否
b. 這個 form 的顯示與否
c. 可能有其他做法？

[SivanYeh]

@mattwang44 I thought “request” can be one of parameters to switch the edit status and check if additional speaker is allowed to update/cancel the form during uneditable time.

...seems like “request” is not included in these two forms.
(Based on the par “request” came from “RequestUserValidationMixin”, which is not indcluded in “AdditionalSpeakerUpdateForm”.)

What is the key par should I consider?

[SivanYeh]

@mattwang44 跟GPT協作找到了一個方法是用RequestFactory來測試：
https://docs.djangoproject.com/en/5.0/topics/testing/advanced/
見commit54bf911