下面是網頁前端待改進的一些點

root 路由

前端一個添加一個 url.path=’/’ 時的路由處理，即當用戶只輸入了域名時的訪問路由處理，可以前端自動跳轉到 /broadcastManagement/ ，我本來計劃在後端直接使用 nginx/envoy 返回 301 進行跳轉，但發現很難處理，因爲系統沒有直接發佈到用戶訪問的地址，中間經過了多次內部跳轉導致端口號遺失，當最終的 nginx/envoy 收到請求時，它已經遺失了前端 url 中輸入的端口號，則在用戶通過非常規端口(80/443)時會導致後端跳轉到一個錯誤地址。

以測試網頁爲例，訪問地址是 https://xsd-kb2022-dev.cdnewstar.cn:3443，這會被發佈到我們公司的一個外部公開服務器，它等待請求後將此請求轉發到內部的測試機器 192.168.x.x:5000 端口，此時 192.168.x.x 上的 nginx/envoy 服務器並不知道用戶請求的 url 是 3443 端口而認爲是 5000 端口，它們將會 301 重定向到 http://xsd-kb2022-dev.cdnewstar.cn:5000/broadcastManagement (因爲最外層的公開服務器處理了 https 所以 192.168.x.x 甚至認爲用戶是通過 http 進行的訪問)。當然對於這裏的特定情況可以在 192.168.x.x 上寫死跳轉到 https://xsd-kb2022-dev.cdnewstar.cn:3443/broadcastManagement 但是當系統部署在不同客戶那裏時不同客戶的內部網路佈局是不同的，這將無法提供一個通用的自動化維護設定。

所以比較簡單的方案是，前端自己處理下路由 / 將其跳轉到 /broadcastManagement/ 或跳轉到其它自己的主入口點(index.html)

系統管理設置bug修復

在路徑 /broadcastManagement/system/roleManagement /broadcastManagement/system/levelManagement /broadcastManagement/system/priorityManagement 三個系統管理頁面(角色管理，等級管理，優先級管理)。點擊設置按鈕彈出對話框之後，設置完數據點擊設置數據按鈕在數據提交服務器後雖然成功但前端頁面會卡主，在瀏覽器調試頁面的 Console 窗口可以查看到未處理的異常信息

session 刷新bug修復

session 自動刷新存在bug導致只能刷新一次，前端似乎在 cookie 中使用了 Authorization 和 refreshToken 兩個屬性來記錄 accessToken 和 refreshToken，當成功刷新了 token 後沒有將新的 accessToken 和 refreshToken 記錄到這兩個屬性（會被記錄爲 undefine 應該是哪裏的存儲代碼有 bug），這導致下次 accessToken 過期後執行的自動刷新功能會失敗。

此外建議不要使用 cookie 記錄 Authorization/refreshToken 兩個屬性，因爲這有兩個問題

cookie 會被所有請求發送到服務器，然而這兩個屬性只是前端用於記錄自己的數據的，傳輸給服務器只會浪費寬帶流量
之所以要設計 accessToken/refreshToken 兩個 token 的好處是，通常訪問服務器時只發送 accessToken 並且有效期很短(通常10分鐘)。當 accessToken 被網路攔截而失竊時它很快就會失效，refreshToken 只在刷新時被網路傳送，它更難失竊或被破解。現在兩個數據都記錄到cookie 中每次都傳輸到服務器就失去了分開設計 accessToken 與 refreshToken 的安全價值

建議使用 localStorage 或者 IndexedDB 來存儲前端數據，特別是 localStorage 它很簡單你完全可以把它當作一個 Map<string,string> 來使用(實際上它就是一個持久化到磁盤並且與訪問域名端口綁定的Map)。如果前端考慮到安全還可以把數據加密後存儲。例如存儲三個 key 分別是 access,refresh,enc。 enc 作爲某種加密算法(例如 aes)的密鑰如果不存在就生成一個隨機值，然後在存儲和讀取 access/refresh 時使用這個密鑰和一個固定的鹽進行加密讀寫

修改昵稱bug修復

在修改昵稱後，用戶 session 不會失效，但前端卻在修改成功後丟棄了 session 導致用戶需要重新登入。

