管理者機能について
管理者機能について
こんにちわ、サーバーサイドエンジニアの師匠です。
6月25日に10回目のDevMeetupが行われ、そちらで権限というテーマを元に、LTさせて頂いたのでその内容についてブログを書きます。
管理者機能というのは自分がiCAREに入社して、今年の1-3月頃に開発していた新機能で、無事に現在リリースされ使われています。
どんな機能？
機能としては登録グループを跨いで、Carely上の従業員データのアップロードやダウンロード、残業時間データのアップロードがバックグラウンド処理で出来るという機能です。
登録グループとは？
企業の組織図の１階層目を表すもの。他の登録グループに個人情報を見せないために権限としてカラムがある。
問題点
閲覧や操作の制限を入れるために登録グループが設けられており、登録グループごとにしか、色々な操作ができなかった。また、企業によっては、登録グループが100を超えてしまうため、同じ操作を登録グループごとに繰り返す必要がある。さらに、企業によっては複数の登録グループであったり、全社の閲覧の権限を持っている人事や産業医の方がおり、その場合は逆に登録グループで分かれて操作制限がかかると不便になる。なので、登録グループを跨いで操作できる機能の管理者機能を開発することになった。
実際の実装と工夫
権限
既存の権限は従業員・産業医・人事・実施実務従事者と後ろ３つの組み合わせの権限があり、それがCustomersTBにenumとして保存されていたが、管理者権限は独立させるため、それとは別に判定のカラムを設けることにした。
データ処理
権限とは関係ないが、今までは登録グループで絞られた一部の従業員の処理しかしていなかったが、全社のデータを一気に処理するため、大量のデータを処理する工夫が必要になった。
具体的にはバルクインサートやバックグラウンド処理化で対応した。
登録グループの異動
登録グループの異動は今まではエンジニアがスクリプトで行っていたが、それも管理者機能のCSVアップロードでできるようにした。
アソシエーションが組まれているカラムに関しては、find_or_initialize_byというメソッドで、一気に処理できるようにした。
終わりに
サービスには、権限によって処理を分けるというのが必須になる。権限は情報の閲覧を制限したり、登録や削除などの処理を制限したりすることに使われるため、どんなサービスでも大抵導入されている。
今回開発した機能では、設計からそういった部分の実装まで非常に勉強になりました。
