Rails의 관리 트리 HRM

Question

저는 조직의 인적 자원 관리 시스템을 개발하고 기본 인프라를 만들었습니다. 지금 관리자 권한을 생성해야하는 시점에 이르렀습니다. 내 조직은 나무 구조가 너무 많아서 내가 쥐고있는 것으로부터 능동적 인 Admin과 같은 Admin 젬에서 쉽게하고 싶지는 않다. 아래의 각 레벨에 대해 parent_id 필드를 사용하는 것을 고려했지만 어떻게 응용 프로그램에서이를 용이하게 할 지 확신하지 못합니다.

사실상 최저 수준의 직원들이 개인 데이터의 대부분을 성능 보고서/메모 및 유사한 특성과 같은 몇 가지 클래스에서 제외하고 연락처 세부 정보와 같은 기본 세부 정보를 편집 할 수 있기를 바랍니다 최신 상태인지 확인하십시오. 그러면 해당 라인 관리자는 자신이 담당하는 직원의 세부 정보를 볼 수 있어야합니다. 조직을 확장 할 수는 있지만 조직에는 약 4 개의 계층이 있습니다. 두 번째 및 세 번째 계층에는 여러 줄 관리자가 있습니다. 저는 보석의 문제가 발생하는 곳이라고 생각합니다.

나는 이것이 딜레마를 푸는 열쇠가 될 것이라고 생각했지만 누군가가 밝은 아이디어를 가지고 있는지 궁금해하기 때문에이 작품을 설치했습니다. 내 현재 employee.rb 파일이 아래에 있습니다. 여기에서 어디로 가야할지 확실하지 않습니다.

class EmployeesController < ApplicationController 
    before_action :set_employee, only: [:show, :edit, :update, :destroy] 
    before_action :logged_in_employee, only: [:index, :show, :edit, :update, :destroy] 
    before_action :correct_employee, only: [:show, :edit, :update] 
    before_action :admin_employee,  only: :destroy 

    # GET /employees 
    # GET /employees.json 
    def index 
    @employees = Employee.paginate(page: params[:page]) 
    end 

    # GET /employees/1 
    # GET /employees/1.json 
    def show 
    end 

    # GET /employees/new 
    def new 
    @s3_direct_post = S3_BUCKET.presigned_post(key: "uploads/#{SecureRandom.uuid}/${filename}", success_action_status: 201, acl: :public_read) 
    @employee = Employee.new 
    end 

    # GET /employees/1/edit 
    def edit 
    @employee = Employee.find(params[:id]) 
    end 

    # POST /employees 
    # POST /employees.json 
    def create 
    @employee = Employee.new(employee_params) 
    if @employee.save 
     @employee.send_activation_email 
     flash[:info] = "Please check your email to activate your account." 
     redirect_to root_url 
    else 
     render 'new' 
    end 
    end 

    # PATCH/PUT /employees/1 
    # PATCH/PUT /employees/1.json 
    def update 
    respond_to do |format| 
     if @employee.update(employee_params) 
     flash[:success] = "Profile updated" 
     format.html { redirect_to @employee, notice: 'Employee was successfully updated.' } 
     format.json { render :show, status: :ok, location: @employee } 
     else 
     format.html { render :edit } 
     format.json { render json: @employee.errors, status: :unprocessable_entity } 
     end 
    end 
    end 

    # DELETE /employees/1 
    # DELETE /employees/1.json 
    def destroy 
    Employee.find(params[:id]).destroy 
    flash[:success] = "Employee deleted" 
    respond_to do |format| 
     format.html { redirect_to employees_url, notice: 'Employee was successfully destroyed.' } 
     format.json { head :no_content } 
    end 
    end 

    private 
    # Use callbacks to share common setup or constraints between actions. 
    def set_employee 
     @employee = Employee.find(params[:id]) 
    end 

     # Confirms a logged-in user. 
    def logged_in_employee 
     unless logged_in? 
     store_location 
     flash[:danger] = "Please log in." 
     redirect_to login_url 
     end 
end 

    # Confirms the correct user. 
def correct_employee 
    @employee = Employee.find(params[:id]) 
    redirect_to(root_url) unless current_employee?(@employee) 
end 

    # Confirms an admin user. 
def admin_employee 
    redirect_to(root_url) unless current_employee.admin? 
end 

# Never trust parameters from the scary internet, only allow the white list through. 
def employee_params 
    params.require(:employee).permit(:avatar, :email, :first_name, :last_name, :service_no, :password, :date_of_birth, :gender, :service_start_date, :substantive_rank, :promotion_date, :passport_number, :passport_expiry, :passport_country_of_origin, :nationality, :national_insurance) 
end 
end 

Answer 1

는 ActiveAdmin을에서 인증이 발생 할 때 access a resource (또는 collection). 기본적으로 요청을 승인하는 데 사용할 수있는 작업 이름에 따라 액션 이름 (예 : index, show, edit, update 등)과 모델 개체 또는 클래스를 사용합니다. 구성하지 않고 ActiveAdmin은 인증 솔루션을 제공하지 않습니다. 아무것도 구성하지 않으면 모든 사용자가 아무 것도 할 수 없게됩니다.

ActiveAdmin의 인증 방법은 cancan gem (또는 그 후계자 인 cancancan gem)과 잘 맞지만, Pundit은 기본적으로 지원됩니다. 자신의 어댑터를 롤링하는 것은 꽤 쉽습니다. 약간의 노력으로 모든 보석을 사용할 수 있습니다. 특정 문제에 대한

: 직원과 어떻게 인증을 사이

관계는 반드시 서로 영향을 할 필요가 없습니다. 역할 기반 접근법은 문제를 잘 처리하는 것으로 보입니다. 예를 들어, 당신은 다른 계층 구조 수준에 대한 역할을 만들 수 있습니다 :

• 직원
• 보스 라인 매니저
• 관리자의 (수퍼 유저가 아무것도 할 수있다) (낮은 수준)
• 라인 관리자

사용자가 여러 역할을 가질 수 있거나 역할이 포괄적 일 수 있습니다 (라인 관리자는 직원이 수행 할 수있는 모든 작업을 수행 할 수 있음). 내가 아는 바로는 후자는 문제에 더 잘 맞습니다.

구체적으로 사용자의 연락처 정보를 업데이트하려는 경우 (사용자가 아닌 경우) 사용자의 역할이 업데이트 작업을 허용하고 현재 사용자가 다른 사용자 개체에 액세스 할 수 있는지 확인해야합니다. 직원의 경우 자신이되어야하지만 라인 관리자는 부하 직원의 연락처 정보도 업데이트 할 수 있습니다.

대부분의 권한 부여 라이브러리는 서로 다른 역할이 수행 할 수있는 것을 표현하는 선언적 방법을 제공합니다. 나는 칸칸칸 젬을 살펴 보길 권한다.