session 只在下述情況下會失效:

session 有效期到期
用戶密碼被修改 (用戶發現密碼被竊時，管理員或用戶自己可以通過修改密碼來讓所有 session 立刻失效，以到達將竊取的 session 踢下線的效果)
用戶權限被修改
用戶管轄區域被修改
用戶優先級被修改
用戶等級被修改

簡單來說除了 session 到期外，當設計到用戶能夠操作的權限與範圍發生改變時 session 才會失效。故昵稱的修改不會讓 session 失效

角色管理權限列表顯示

在 /broadcastManagement/system/roleManagement 頁面(角色管理)，點擊查看權限按鈕後顯示的權限信息不夠完整只顯示了組本身的權限，組可以從其它組派生，接口返回數據的 extends 屬性記錄了它從哪些組派生。一個子組是擁有父組的權限的，所以權限列表在顯示時應該爲每個組遞歸遍歷 extends 中記錄的組的權限並將它們顯示出來，並且最好顯示出這一權限來自哪一個組。這樣用戶就可以直觀的查看到每個組擁有的全部可操作權限而不是需要自己去計算派生了哪些權限

用戶管理頁面未分頁

用戶管理頁面 /broadcastManagement/system/useManagement，只能顯示前10條數據，當數據超過10條時應該支持分頁顯示

區域管理頁面bug修復與功能添加

區域管理頁面 /broadcastManagement/system/areaManagement，在先點擊修改按鈕後再點擊添加按鈕，這時添加不會請求服務器的添加接口而是請求服務器的修改接口。如果打開頁面直接點擊添加按鈕則會正常請求添加接口

此外這個頁面應該增加一個導入功能，讓用戶可以批量導入區域數據，因爲在創建系統時管理員需要添加大量的區域信息(少則十幾多則幾百上千)，如果要一個個添加既容易出錯也會給管理員帶來巨大負擔。單個的添加和修改通常只是在系統運行一段時間後管理員爲新的需求進行少量的添加與修改

區域樹在同一高度的節點目前似乎沒有排序，後端返回的結果是按數據庫 id 排序的，前端在顯示前應該爲它們按照邏輯碼排序一下再顯示到頁面，因爲通常管理員在創建區域時會按照區域鄰近位置去創建區域信息，例如相鄰的三個地方邏輯碼可能是 5101 5102 5103 ,有時數據庫的 id 順序和邏輯碼順序不會一致(例如先禁用了 5102 後來又重新添加了 5102)。按照邏輯碼排序後再顯示對用戶查看相關區域更友好

模糊查詢

涉及頁面:

/broadcastManagement/device/deviceManagement
/broadcastManagement/device/deviceControl
/broadcastManagement/system/useManagement
/broadcastManagement/task/createTask
/broadcastManagement/task/audioList
/broadcastManagement/task/toExamineAudio
/broadcastManagement/task/liveManagement
/broadcastManagement/task/audioLive
/broadcastManagement/task/timelyLive

一些查詢接口在查詢服務器時，通常可以傳入一個名稱，例如查詢用戶名音頻名任務名設備名，服務器接口直接使用了 like 查詢這樣的好處是同時可以滿足前端的模糊查詢和精確查詢，通常在不輸入 % 時(數據庫不同關鍵字可能不一樣，大部分開源數據庫都使用 % 做模糊匹配，我們後端使用 mariadb 數據庫也使用關鍵字 % 做模糊匹配)，like 會執行近似的精確查詢，但傳入 % 會進行模糊查詢。例如傳入 “成都” like 會查詢屬性等於 “成都” 的所有內容，而傳入 “成都%” 會查詢所有以 “成都” 爲前綴的數據，傳入 “%成都” 會查詢所有以 “成都” 爲後綴的數據，傳入 “%成都%” 會查詢所有包含 “成都” 兩字的數據。

