今天下班後，星樓提出了乙個想法，想構架乙個調崗的審批流程，然後我們和廣龍一起**了這個問題，就是關於員工調崗有什麼更簡單的審批流程。
問題來了：員工1本來在a部門，現在要調到b部門，需要兩個部門的領導審批，a部門的領導可以設定角色，自動識別發起人所在部門領導審批，b部門領導怎麼自動識別呢
針對這個問題，我們開始利用目前掌握的一些淺顯的釘釘使用經驗開始了苦思冥想：
第一種：開始的時候，我計畫是用角色來控制接收部門的審批人，但是我經過在電腦測試後，發現不可取，角色即使劃分了職責範圍，但是這個範圍是圍繞著發起人進行判定的，第乙個提議被否決了（設定後，只要發起人不變，那麼接收單位的負責人無論接收部門如何變化始終不變）
第二種方式：繼續**其他的方法，這時候我們也是想到了乙個沒有辦法的辦法，條件判定，根據接收部門的不同，來設定不同的接收人，就是設定要麻煩些，但是後期用著可能會方便很多；
測試一下唄（其實也無需測試了，大家都能想到是可以成功的）
給大家看一下，我使用這個方式設定的乙個審批流
此流程雖然複雜，設定起來比較麻煩，但是有乙個優點就是基本不會出錯，差錯率很少，而且不會出現因部門之間領導關係出現不融洽的情況！對於調崗這個問題也能夠完美的解決，這個流程咱們姑且算是乙個一號優質備胎，隨時準備扶正！那麼還有沒有更好點的辦法呢，讓流程設定能夠再簡單一些呢？
反正又備胎了，開始天馬行空的思考起來，於是又乙個審批流程面世：
第三種審批流設定方式：
這個方式是通過在表單內，新增加了乙個接收部門負責人的控制項，而且這個控制項還只能由第一審批人進行填寫（必填專案），填寫好之後，才可以進行同意或者是拒絕的操作，否則無法進行操作！
話不多說，看一下我根據這個想法設定的最終流程是什麼樣子的，是不是非常的簡單了呢？
一共只有五個節點，第一和第三節點為傳送節點，便於傳送人對審批流程的填寫進行監督，第二節點為發起人的直接主管，直接主管在表單內填寫接收部門的負責人，然後轉到下一審批人（即直接主管填寫的人員），接收主管同意後，由最後一步人事負責人進行核實，如不合規，可以直接打回到出錯誤的任意審批人處，進行重新走流程！大家可以按這個思路在手機演示一下
本帖子的寫作由來感謝星樓 感謝廣龍
後記：
今天上班後，立新 提出了乙個建議，就是說每個公司制度是不同的，很多公司可能直接就是人事與領導都協調好，直接就可以簡化這個步驟了！確實是這樣的，因為畢竟每個公司的制度不同，都需要根據公司的制度和要求來改動調整的！
Kafka訊息重新傳送
kafka訊息重新傳送 1 使用kafka訊息佇列做訊息的發布 訂閱，如果consumer端消費出問題，導致資料並沒有消費，此時不需要擔心，資料並不會立刻丟失，kafka會把資料在伺服器的磁碟上預設儲存7天，或者自己指定有兩種方式 1 指定時間，log.retention.hours 168 2 指...
重新發現大型機
全球業務環境既多種多樣又靈活多變，受到客戶需求 監管和社會政治問題的影響。每年，ibm 都在全球範圍面向1400多名企業管理者展開年度調查，什麼是當今世界所面臨的重要問題。在2005年，人們認為收入上限是首要問題，然後是贏利能力以及成本控制。接受調查的管理者表示，為了解決上述問題，主要需要做到改善業...
testng失敗重新執行
testng重新執行失敗的用例 有時，可能希望testng在失敗時自動重試測試。在這些情況下，可以使用iretryanalyzer。將retryanalyzer 繫結到測試時，testng會自動呼叫retryanalyzer以確定testng是否可以再次retry測試用例，以嘗試檢視現在失敗的測試是...