勤怠管理システムの自作-役割情報編集画面

概要

勤怠管理システムの各機能へのアクセス権限と、月報の承認順位をまとめて管理する機能です。

本来は別々に管理すべきものだと思いますが、ほぼ同じテーブルや画面を2つ作るのを避けるために混ぜてしまいました。

勤怠管理システム内部において、アクセス権を管理するためのデータです。
DB内に初期データとして投入しており、ユーザーが操作することはできません。
承認レベルを0として定義することで、月報承認処理では無視されるようにしています。

当システムのアクセス権限の考え方は・・
システム内に固定で定義された権限があり、権限ごとにアクセスできる機能が決まっています。各ユーザーに対して権限データを紐付けることで、アクセス制御を行います。

アクセス制御はASP.NET Identityのロールを使って実現しています。予約済みデータはロールIDそのまんまです。
ソースコードに直接ロールIDを書いているため、動的に変更できなくなりました。

/// <summary>
/// 役割マスタ
/// </summary>
[Authorize(Roles = "admin")]
public class RoleMaintenanceController : Controller
{
}

予約済みデータの種類と意味

ロールID	効果
admin	マスタメンテ系の画面にアクセスできます。契約情報や年間カレンダーの編集に必要です。
privacy	ユーザーマスタメンテ画面にアクセスできます。 adminの権限を持たせたうえで、さらにこの権限を紐付ける必要があります。ユーザーマスタには労働者名簿と同等の情報(住所など)が保存されているため、他の権限とは分けてあります。
approver	月報承認機能にアクセスできます。
accounting	月報締め処理にアクセスできます。
users	これはアクセス権限とは関係なく、月報承認レベルに関わるデータです。全てのユーザーにこの権限を付与します。各労働者が月報を作って申請を行った場合、内部的には月報をレベル1で承認したことになります。レベル1をシステム側で占有することで、月報の申請/承認を簡単に見分けられるようにしています。

1～99の数値です。承認レベルが高いほど役職が高くなるイメージです。
レベル1は月報を作った本人による申請の意味を持つため、実際には2～99の数値を役職に割り当てていきます。

役割データはシステム内全体で共用します。事業場によって承認者の階層数が異なる場合があるため、事業場ごとに使用する役割のON/OFFを切り替えられます。

ひとつの承認レベルで複数のユーザーが承認を行うことはできません。
ひとつの押印欄に複数のハンコを押すような運用は再現できなくなります。厳密に承認レベル(押印欄)を分ける必要があります。

役割ID、役割名、承認レベル、それぞれの項目単位で他のデータとの重複を禁止。
予約済みデータとの重複も禁止。
ただし、承認レベル0は重複可能。

システム日時時点で在職中のユーザーと紐付いている役割データは削除不可。

運用開始直後に設定して、それ以降は書き換えられることがない想定です。
データを削除した場合、月報の承認データをうまく表示できなくなります。
月報を承認した時点で役割マスタとは切り離すような設計にするべきでした。