一般用戶通常都是想執行模糊匹配，所以前端應該在查詢字符串不爲空白時爲它添加上 % 後再查詢服務器，例如用戶輸入 “xxx” 則將 “xxx%” 或者 “%xxx%” 傳遞給服務器。最好是在頁面給出一個勾選框(文本可以顯示前綴查詢)，如果用戶未勾選則將輸入的原本內容 “xxx” 傳給服務器，而當用戶勾選時將 “xxx%” 傳遞給服務器（也就是查詢前綴）。這樣可以依據用戶的需要而實現不同的查詢需求。

不要傳遞 “%xxx” 因爲在數據庫查詢中 “%xxx” 和 “%xxx%” 都無法使用索引，與其查詢 “%xxx” 不如查詢 “%xxx%” 更能滿足大部分客戶需求。而 “xxx%” 能夠滿足部分客戶需求並且可以使用數據庫的部分索引也是常用的方案。最好的方案是給出一個 select選擇讓用戶選擇要使用哪種查詢模式，然後前端依據用戶不同選擇爲用戶輸入的關鍵字在合適的位置加上 % 後再傳遞給後端

設備查詢

在設備管理的頁面應該添加兩個查詢條件

應該讓用戶可以是選擇查詢被禁用的設備/啓用的設備/全部設備，默認查詢啓用的設備，因爲大部分時間用戶都關心的是啓用的設備以便對它們進行規劃管理，但可能需要查詢被禁用的設備以便查看一些歷史數據
應該讓用戶可以選擇查詢未連接/已連接/全部設備，默認查詢已連接的設備，因爲大部分時間用戶都關心的是已連接的設備以便對它們進行規劃管理，但有時需要查詢未連接的設備來找到硬件出問題的設備(硬件壞了自然就不會連接到服務器所以會在未連接狀態)

添加設備bug修復

目前點擊添加設備，最終調用的是服務器添加區域的接口 /broadcastManagement/device/deviceManagement

此外應該提供一個導入設備的功能，因爲在系統初創時，管理員會創建大量的設備(少則幾十個多則幾百幾千個)，一個個的添加既容易出錯也會對管理員造成巨大負擔。單個的添加只在系統運行後期偶爾出現的設備壞掉更換之類的情況下會被使用

設備管控bug修復

設備管控頁面的操作菜單存在多個 bug /broadcastManagement/device/deviceControl

一個彈出窗口的錯誤信息會一直保留顯示到其它的窗口，例如先打開服務器地址窗口輸入錯誤地址引發錯誤提示文本顯示，之後打開其它窗口在這些窗口中依然會顯示服務器地址窗口中出現的錯誤提示
升級窗口的輸入框和服務器地址窗口似乎是同一個輸入框，在其中一個輸入框中輸入的內容會在另外一個輸入框中保留，這顯然不太合理，比如在升級輸入框中輸入一個常用的版本號 v1.2.3，打開服務器地址窗口輸入框會顯示已經輸入了 v1.2.3 而此時需要的是一個域名:端口或 ip:端口形式的字符串
無法發送休眠指令因爲服務器要求的參數是一個 number 的秒數，前端直接將輸入框中的字符串傳遞給了服務器導致服務器驗證參數發生錯誤
服務器地址窗口前端驗證格式似乎存在bug，正確的 host:port 形式的地址無法通過前端驗證導致無法向後端提交請求
對講參數，和休眠指令類似後端要求的是 number 數據(uint32 的頻率和 float32 的亞音)。前端直接將 type=’text’ 的輸入框字符串數據傳遞給了後端導致後端驗證數據發生錯誤
在操作記錄中應該顯示出服務器返回的 parameters 參數，這樣管理員才能知道這個設備被設置成了什麼樣子，比如對於對講開關指令用戶需要知道它到底是執行的打開還是關閉，對於調整音量指令用戶需要知道音量被設置爲了多少，最簡單可行的方案就是將 parameters 值顯示給用戶查看
在操作記錄中不應該直接顯示用戶 id 和設備 id，因爲用戶對無意義的id是難以理解的，前端應該自動爲未知的 id 查詢到對應的用戶名和設備名之類的信息顯示。並且對於單頁面網頁應該創建一個緩存來緩存 id 與用戶名/設備名的關係 Map<string,any>。首先在緩存中查找顯示信息只在緩存中不存在時再查找服務器數據，因爲很多頁面都會共用這些顯示信息，全部查詢服務器會對服務器造成巨大的壓力

