액션 정의와 실행 권한

액션 유형(Action type)의 정의를 보거나 편집하는 권한, 특정 입력으로 액션(Action)을 실행하는 권한은 서로 다릅니다. 정의를 프로젝트(Project)에 저장한 경우에는 프로젝트 권한을 관리하고, 기존 구형 권한 모델은 해당 온톨로지 역할을 따릅니다.

실행 조건

제출자는 편집 대상 객체 유형(Object type), 링크 유형(Link type)과 해당 데이터소스(Datasource)를 볼 수 있어야 하고 액션 제출 조건(Submission criteria)도 통과해야 합니다. 실행자나 그룹 ID를 입력 조건과 결합하여 업무별 실행 범위를 제한할 수 있습니다.

작업 공간(Workspace) 사이드바의 Check access에서는 Workshop 모듈과 의존하는 액션 및 제출 조건에 대한 사용자 접근을 함께 확인할 수 있습니다.

편집 경로와 필요한 데이터 권한

새 객체 유형은 기본적으로 Only allow edits via actions를 사용합니다. 이 방식에서는 제출자가 편집할 객체에 Read 권한을 가지면 액션의 규칙과 제출 조건에 따라 변경할 수 있습니다. 생성한 결과의 보안이 달라지면 사용자가 자신이 만든 객체를 볼 수 없는 경우도 있습니다.

직접 편집, Foundry Forms와 직접 편집 API도 허용하는 구형 데이터셋 기반 경로는 편집 대상의 쓰기 반영 데이터셋(Writeback dataset)에 Edit 권한이 필요합니다. 이 권한은 그 데이터셋의 전체 데이터를 볼 수 있게 하므로 객체 편집만을 위해 넓게 부여하지 않는 것이 좋습니다. 제한 뷰(Restricted view) 기반 경로는 해당 편집 정책을 통과해야 합니다.

액션 설정 화면이 대상 객체 유형의 모든 권한을 대신 보여 주지는 않습니다. 구성자는 해당 권한을 별도로 확인합니다. Only allow edits via actions로 바꾸어도 과거 비액션 편집은 지우지 않지만 이후 Forms, Object Explorer 직접 편집과 직접 편집 API를 통한 변경은 막습니다. 액션 적용 API와 직접 편집 API를 구분합니다.

읽기 제어와 쓰기 보호

행과 열 접근 제어, 제한 뷰, 객체 보안 정책과 속성 보안 정책은 액션 실행 중 사용자가 읽는 값을 제한합니다. 이 읽기 필터가 결과 쓰기에 자동으로 같은 보호를 적용하는 것은 아닙니다.

하위 결과에도 보안이 유지되어야 한다면 보안 표지(Marking)나 보안 분류 기반 접근 제어(CBAC)를 함께 구성합니다. 읽기 및 쓰기 권한 경계는 입력의 보안 상한과 결과의 최소 보안을 추가로 검사하며 기존 사용자 권한이나 제출 조건을 대신하지 않습니다.

액션 로그 권한

액션 로그(Action log)를 구성했다면 제출자는 로그 객체 유형에 필요한 권한도 가져야 합니다. 다른 생성 및 수정 대상 유형과 같은 원칙이며 권한이 없으면 액션 제출에 실패합니다.

부수 효과

액션을 설정할 수 있는 사용자는 부수 효과(Side effect)도 구성할 수 있습니다. 웹훅은 기본 활성 기능이 아니며 Data Connection에서 웹훅 플러그인을 준비할 추가 권한이 필요합니다.

제출 조건에 실패하면 부수 효과를 실행하지 않습니다. 알림 수신자는 내용에 포함된 모든 객체 데이터에 접근할 수 있어야 합니다. 기본 설정인 Require all users to have permissions에서는 수신자 한 명이라도 필요한 권한이 없으면 액션이 실패하며 편집과 알림을 모두 적용하지 않습니다. Require any user to have permissions를 선택하면 권한이 있는 수신자가 한 명 이상일 때 액션이 성공하고, 권한이 있는 사람에게만 알림을 보냅니다.

실행자도 알림을 받을 사용자나 그룹을 볼 수 있어야 합니다. 제출 전 수신자 권한 검사와 커밋 후 알림 전송은 구분합니다. 전송 실패가 이미 커밋한 온톨로지 편집을 되돌리는 것은 아니며, 트랜잭션 범위를 따릅니다.