此外在此頁面打開的設備操作記錄沒有分頁，當數據超過10行時雖然創建了分頁 nav 但單擊 nav 標籤沒有顯示新頁的數據，另外最好使用 limt.desc 參數倒序顯示數據

回傳與調度器

應該在設備管理中再添加一個頁面來顯示回傳與調度其信息。

每個設備都有一個與之綁定(模擬器id 和設備 id 一樣)的模擬器,通過查詢模擬器數據可以知道四組非常有用的信息

設備什麼時候連接到服務器，已經連接了多久，如果斷線是什麼時候斷線的最後連接時間是什麼時候。這在設備硬件故障時可以很好的用於評估它壞的時間
設備回傳給服務器的自己當前的一些數據狀態，可以用於讓管理員知道設備目前處於什麼狀態。(比如安裝的軟件版本，是否打開某些功能，音量設置的是多少)
調度器id，依據此值可以進一步查詢到設備被調度的詳細情況，在幾點開始播放了什麼內容，在幾點停止播放，在調度過程中出現了什麼異常。（把調度即器日誌顯示給用戶即可，這些信息存儲在調度器日誌中）
當前是否在播放音頻(調度器id非0時有任務在播放)，如果在播放它播放的來自哪中任務哪個房間的音頻，這個音頻是來自哪個任務

名稱與時間查詢

在任務管理中，應該支持以任務名稱查詢數據

/broadcastManagement/task/timelyLive
/broadcastManagement/task/audioLive
/broadcastManagement/task/createTask
/broadcastManagement/task/toExamineTask

在任務和資產管理中，應該支持指定查詢日期，因爲用戶有可能需要查詢特定時間段創建的任務或音頻

/broadcastManagement/task/timelyLive
/broadcastManagement/task/audioLive
/broadcastManagement/task/createTask
/broadcastManagement/task/toExamineTask
/broadcastManagement/task/audioList
/broadcastManagement/task/toExamineAudio

任務與資產顯示完整信息

在任務和音頻資產的列表中只顯示了部分關鍵信息，應該給出一個按鈕點擊後顯示完整的信息。因爲這些信息在涉及到追責時是必不可少的。例如有人上傳了一個違法音頻，需要知道是誰在什麼時候上傳的，而如果這個音頻被審覈通過了也需要知道是誰在什麼時候爲它通過的。任務的完整信息也是處於類似目的

此外服務器通常只返回了相關用戶的 uid，前端應該使用這個 user id 去查詢用戶的信息爲用戶顯示用戶名/昵稱之類更加友好的信息，以方便用戶查看。同時作爲單頁面web應該爲這些顯示信息創建一個緩存，只在緩存不存在時才查詢服務器信息以避免頻繁查詢這些重複的信息對服務器造成巨大的壓力

查詢自己的任務與資產

在查詢任務和音頻資產的相關頁面中應該給出一個 checkbox 之類的東西當用戶勾選時就只查詢他/她/它自己上傳的音頻或創建的任務。因爲對於大部分普通用戶通常只關心自己創建的任務和上傳的音頻(少數情況也會用別人上傳的音頻)。而管理員們則要關心所有人的任務與音頻。

草稿應該單獨顯示

處於草稿狀態的音頻和任務應該在單獨的頁面顯示並且只爲用戶顯示它自己的草稿，因爲處於草稿狀態的音頻和任務除了創建人自己，任何人都無法進行任何操作(即使超級管理員也無權)，並且通常用戶也不會去關心別人的草稿。

在草稿顯示頁面之外的任何地方都不應該再顯示草稿(其它地方的任何查詢都應該爲服務器接口傳入參數，來去除掉草稿內容)

不過我看來下現在的音頻管理頁面 /broadcastManagement/task/audioList 也可以用這個頁面的邏輯來處理但要稍加修改。音頻管理頁面只顯示自己音頻（相當於又可以顯示草稿又可以顯示其它但都是自己的內容），因爲都是自己的內容，所以可以在此處理草稿(刪除繼續上傳重新提交之類)。(這個頁面顯示別人的東西又無法操作沒有意義)。然後在音頻審覈裏面顯示所有人的音頻(最好是除草稿之外的就是目前頁面的狀態)。類似的需要一個流程管理頁面只顯示自己的流程任務，並可以對自己的流程任務進行處理(刪除重新提交之類)。

流程任務審覈時沒有詳細信息

流程任務在審覈時，審覈人員必須知道任務包含的詳細信息，否則無法評估任務是否合法 /broadcastManagement/task/toExamineTask。至少需要知道任務在什麼時間要播放什麼內容哪些設備或地區要進行播放

創建流程任務bug修復

在創建流程任務時 /broadcastManagement/task/createTask，添加音頻按鈕被點擊後就應該直接彈出音頻選擇對話框而不是要在點擊一下圖標按鈕才顯示對話框這多出的一個點擊沒有任何意義(因爲也無法做出點擊它之外的任何操作)。而且目前在沒有點擊圖標按鈕選擇音頻前會直接把空白字符串 “” 作爲音頻id傳給服務器導致服務器驗證參數出錯。

此外在添加音頻後應該顯示音頻名稱而非音頻id 這樣更友好。

在彈出的音頻選擇框中，應該爲音頻提供一個試聽按鈕，用 a 標籤供用戶在此處試聽下音頻內容是否是自己想要的。否則還要去音頻審覈裏面才能聽到音頻內容，很不友好。例如有三首國慶節要播放的音頻分別是國慶音頻1，國慶音頻2，國慶音頻3 用戶可能已經忘記了具體內容，此時如果可以在音頻選擇頁面就直接聽下內容將會是比較友好的ui界面

任務調度歷史

所有任務在執行時都會創建一個調度器，並且會爲調度器記錄詳細的調度日誌。應該提供頁面來查詢這些歷史，它對追責等起到關鍵作用，例如有人發現某天的廣播播放了非法內容，必須依據調度歷史來查看到達有哪些地方都受到了波及。並且當時出現問題的音頻到達來自哪裏。

此外如果某天應該播放的內容沒有播放，也可以依據調度歷史來排查到達是服務器還是設備出現了故障。基本上調度歷史是給專業人員看的，裏面記錄了繁雜的日誌信息，通常頁面只需要讓管理員能夠把它們查詢並顯示到網頁上即可

直播歷史

直播任務都會在服務器存儲一份直播的音頻備份歷史（一個 mp3 檔案，通常會保留1到3個月），在查詢到的直播類任務列表裏面，應該爲直播完成的任務提供一個按鈕可以收聽這些音頻。這才出現非法的播放問題時可以重新收聽以確認之前直播播放的內容。

前端可以使用 a 標籤和 DOWNLOAD 接口來播放它們

倒序查詢

目前各個列表頁面的查詢結果是按照服務器默認順序查詢的，默認採用的按照插入順序返回結果，即先插入的數據顯示在前，後插入的數據顯示在後。但大部分列表信息用戶比較關心的是後插入的數據，例如通常用戶想查找到最近兩天創建的任務，而不是一兩年前創建的任務。

所有 find 查詢接口都支持一個 limit.desc 參數，將它設置爲 true 服務器就會倒序返回結果，即先顯示後插入的數據，後顯示先插入的數據。

前端應該默認以 limit.desc=true 爲用戶返回列表數據，另外最好能夠提供一個 checkbox 之類的勾選框當用戶勾選時就不設置 limit.desc(即讓用戶可以選擇要以正序還是倒序查詢數據)。

統計頁面

統計頁面，將已經定位的終端添加到地圖上(畫一個圖標)，可以點擊圖標顯示終端的信息(名稱，物理碼，邏輯碼，是否在線，上線時間，掉線時間等)。點擊區域後，地圖定位到區域，並爲區域顯示設備在線率(這個區域下有多少設備在線，多少設備離線)

在這個頁面添加一個返回首頁的導航按鈕或圖標(進入這個頁面後沒有辦法返回到其它頁面，一些用戶不習慣或不知道按瀏覽器返回按鈕)

網頁前端待改進地方