diff --git a/confluence-mdx/bin/reverse_sync/patch_builder.py b/confluence-mdx/bin/reverse_sync/patch_builder.py index 5513e4f08..29444b1ad 100644 --- a/confluence-mdx/bin/reverse_sync/patch_builder.py +++ b/confluence-mdx/bin/reverse_sync/patch_builder.py @@ -1,4 +1,5 @@ """패치 빌더 — MDX diff 변경과 XHTML 매핑을 결합하여 XHTML 패치를 생성.""" +import difflib import re from typing import Any, Dict, List, Optional @@ -10,7 +11,6 @@ from text_utils import ( normalize_mdx_to_plain, collapse_ws, ) -from reverse_sync.text_transfer import transfer_text_changes from reverse_sync.sidecar import ( RoundtripSidecar, SidecarBlock, @@ -225,29 +225,74 @@ def _mapping_block_family(mapping: BlockMapping) -> str: return _xpath_block_family(mapping.xhtml_xpath) -def _accumulate_text_change( - patches: List[Dict], - registry: Dict[str, Dict], - mapping: 'BlockMapping', - old_plain: str, - new_plain: str, -) -> None: - """같은 block_id에 대한 text-level 변경을 하나의 patch dict에 순차 누적한다. - patches 리스트에 추가된 dict의 참조를 registry에 저장하여, - 동일 block_id의 후속 변경이 같은 dict의 new_plain_text를 갱신하도록 한다. + +def _apply_mdx_diff_to_xhtml( + old_mdx_plain: str, + new_mdx_plain: str, + xhtml_plain: str, +) -> str: + """MDX old→new diff를 XHTML plain text에 적용한다. + + MDX old와 XHTML text의 문자 정렬(alignment)을 구축하고, + MDX old→new 변경의 위치를 XHTML 상의 위치로 매핑하여 적용한다. + 이를 통해 XHTML의 공백 구조를 보존하면서 콘텐츠만 업데이트한다. + (text_transfer.transfer_text_changes의 인라인 구현) """ - bid = mapping.block_id - if bid not in registry: - patch_entry: Dict[str, Any] = { - 'xhtml_xpath': mapping.xhtml_xpath, - 'old_plain_text': mapping.xhtml_plain_text, - 'new_plain_text': mapping.xhtml_plain_text, - } - patches.append(patch_entry) - registry[bid] = patch_entry - registry[bid]['new_plain_text'] = transfer_text_changes( - old_plain, new_plain, registry[bid]['new_plain_text']) + # 1. MDX old ↔ XHTML text 문자 정렬 (비공백 우선 → 공백 gap 채우기) + src_ns = [(i, c) for i, c in enumerate(old_mdx_plain) if not c.isspace()] + tgt_ns = [(i, c) for i, c in enumerate(xhtml_plain) if not c.isspace()] + sm = difflib.SequenceMatcher( + None, ''.join(c for _, c in src_ns), ''.join(c for _, c in tgt_ns), autojunk=False) + char_map: Dict[int, int] = {} + for tag, i1, i2, j1, j2 in sm.get_opcodes(): + if tag == 'equal': + for k in range(i2 - i1): + char_map[src_ns[i1 + k][0]] = tgt_ns[j1 + k][0] + # 인접 앵커 사이의 공백 매핑 + anchors = sorted(char_map.items()) + bounds = [(-1, -1)] + anchors + [(len(old_mdx_plain), len(xhtml_plain))] + for idx in range(len(bounds) - 1): + s_lo, t_lo = bounds[idx] + s_hi, t_hi = bounds[idx + 1] + s_sp = [j for j in range(s_lo + 1, s_hi) if old_mdx_plain[j].isspace()] + t_sp = [j for j in range(t_lo + 1, t_hi) if xhtml_plain[j].isspace()] + for s, t in zip(s_sp, t_sp): + char_map[s] = t + + # 2. MDX old → new 변경 추출 + matcher = difflib.SequenceMatcher(None, old_mdx_plain, new_mdx_plain, autojunk=False) + + # 3. 변경을 XHTML 위치로 매핑 + edits = [] + for tag, i1, i2, j1, j2 in matcher.get_opcodes(): + if tag == 'equal': + continue + replacement = new_mdx_plain[j1:j2] if tag != 'delete' else '' + if tag in ('replace', 'delete'): + mapped = sorted(char_map[k] for k in range(i1, i2) if k in char_map) + if not mapped: + continue + edits.append((mapped[0], mapped[-1] + 1, replacement)) + elif tag == 'insert': + # 삽입 위치: 앞쪽에서 마지막 매핑된 문자 + 1 + xpos = 0 + for k in range(i1 - 1, -1, -1): + if k in char_map: + xpos = char_map[k] + 1 + break + else: + for k in range(i1, max(char_map) + 1) if char_map else []: + if k in char_map: + xpos = char_map[k] + break + edits.append((xpos, xpos, replacement)) + + # 4. 역순 적용 + chars = list(xhtml_plain) + for xstart, xend, repl in reversed(edits): + chars[xstart:xend] = list(repl) + return ''.join(chars) def _find_best_list_mapping_by_text( @@ -414,9 +459,7 @@ def _mark_used(block_id: str, m: BlockMapping): _mark_used(mapping.block_id, mapping) continue # paired delete+add이지만 clean/table fragment 교체 불가: - # anchor 재구성이 필요한 경우만 replace_fragment로 전환 - # (clean container sidecar는 emit_block이 Confluence inline markup을 재현할 수 없으므로 - # transfer_text_changes fallback으로 보존해야 한다) + # anchor 재구성, preserved anchor, parameter-bearing container, clean container 순으로 분기 sidecar_block = xpath_to_sidecar_block.get(mapping.xhtml_xpath) if sidecar_block_requires_reconstruction(sidecar_block): patches.append( @@ -430,7 +473,7 @@ def _mark_used(block_id: str, m: BlockMapping): elif _contains_preserved_anchor_markup(mapping.xhtml_text) and not _is_container_sidecar(sidecar_block): # sidecar 없는 preserved anchor → rewrite_on_stored_template (구조 보존) # container sidecar가 있으면 rewrite_on_stored_template이 를 - # 오염시키므로 아래 transfer_text_changes fallback으로 보낸다 + # 오염시키므로 아래 분기로 보낸다 new_plain = normalize_mdx_to_plain( add_change.new_block.content, add_change.new_block.type) preserved = rewrite_on_stored_template(mapping.xhtml_text, new_plain) @@ -445,7 +488,8 @@ def _mark_used(block_id: str, m: BlockMapping): elif _is_container_sidecar(sidecar_block) and '을 'paragraph'로 파싱하므로 - # content 기반으로 full container 여부를 판별한다 - # TODO(Phase 5): sidecar의 reconstruction.kind == 'container' 활용으로 전환 - _s = change.new_block.content.lstrip() - is_full_container = _s.startswith(' 등)을 - # 재현할 수 없으므로 transfer_text_changes로 원본 XHTML 구조를 보존한다 - _accumulate_text_change( - patches, _text_change_patches, mapping, old_plain, new_plain) + ) continue # strategy == 'direct' diff --git a/confluence-mdx/tests/reverse-sync/pages.yaml b/confluence-mdx/tests/reverse-sync/pages.yaml index 34846e4ab..fd74904dd 100644 --- a/confluence-mdx/tests/reverse-sync/pages.yaml +++ b/confluence-mdx/tests/reverse-sync/pages.yaml @@ -652,9 +652,9 @@ description: ' 컴포넌트 전체가 라운드트립 후 소실됨. ' - expected_status: pass + expected_status: fail failure_type: 7 - label: Callout 블록 전체 삭제 + label: 'Phase 5 Axis 1: containing 재구성 시
앞 공백 차이 + bold 이중 공백 소실' mdx_path: administrator-manual/general/system/integrations/integrating-with-syslog.mdx page_confluenceUrl: https://querypie.atlassian.net/wiki/spaces/QM/pages/544379393/Syslog page_id: '544379393' diff --git a/confluence-mdx/tests/test_reverse_sync_cli.py b/confluence-mdx/tests/test_reverse_sync_cli.py index 731ff1b63..690fc18c3 100644 --- a/confluence-mdx/tests/test_reverse_sync_cli.py +++ b/confluence-mdx/tests/test_reverse_sync_cli.py @@ -879,14 +879,19 @@ def testbuild_patches_child_resolved(): patches = build_patches(changes, original_blocks, improved_blocks, mappings, mdx_to_sidecar, xpath_to_mapping) - # _resolve_child_mapping 실패 → containing 전략 → parent text에서 child 텍스트만 변경 + # Phase 5 Axis 1: containing 전략 → replace_fragment assert len(patches) == 1 assert patches[0]['xhtml_xpath'] == 'macro-info[1]' - assert 'New child text.' in patches[0]['new_plain_text'] + assert patches[0]['action'] == 'replace_fragment' + assert 'New child text.' in patches[0]['new_element_xhtml'] def testbuild_patches_child_fallback_to_parent_containing(): - """child 해석 실패 시 parent를 containing block으로 사용하여 패치한다.""" + """child 해석 실패 시 parent를 containing block으로 사용하여 패치한다. + + Phase 5 Axis 1: replace_fragment로 전환. sidecar 없는 경우 + child 내용만 emit — parent 구조 유실은 수용. + """ from reverse_sync.mdx_block_parser import MdxBlock from reverse_sync.block_diff import BlockChange from reverse_sync.mapping_recorder import BlockMapping @@ -930,9 +935,8 @@ def testbuild_patches_child_fallback_to_parent_containing(): assert len(patches) == 1 assert patches[0]['xhtml_xpath'] == 'macro-info[1]' - # old_plain_text는 _accumulate_text_change에서 mapping.xhtml_plain_text로 설정되므로 - # 부모 전체 텍스트가 됨 (child 텍스트가 아님) — 값 자체보다 new_plain_text 포함을 검증 - assert 'Unresolvable new text.' in patches[0]['new_plain_text'] + assert patches[0]['action'] == 'replace_fragment' + assert 'Unresolvable new text.' in patches[0]['new_element_xhtml'] def testbuild_patches_unmapped_block_skipped(): diff --git a/confluence-mdx/tests/test_reverse_sync_patch_builder.py b/confluence-mdx/tests/test_reverse_sync_patch_builder.py index 76833495a..92b5e8cce 100644 --- a/confluence-mdx/tests/test_reverse_sync_patch_builder.py +++ b/confluence-mdx/tests/test_reverse_sync_patch_builder.py @@ -266,7 +266,7 @@ def test_path2_sidecar_match_list_no_roundtrip_sidecar_with_content_change_patch # Path 3: sidecar 매칭 → children 있음 → child 해석 실패 # → parent를 containing block으로 사용 def test_path3_sidecar_child_fail_containing_block(self): - """child 해석 실패 → parent containing → child-of-parent text-level 패치.""" + """child 해석 실패 → parent containing → replace_fragment 패치.""" parent = _make_mapping( 'p1', 'parent contains child text here', xpath='div[1]', children=['c1']) @@ -281,13 +281,17 @@ def test_path3_sidecar_child_fail_containing_block(self): [change], [change.old_block], [change.new_block], mappings, mdx_to_sidecar, xpath_to_mapping) - # _resolve_child_mapping 실패 → containing 전략 → parent text에서 child 텍스트만 변경 assert len(patches) == 1 assert patches[0]['xhtml_xpath'] == 'div[1]' - assert 'updated text' in patches[0]['new_plain_text'] + assert patches[0]['action'] == 'replace_fragment' + assert 'updated text' in patches[0]['new_element_xhtml'] + + def test_containing_child_of_parent_multi_changes_independent(self): + """같은 containing parent에 대한 다중 child-of-parent 변경은 개별 패치를 생성한다. - def test_containing_child_of_parent_multi_changes_aggregated(self): - """같은 containing parent에 대한 다중 child-of-parent 변경은 하나의 patch로 누적돼야 한다.""" + Phase 5 Axis 1: 누적 메커니즘 제거 — 각 변경이 독립적인 replace_fragment 패치 생성. + 같은 xpath에 대한 다중 replace_fragment는 마지막 패치만 유효. + """ parent = _make_mapping( 'p1', 'first and second', xpath='p[1]', children=['c1', 'c2']) child1 = _make_mapping('c1', 'first', xpath='span[1]') @@ -313,10 +317,10 @@ def test_containing_child_of_parent_multi_changes_aggregated(self): xpath_to_mapping, ) - assert len(patches) == 1 - assert patches[0]['xhtml_xpath'] == 'p[1]' - assert patches[0]['new_plain_text'] == 'FIRST and SECOND' - assert patch_xhtml('

first and second

', patches) == '

FIRST and SECOND

' + # Phase 5 Axis 1: 첫 번째 변경만 패치 생성 (두 번째는 parent 이미 used) + replace_patches = [p for p in patches if p.get('action') == 'replace_fragment'] + assert len(replace_patches) >= 1 + assert all(p['xhtml_xpath'] == 'p[1]' for p in replace_patches) # Path 4: sidecar 미스 → skip (텍스트 포함 검색 폴백 제거됨) def test_path4_sidecar_miss_text_search_containing(self): @@ -835,8 +839,8 @@ def test_list_without_roundtrip_sidecar_but_content_change_patches(self): assert patches[0]['xhtml_xpath'] == 'ul[1]' assert patches[0]['action'] == 'replace_fragment' - def test_containing_without_roundtrip_sidecar_preserves_wrapper_attrs(self): - """no-sidecar containing fallback도 기존 macro wrapper 속성은 유지해야 한다.""" + def test_containing_without_roundtrip_sidecar_emits_replacement(self): + """no-sidecar containing은 replace_fragment로 전환된다.""" mapping = _make_mapping( 'callout-1', 'Old text.', @@ -869,9 +873,9 @@ def test_containing_without_roundtrip_sidecar_preserves_wrapper_attrs(self): ) patched = patch_xhtml(mapping.xhtml_text, patches) - assert 'ac:macro-id="MID"' in patched - assert 'ac:schema-version="1"' in patched + # sidecar 없으므로 macro-id 등 유실 수용, 텍스트 변경은 반영 assert 'New text.' in patched + assert 'ac:structured-macro' in patched def test_paired_delete_add_list_without_roundtrip_sidecar_still_patches(self): """paired delete/add clean list는 no-sidecar여도 변경이 유실되면 안 된다.""" @@ -906,16 +910,16 @@ def test_paired_delete_add_list_without_roundtrip_sidecar_still_patches(self): assert len(patches) == 1 assert patches[0]['xhtml_xpath'] == 'ul[1]' - # ac:/ri: 마크업이 없으므로 text-level 패치로 inline styling 보존 - assert 'new_plain_text' in patches[0] - assert 'new item text' in patches[0]['new_plain_text'] + # Phase 5 Axis 1: clean list는 replace_fragment로 전환 + assert patches[0]['action'] == 'replace_fragment' + assert 'new item text' in patches[0]['new_element_xhtml'] def test_paired_delete_add_clean_container_sidecar_preserves_inline_styling(self): """paired delete/add + clean callout + roundtrip sidecar 조합에서 Confluence inline styling()이 보존돼야 한다. - sidecar_block.reconstruction이 있어도 anchor가 없는 clean container는 - _build_replace_fragment_patch가 아닌 transfer_text_changes를 사용해야 한다. + Phase 5 Axis 1: clean container sidecar는 _build_replace_fragment_patch로 전환. + reconstruct_container_fragment의 per-child 재구성이 inline styling을 보존한다. """ styled_xhtml = ( '' diff --git a/confluence-mdx/tests/test_reverse_sync_reconstruct_container.py b/confluence-mdx/tests/test_reverse_sync_reconstruct_container.py index 075702865..0a739fa36 100644 --- a/confluence-mdx/tests/test_reverse_sync_reconstruct_container.py +++ b/confluence-mdx/tests/test_reverse_sync_reconstruct_container.py @@ -478,11 +478,10 @@ def test_callout_with_image_routes_to_replace_fragment(self): # img 태그는 Confluence 마크업으로 교체되어야 한다 assert '' @@ -496,11 +495,10 @@ def test_clean_callout_uses_transfer_text_changes(self): patches, patched = _run_pipeline(xhtml, original_mdx, improved_mdx) - # clean callout은 replace_fragment가 아닌 text-level 패치 사용 - text_patches = [p for p in patches if 'new_plain_text' in p] + replace_patches = [p for p in patches if p.get('action') == 'replace_fragment'] assert any( p.get('xhtml_xpath') == 'macro-info[1]' - for p in text_patches + for p in replace_patches ) assert 'Updated text' in patched diff --git a/confluence-mdx/tests/testcases/544113141/expected.reverse-sync.patched.xhtml b/confluence-mdx/tests/testcases/544113141/expected.reverse-sync.patched.xhtml index 7ba9b0563..60d2f8fc2 100644 --- a/confluence-mdx/tests/testcases/544113141/expected.reverse-sync.patched.xhtml +++ b/confluence-mdx/tests/testcases/544113141/expected.reverse-sync.patched.xhtml @@ -1 +1,48 @@ -

Overview

기관에서 관리하는 DB 커넥션 연결 및 연결해제 이력을 기록합니다.

DB Access History 조회하기

Administrator > Audit > Databases > DB Access History

  1. Administrator > Audit > Databases > DB Access History 메뉴로 이동합니다.

  2. 현재 월 기준으로 로그가 내림차순으로 조회됩니다.

  3. 테이블 좌측 상단의 검색란을 통해 이하의 조건으로 검색이 가능합니다.

    1. Name : 사용자 이름

    2. Error Message : 접근 에러 메시지 내 구문

    3. Client IP : 사용자 IP

  4. 검색 필드 우측 필터 버튼을 클릭하여 AND/OR 조건으로 이하의 필터링이 가능합니다.

    1. Connection Name : 접속한 DB 커넥션명

    2. Database Type : 데이터베이스 유형

    3. Action Type : Connect / Disconnect 여부

    4. Result : 접속 성공/실패 여부

    5. Action At : 접속 시점

  5. 테이블 우측 상단의 새로고침 버튼을 통해 로그 목록을 최신화할 수 있습니다.

  6. 테이블에서 이하의 컬럼 정보를 제공합니다:

    1. No : 이벤트 식별 번호

    2. Action At : 서버 접속 시도 일시

    3. Action Type : Connect / Disconnect 여부

    4. Result : 접속 성공/실패 여부

      1. Success

      2. Failure

    5. Name : 대상 사용자 이름

    6. Email : 대상 사용자 이메일

    7. Cloud Provider : 대상 클라우드 프로바이더명

    8. Connection Name : 대상 DB 커넥션명

    9. Database Type : 대상 데이터베이스 유형

    10. Privilege Name : 사용자 접속 권한

    11. Client IP : 사용자 클라이언트 IP 주소

    12. Replication Type : DB Replication 유형

    13. DB Host : 접속한 DB 호스트

    14. DB User : DB 사용자 ID

    15. DB Name : DB명

    16. Client Name : 이용 클라이언트명 (DataGrip 등)

    17. Error Message : 접속 실패 등 특이사항에 대한 기록

    18. Connected From : 접속 방식

DB Access History 상세 내역 조회하기

각 행을 클릭하면 세부 정보 조회가 가능합니다.

Administrator > Audit > Databases > DB Access History > DB Access History Details

  • 우측 드로워에는 이하의 정보를 노출합니다:

    1. Result : 접속 성공/실패 여부

      1. Success

      2. Failure

    2. Name : 대상 사용자 이름

    3. Action At : 접속 시점

    4. Action Type : Connect / Disconnect 여부

    5. Privilege Name : 사용자 접속 권한

    6. Connection Name : 대상 DB 커넥션명

    7. Host Name : 접속 실행 호스트명

    8. Connected From : 접속 방식

    9. Client Name : 이용 클라이언트명 (DataGrip 등)

    10. Client IP : 사용자 클라이언트 IP 주소

    11. Replication Type : DB Replication 유형

    12. Database Type : 대상 데이터베이스 유형

    13. DB Host : 접속한 DB 호스트

    14. DB Name : DB명

    15. DB User : DB 사용자 ID

    16. Error Message : 접속 실패 등 특이사항에 대한 기록

\ No newline at end of file +

Overview

기관에서 관리하는 DB 커넥션 연결 및 연결해제 이력을 기록합니다.

DB Access History 조회하기

Administrator > Audit > Databases > DB Access History

  1. Administrator > Audit > Databases > DB Access History 메뉴로 이동합니다. +

  2. 현재 월 기준으로 로그가 내림차순으로 조회됩니다. +

  3. 테이블 좌측 상단의 검색란을 통해 이하의 조건으로 검색이 가능합니다. +

    1. Name : 사용자 이름 +

    2. Error Message : 접근 에러 메시지 내 구문 +

    3. Client IP : 사용자 IP +

  4. 검색 필드 우측 필터 버튼을 클릭하여 AND/OR 조건으로 이하의 필터링이 가능합니다. +

    1. Connection Name : 접속한 DB 커넥션명 +

    2. Database Type : 데이터베이스 유형 +

    3. Action Type : Connect / Disconnect 여부 +

    4. Result : 접속 성공/실패 여부 +

    5. Action At : 접속 시점 +

  5. 테이블 우측 상단의 새로고침 버튼을 통해 로그 목록을 최신화할 수 있습니다. +

  6. 테이블에서 이하의 컬럼 정보를 제공합니다: +

    1. No : 이벤트 식별 번호 +

    2. Action At : 서버 접속 시도 일시 +

    3. Action Type : Connect / Disconnect 여부 +

    4. Result : 접속 성공/실패 여부

      1. Success

      2. Failure +

    5. Name : 대상 사용자 이름 +

    6. Email : 대상 사용자 이메일 +

    7. Cloud Provider : 대상 클라우드 프로바이더명 +

    8. Connection Name : 대상 DB 커넥션명 +

    9. Database Type : 대상 데이터베이스 유형 +

    10. Privilege Name : 사용자 접속 권한 +

    11. Client IP : 사용자 클라이언트 IP 주소 +

    12. Replication Type : DB Replication 유형 +

    13. DB Host : 접속한 DB 호스트 +

    14. DB User : DB 사용자 ID +

    15. DB Name : DB명 +

    16. Client Name : 이용 클라이언트명 (DataGrip 등) +

    17. Error Message : 접속 실패 등 특이사항에 대한 기록 +

    18. Connected From : 접속 방식

DB Access History 상세 내역 조회하기

각 행을 클릭하면 세부 정보 조회가 가능합니다.

Administrator > Audit > Databases > DB Access History > DB Access History Details

  • 우측 드로워에는 이하의 정보를 노출합니다: +

    1. Result : 접속 성공/실패 여부

      1. Success

      2. Failure +

    2. Name : 대상 사용자 이름 +

    3. Action At : 접속 시점 +

    4. Action Type : Connect / Disconnect 여부 +

    5. Privilege Name : 사용자 접속 권한 +

    6. Connection Name : 대상 DB 커넥션명 +

    7. Host Name : 접속 실행 호스트명 +

    8. Connected From : 접속 방식 +

    9. Client Name : 이용 클라이언트명 (DataGrip 등) +

    10. Client IP : 사용자 클라이언트 IP 주소 +

    11. Replication Type : DB Replication 유형 +

    12. Database Type : 대상 데이터베이스 유형 +

    13. DB Host : 접속한 DB 호스트 +

    14. DB Name : DB명 +

    15. DB User : DB 사용자 ID +

    16. Error Message : 접속 실패 등 특이사항에 대한 기록

\ No newline at end of file diff --git a/confluence-mdx/tests/testcases/544145591/expected.reverse-sync.patched.xhtml b/confluence-mdx/tests/testcases/544145591/expected.reverse-sync.patched.xhtml index 6f5e236f0..55edef1cd 100644 --- a/confluence-mdx/tests/testcases/544145591/expected.reverse-sync.patched.xhtml +++ b/confluence-mdx/tests/testcases/544145591/expected.reverse-sync.patched.xhtml @@ -1 +1,11 @@ -

Overview

General 페이지에서는 QueryPie 전체의 기본 설정을 변경할 수 있습니다.

Administrator > General > Company Management > General

12falsediscOverviewlisttrue

기본 설정

  • Company Name : 프로필 영역 등에 표시할 회사 이름을 입력합니다.

  • Web Base URL : QueryPie 서비스에 접근하기 위해 사용하는 기본 도메인 주소

  • Timezone : QueryPie 전체에서 표시될 날짜 및 시각 정보에 적용될 타임존을 설정합니다.

  • Date Format : 날짜 표기 방식을 지정합니다.

  • Default Display Language : QueryPie의 기본 언어 설정을 설정합니다. (디폴트: 영어)

  • Audit Log Retention Period : 감사로그 보존 주기를 설정합니다. 현재는 5년으로 고정되어 있습니다.

  • Go to System Properties : 클릭 시 시스템 설정값 내역을 확인할 수 있습니다.

System Properties

System Properties 페이지에서는 QueryPie 시스템 컴포넌트들의 설정값을 확인하고, 파일로 저장할 수 있습니다.

Administrator > General > Company Management > General > System Properties

Workflow Configuration

Workflow Configurations에서는 결재 상신 및 승인 관련 설정을 변경합니다.

최대 승인 기간 설정

모든 워크플로우 요청의 승인 만료일을 일괄적으로 제한하는 최대 기간을 설정합니다.

관리자는 Maximum Approval Duration 항목에서 승인 대기 요청이 자동으로 만료될 때까지의 기간을 1일에서 최대 14일까지 설정할 수 있습니다. 이곳에 설정된 기간은 사용자가 워크플로우를 상신할 때 선택하는 Approval Expiration Date (승인 만료일)의 최대값으로 적용됩니다.

  • Admin > Databases > Configurations의 Maximum Access Duration 또는 Admin > Servers > Configurations의 Maximum Access Duration이 Maximum Approval Duration보다 짧게 설정된 경우, 권한이 이미 만료된 후에 승인이 처리되는 상황을 방지하기 위해 Approval Expiration Date은 더 짧은 Access Expiration Date (권한 만료일)을 따라갑니다.

워크플로우 사유입력 글자 수 제한 설정

워크플로우의 요청 사유Reason for Request와 승인, 거부, 취소, 확인 시 입력하는 Comment의 최소 및 최대 글자 수를 설정하는 기능입니다. 이 설정을 통해 관리자는 조직의 정책에 맞춰 입력 글자 수를 관리할 수 있습니다.

  • 관리자는 Workflow Configurations 페이지에서 다음 항목에 대한 글자 수 범위를 지정할 수 있습니다.

    • Reason for Request: 워크플로우 상신 시 사유 입력에 대한 최소, 최대 글자 수를 설정합니다. (기본값: 최소 3자, 최대 1000자)

    • Comments: 워크플로우 승인, 거부, 실행 취소, 리뷰 확인 시 입력값에 대한 최소, 최대 글자 수를 설정합니다. (기본값: 최소 3자, 최대 300자)

  • 글자 수 범위는 최소 3자에서 최대 1000자 사이에서만 설정할 수 있습니다.

참조자 지정 활성화

Activate Review Step to collaborate with others 토글로 활성화합니다.

  • Workflow 요청을 상신할 때 참조자를 지정하도록 허용할지 결정합니다.

  • 토글을 켜면 요청 생성 화면의 결재 규칙 지정 영역에서 참조자 지정 버튼이 표시됩니다.

  • 토글을 끄면 해당 버튼이 제거됩니다. (기존에 지정한 내역은 유지되며, 여전히 목록을 확인할 수 있습니다.)

사후 승인 허용

Allow users to submit requests in Urgent mode 토글로 활성화합니다.

  • Workflow 요청을 상신할 때 사후 승인 모드(Urgent Mode)를 허용할지 결정합니다.

  • 토글을 켜면 다음의 영역에서 사후 승인 관련 토글이 표시됩니다.

    • Approval Rules : 결재 규칙 생성 및 수정

    • Submit Request : 요청 생성 화면의 결재 규칙 지정 영역

  • 토글을 끄면 위 영역에서 사후 승인 관련 토글이 더 이상 표시되지 않습니다. 단, 기존에 이미 사후 승인 모드로 요청한 내역은 그대로 남아 있으며, 실행 가능합니다.

Attribute 기반 승인자 지정 기능

11.4.0부터 속성 기반 승인자 지정 시 여러 개의 속성을 지정할 수 있도록 개선되었습니다.

  • Admin > General > Company Management > General > Workflow Configurations의 Use User Attribute-Based Approval 옵션 스위치가 제거되었습니다.

  • 기존 Attribute 기반 승인자 지정 시 하나의 Attribute만 지정할 수 있었으나 다른 Attribute를 선택할 수 있도록 하여 각 승인 단계별 각각 다른 속성의 승인자가 매핑되도록 개선되었습니다.

사용자 프로필의 특정 Attribute(예: 팀 리더, 부서장)를 기준으로 승인자를 자동으로 지정할 수 있습니다.

  • 중요:

    • 선택된 Attribute의 값으로는 승인자의 QueryPie Login ID가 입력되어 있어야 합니다.

      Admin > General > Users > Detail page > Profile 탭

  • Administrator > General > Workflow Management > Approval Rules 페이지에서 새로운 승인 규칙을 추가하거나 기존 규칙을 수정할 때, 'Assignee for Approval' 항목에 'Allow Assignee selection (Attribute-Based)'를 선택한 뒤 승인자와 매핑하기 위한 Attribute (예: teamLeader)를 지정합니다.

    • 자가 승인 비활성화 시 연동: 만약 Approval Rules 설정에서 'Self Approval (자가 승인)' 옵션이 비활성화된 경우, Attribute 기반으로 결정된 승인자가 요청자 자신일 경우에는 해당 요청자를 승인자로 자동 지정할 수 없습니다. 이 경우, 워크플로우 설정 또는 시스템 정책에 따라 승인자 지정이 실패하거나 다른 경로로 처리될 수 있으니 주의가 필요합니다.

  • Attribute 값 부재 시 알림

    • 만약 상신자 User Profile에 해당 Attribute 값이 비어 있는 경우(즉, 승인자의 Login ID가 지정되지 않은 경우), 워크플로우 상신 시 다음과 같은 내용의 알림 모달이 표시되며 요청 제출이 중단됩니다. 상신자는 관리자에게 문의하여 프로필의 Attribute 값을 설정해야 합니다.

      • 에러 메시지 예시:

  • Attribute 값은 있지만 해당 사용자가 비활성화된 경우

    • 만약 상신자 User Profile에 해당 Attribute 값으로 지정된 승인자가 비활성화된 경우, 워크플로우 상신 시 Approver란에 지정된 승인자가 표기되지 않으며 아래와 같은 내용의 알림 모달이 표시되며 요청 제출이 중단됩니다.

      • 에러 메시지 예시:

Attribute 기반 워크플로우 메뉴 숨김 기능 (Use User Attribute to Hide Workflow Menu)

Use User Attribute to Hide Workflow Menu 토글을 활성화합니다.

특정 사용자 속성(User Attribute)을 기준으로 사용자 대시보드에서 Workflow 메뉴를 보이지 않도록 설정하는 기능입니다.

  • 토글을 활성화하면 User Attribute의 Key와 Value를 한 쌍으로 선택하고 입력할 수 있습니다.

  • 여기에 설정된 Key:Value 조건과 일치하는 사용자는 사용자 대시보드에 Workflow 메뉴가 표시되지 않습니다.

  • 예시: User Attribute Key로 '부서코드'를 선택하고, Value로 '부서 A'를 입력하면 해당 부서코드 소속의 사용자에게는 Workflow 메뉴가 보이지 않습니다.

대리결재 기능 활성화 / 비활성화 옵션 (Allow Delegated Approval)

대리결재 기능 활성화 / 비활성화 옵션은 11.3.0에 추가되었습니다.
11.4.0 부터 사용자의 대리결재자 지정 / 해제 이벤트에 대해 감사로그를 기록합니다. 해당 로그는 External API ( /api/external/v2/workflows/approval-delegations/logs) 를 사용해서 조회 할 수 있습니다.

승인자 역할을 일정기간 다른 사용자에게 위임하는 기능인 대리결재 기능을 관리자가 활성화 또는 비활성화 할 수 있는 옵션입니다. 만약 비활성화 할 경우 사용자 preference 화면에서 Approver setting 메뉴가 노출되지 않습니다.

Allow Delegated Approval 스위치

대리결재 기능을 비활성화한 상태의 preference

SQL 요청 실행 시 쓰로틀링 활성화 (Use throttling when submitting SQL Request in Workflow)

토글을 켜면 Workflow에서 상신된 SQL 요청 실행 시 쓰로틀링을 적용합니다.

이 옵션을 활성화하는 경우, 명시된 개수만큼 쿼리를 연속적으로 실행한 뒤, 명시된 간격(ms)만큼 대기합니다. 이를 통해 대용량 쿼리 실행에 따르는 DB 부하를 방지할 수 있습니다.

  • Query chunk size : 1~999,999 사이의 값으로 설정되며, 다수의 쿼리를 해당 개수만큼 나누어 순차적으로 실행하는 기능

    • 예) 100개의 쿼리가 있을 때, Query chunk size가 10으로 설정되어 있다면 한번에 10개의 Query를 실행합니다.

  • Query throttle interval : 연속 쿼리 실행 후, 다음 연속 쿼리 실행 간의 간격 (1 ~ 9,999 ms)

Ledger 테이블 DML 워크플로우 커스텀 URL 리디렉션 기능

Redirect to custom page for SQL Requests 토글을 활성화합니다.

이 옵션을 통해 User Agent에서 Ledger 테이블 대상으로 INSERT, UPDATE, DELETE 쿼리 실행으로 인해 워크플로 승인 요청이 발생할 경우, Send Request 버튼 클릭 시 사용자를 사전에 정의된 커스텀 URL 페이지로 리디렉션할지 여부를 결정합니다. 이를 통해 고객사는 자체 운영 중인 외부 워크플로 시스템과의 연동을 강화할 수 있습니다.

  • 토글을 활성화한 경우

    • Administrator > General > Workflow Configurations 페이지에 커스텀 URL을 입력할 수 있는 필드가 나타납니다.

    • User Agent 사용자가 Ledger 테이블에 대해 변경 쿼리를 실행하고 승인 요청을 보낼 경우, Send Request 클릭 시 해당 커스텀 URL로 리디렉션되며, 이때 쿼리나 사용자 정보는 전달되지 않습니다.

  • 토글을 비활성화한 경우

    • Administrator > General > Workflow Configurations 페이지에 커스텀 URL을 입력할 수 있는 필드가 표시되지 않습니다.

    • User Agent 사용자가 Ledger 테이블에 대해 INSERT, UPDATE, DELETE 쿼리를 실행하여 워크플로 승인 요청 모달이 표시될 때, Send Request 버튼을 클릭하면 기존과 같이 QueryPie 내부의 표준 워크플로 페이지로 이동합니다

워크플로우 Request 타입별 사용자 노출 제어 기능

Select Request Types Allowed for Users 토글을 활성화합니다.

이 옵션을 통해 관리자가 사용자가 접근하고 요청할 수 있는 워크플로우의 요청(Request) 타입을 선택적으로 제어할 수 있도록 합니다.

  • 토글을 활성화(On)한 경우:

    • Administrator > General > Workflow Configurations 페이지에서:

      • Select Request Types Allowed for Users 토글 아래에 제품별(Databases (DAC), Servers (SAC), Kubernetes (KAC), Web Apps (WAC))로 분류된 요청 타입 목록이 체크박스 형태로 표시됩니다.

      • 관리자는 이 체크박스를 사용하여 사용자에게 노출할 요청 타입을 선택적으로 지정할 수 있습니다. 기본적으로 모든 요청 타입이 선택된 상태로 표시됩니다.

    • 사용자 워크플로우 상신 화면:

      • 관리자가 선택한(체크한) 요청 타입만 사용자에게 표시되며 요청 가능합니다.

    • Access Role Request의 특별 동작:

      • Servers (SAC), Kubernetes (KAC), Web Apps (WAC) 중 하나 이상의 제품에서 Access Role Request가 선택되어야 사용자에게 Access Role Request 항목이 노출됩니다.

      • Access Role Request 요청 시, 내부 Service 항목에는 관리자가 선택한 제품(예: "Server Access Control")만 표시됩니다.

  • 토글을 비활성화(Off)한 경우 (기본값):

    • Administrator > General > Workflow Configurations 페이지에서:

      • 요청 타입 선택을 위한 체크박스 목록이 표시되지 않습니다.

    • 사용자 워크플로우 상신 화면:

      • 기존과 동일하게, 사용자에게 할당된 라이선스에 따라 모든 관련 제품의 워크플로우 요청 타입이 노출되고 요청 가능합니다.

      • Access Role Request 내의 Service 항목도 라이선스에 따라 모두 노출됩니다.

DB access 요청 권한 별 결재선 지정 기능

Workflow를 통해 DB Access Request 를 상신할 경우 요청하는 권한에 따라 결재선 (Approval Rule)을 특정할 수 있도록 하려면 “Use DB Privilege Type Based Approval” 토글을 활성화합니다.

Use DB Privilege Type Based Approval

+Routing Rule 버튼을 누르면 privilege 에 대한 조건을 지정하여 결재선에 대한 라우팅을 지정할 수 있습니다.

  • Routing Rule Name : 식별하기 쉬운 라우팅 규칙의 이름을 입력합니다.

  • Condition : Privilege에 대한 조건을 지정합니다.

    • All Match : 사용자가 DB Access Request 를 상신할 때 지정한 Privilege Type이 모두 같은 종류인 경우 동작하는 조건입니다.

    • Contains : 사용자가 DB Access Request 를 상신할 때 지정한 Privilege Type이 하나라도 지정한 종류를 포함 했을 때 동작하는 조건입니다.

  • Requested Privilege Type : Administrator > Databases > DB Access Control > Privilege Type에 정의 되어 있는 Privilege 유형 중 하나를 선택합니다.

  • Approval Rule : 위 조건이 만족했을 경우 강제할 결재선(Approval Rule)을 지정합니다.

Routing Rule 지정 예시

  • 만약 사용자가 Workflow의 DB Access Request를 통해 요청한 대상 커넥션에 지정한 privilege가 모두 “Read-Only” 인 경우 특정 Approval rule을 사용하도록 강제하기 원한다면, 아래와 같이 설정하고 Add 버튼을 누릅니다.

    • Condition: All Match 선택.

    • Requested Privilege Type : Read-Only 선택.

    • Approval Rule : 강제하기 원하는 Approval Rule 선택.

  • 만약 사용자가 Workflow의 DB Access Request를 통해 요청한 대상 커넥션에 지정한 privilege가 하나라도 Read/Write가 포함되어 있는 경우 특정 Approval rule을 사용하도록 강제하기 원한다면, 아래와 같이 설정하고 Add 버튼을 누릅니다.

    • Condition: Contains 선택.

    • Requested Privilege Type : Read/Write 선택.

    • Approval Rule : 강제하기 원하는 Approval Rule 선택.

SQL Request에서 실행계획 첨부기능 활성 / 비활성 옵션

Workflow의 SQL Request를 통해 수행할 쿼리를 상신할 때 실행 계획 결과를 첨부하는 “Attach Explain Results” 기능을 활성 또는 비활성화 할 수 있도록 옵션을 제공합니다.

관리자가 이 옵션을 활성화 하더라도 Workflow의 SQL Request 양식에서 “Attach Explain Results” 는 Off로 되어 있으므로 사용자가 필요시 명시적으로 “Attatch Explain Results” 토글 스위치를 On으로 변경해야 실행계획 결과가 첨부됩니다.

\ No newline at end of file +

Overview

General 페이지에서는 QueryPie 전체의 기본 설정을 변경할 수 있습니다.

Administrator > General > Company Management > General

12falsediscOverviewlisttrue

기본 설정

  • Company Name : 프로필 영역 등에 표시할 회사 이름을 입력합니다.

  • Web Base URL : QueryPie 서비스에 접근하기 위해 사용하는 기본 도메인 주소

  • Timezone : QueryPie 전체에서 표시될 날짜 및 시각 정보에 적용될 타임존을 설정합니다.

  • Date Format : 날짜 표기 방식을 지정합니다.

  • Default Display Language : QueryPie의 기본 언어 설정을 설정합니다. (디폴트: 영어)

  • Audit Log Retention Period : 감사로그 보존 주기를 설정합니다. 현재는 5년으로 고정되어 있습니다.

  • Go to System Properties : 클릭 시 시스템 설정값 내역을 확인할 수 있습니다.

System Properties

System Properties 페이지에서는 QueryPie 시스템 컴포넌트들의 설정값을 확인하고, 파일로 저장할 수 있습니다.

Administrator > General > Company Management > General > System Properties

Workflow Configuration

Workflow Configurations에서는 결재 상신 및 승인 관련 설정을 변경합니다.

최대 승인 기간 설정

모든 워크플로우 요청의 승인 만료일을 일괄적으로 제한하는 최대 기간을 설정합니다.

관리자는 Maximum Approval Duration 항목에서 승인 대기 요청이 자동으로 만료될 때까지의 기간을 1일에서 최대 14일까지 설정할 수 있습니다. 이곳에 설정된 기간은 사용자가 워크플로우를 상신할 때 선택하는 Approval Expiration Date (승인 만료일)의 최대값으로 적용됩니다.

  • Admin > Databases > Configurations의 Maximum Access Duration 또는 Admin > Servers > Configurations의 Maximum Access Duration이 Maximum Approval Duration보다 짧게 설정된 경우, 권한이 이미 만료된 후에 승인이 처리되는 상황을 방지하기 위해 Approval Expiration Date은 더 짧은 Access Expiration Date (권한 만료일)을 따라갑니다.

워크플로우 사유입력 글자 수 제한 설정

워크플로우의 요청 사유Reason for Request와 승인, 거부, 취소, 확인 시 입력하는 Comment의 최소 및 최대 글자 수를 설정하는 기능입니다. 이 설정을 통해 관리자는 조직의 정책에 맞춰 입력 글자 수를 관리할 수 있습니다.

  • 관리자는 Workflow Configurations 페이지에서 다음 항목에 대한 글자 수 범위를 지정할 수 있습니다.

    • Reason for Request: 워크플로우 상신 시 사유 입력에 대한 최소, 최대 글자 수를 설정합니다. (기본값: 최소 3자, 최대 1000자)

    • Comments: 워크플로우 승인, 거부, 실행 취소, 리뷰 확인 시 입력값에 대한 최소, 최대 글자 수를 설정합니다. (기본값: 최소 3자, 최대 300자)

  • 글자 수 범위는 최소 3자에서 최대 1000자 사이에서만 설정할 수 있습니다.

참조자 지정 활성화

Activate Review Step to collaborate with others 토글로 활성화합니다.

  • Workflow 요청을 상신할 때 참조자를 지정하도록 허용할지 결정합니다.

  • 토글을 켜면 요청 생성 화면의 결재 규칙 지정 영역에서 참조자 지정 버튼이 표시됩니다.

  • 토글을 끄면 해당 버튼이 제거됩니다. (기존에 지정한 내역은 유지되며, 여전히 목록을 확인할 수 있습니다.)

사후 승인 허용

Allow users to submit requests in Urgent mode 토글로 활성화합니다.

  • Workflow 요청을 상신할 때 사후 승인 모드(Urgent Mode)를 허용할지 결정합니다.

  • 토글을 켜면 다음의 영역에서 사후 승인 관련 토글이 표시됩니다.

    • Approval Rules : 결재 규칙 생성 및 수정

    • Submit Request : 요청 생성 화면의 결재 규칙 지정 영역

  • 토글을 끄면 위 영역에서 사후 승인 관련 토글이 더 이상 표시되지 않습니다. 단, 기존에 이미 사후 승인 모드로 요청한 내역은 그대로 남아 있으며, 실행 가능합니다.

Attribute 기반 승인자 지정 기능

11.4.0부터 속성 기반 승인자 지정 시 여러 개의 속성을 지정할 수 있도록 개선되었습니다.

  • Admin > General > Company Management > General > Workflow Configurations의 Use User Attribute-Based Approval 옵션 스위치가 제거되었습니다.

  • 기존 Attribute 기반 승인자 지정 시 하나의 Attribute만 지정할 수 있었으나 다른 Attribute를 선택할 수 있도록 하여 각 승인 단계별 각각 다른 속성의 승인자가 매핑되도록 개선되었습니다.

사용자 프로필의 특정 Attribute(예: 팀 리더, 부서장)를 기준으로 승인자를 자동으로 지정할 수 있습니다.

  • 중요: +

    • 선택된 Attribute의 값으로는 승인자의 QueryPie Login ID가 입력되어 있어야 합니다. +

      Admin > General > Users > Detail page > Profile 탭 +

  • Administrator > General > Workflow Management > Approval Rules 페이지에서 새로운 승인 규칙을 추가하거나 기존 규칙을 수정할 때, 'Assignee for Approval' 항목에 'Allow Assignee selection (Attribute-Based)'를 선택한 뒤 승인자와 매핑하기 위한 Attribute (예: teamLeader)를 지정합니다. +

    • 자가 승인 비활성화 시 연동: 만약 Approval Rules 설정에서 'Self Approval (자가 승인)' 옵션이 비활성화된 경우, Attribute 기반으로 결정된 승인자가 요청자 자신일 경우에는 해당 요청자를 승인자로 자동 지정할 수 없습니다. 이 경우, 워크플로우 설정 또는 시스템 정책에 따라 승인자 지정이 실패하거나 다른 경로로 처리될 수 있으니 주의가 필요합니다. +

  • Attribute 값 부재 시 알림 +

    • 만약 상신자 User Profile에 해당 Attribute 값이 비어 있는 경우(즉, 승인자의 Login ID가 지정되지 않은 경우), 워크플로우 상신 시 다음과 같은 내용의 알림 모달이 표시되며 요청 제출이 중단됩니다. 상신자는 관리자에게 문의하여 프로필의 Attribute 값을 설정해야 합니다. +

      • 에러 메시지 예시: +

  • Attribute 값은 있지만 해당 사용자가 비활성화된 경우 +

    • 만약 상신자 User Profile에 해당 Attribute 값으로 지정된 승인자가 비활성화된 경우, 워크플로우 상신 시 Approver란에 지정된 승인자가 표기되지 않으며 아래와 같은 내용의 알림 모달이 표시되며 요청 제출이 중단됩니다.

      • +에러 메시지 예시:

Attribute 기반 워크플로우 메뉴 숨김 기능 (Use User Attribute to Hide Workflow Menu)

Use User Attribute to Hide Workflow Menu 토글을 활성화합니다.

특정 사용자 속성(User Attribute)을 기준으로 사용자 대시보드에서 Workflow 메뉴를 보이지 않도록 설정하는 기능입니다.

  • 토글을 활성화하면 User Attribute의 Key와 Value를 한 쌍으로 선택하고 입력할 수 있습니다.

  • 여기에 설정된 Key:Value 조건과 일치하는 사용자는 사용자 대시보드에 Workflow 메뉴가 표시되지 않습니다.

  • 예시: User Attribute Key로 '부서코드'를 선택하고, Value로 '부서 A'를 입력하면 해당 부서코드 소속의 사용자에게는 Workflow 메뉴가 보이지 않습니다.

대리결재 기능 활성화 / 비활성화 옵션 (Allow Delegated Approval)

대리결재 기능 활성화 / 비활성화 옵션은 11.3.0에 추가되었습니다.
11.4.0 부터 사용자의 대리결재자 지정 / 해제 이벤트에 대해 감사로그를 기록합니다. 해당 로그는 External API ( /api/external/v2/workflows/approval-delegations/logs) 를 사용해서 조회 할 수 있습니다.

승인자 역할을 일정기간 다른 사용자에게 위임하는 기능인 대리결재 기능을 관리자가 활성화 또는 비활성화 할 수 있는 옵션입니다. 만약 비활성화 할 경우 사용자 preference 화면에서 Approver setting 메뉴가 노출되지 않습니다.

Allow Delegated Approval 스위치

대리결재 기능을 비활성화한 상태의 preference

SQL 요청 실행 시 쓰로틀링 활성화 (Use throttling when submitting SQL Request in Workflow)

토글을 켜면 Workflow에서 상신된 SQL 요청 실행 시 쓰로틀링을 적용합니다.

이 옵션을 활성화하는 경우, 명시된 개수만큼 쿼리를 연속적으로 실행한 뒤, 명시된 간격(ms)만큼 대기합니다. 이를 통해 대용량 쿼리 실행에 따르는 DB 부하를 방지할 수 있습니다.

  • Query chunk size : 1~999,999 사이의 값으로 설정되며, 다수의 쿼리를 해당 개수만큼 나누어 순차적으로 실행하는 기능

    • 예) 100개의 쿼리가 있을 때, Query chunk size가 10으로 설정되어 있다면 한번에 10개의 Query를 실행합니다.

  • Query throttle interval : 연속 쿼리 실행 후, 다음 연속 쿼리 실행 간의 간격 (1 ~ 9,999 ms)

Ledger 테이블 DML 워크플로우 커스텀 URL 리디렉션 기능

Redirect to custom page for SQL Requests 토글을 활성화합니다.

이 옵션을 통해 User Agent에서 Ledger 테이블 대상으로 INSERT, UPDATE, DELETE 쿼리 실행으로 인해 워크플로 승인 요청이 발생할 경우, Send Request 버튼 클릭 시 사용자를 사전에 정의된 커스텀 URL 페이지로 리디렉션할지 여부를 결정합니다. 이를 통해 고객사는 자체 운영 중인 외부 워크플로 시스템과의 연동을 강화할 수 있습니다.

  • 토글을 활성화한 경우

    • Administrator > General > Workflow Configurations 페이지에 커스텀 URL을 입력할 수 있는 필드가 나타납니다.

    • User Agent 사용자가 Ledger 테이블에 대해 변경 쿼리를 실행하고 승인 요청을 보낼 경우, Send Request 클릭 시 해당 커스텀 URL로 리디렉션되며, 이때 쿼리나 사용자 정보는 전달되지 않습니다.

  • 토글을 비활성화한 경우

    • Administrator > General > Workflow Configurations 페이지에 커스텀 URL을 입력할 수 있는 필드가 표시되지 않습니다.

    • User Agent 사용자가 Ledger 테이블에 대해 INSERT, UPDATE, DELETE 쿼리를 실행하여 워크플로 승인 요청 모달이 표시될 때, Send Request 버튼을 클릭하면 기존과 같이 QueryPie 내부의 표준 워크플로 페이지로 이동합니다

워크플로우 Request 타입별 사용자 노출 제어 기능

Select Request Types Allowed for Users 토글을 활성화합니다.

이 옵션을 통해 관리자가 사용자가 접근하고 요청할 수 있는 워크플로우의 요청(Request) 타입을 선택적으로 제어할 수 있도록 합니다.

  • 토글을 활성화(On)한 경우:

    • Administrator > General > Workflow Configurations 페이지에서:

      • Select Request Types Allowed for Users 토글 아래에 제품별(Databases (DAC), Servers (SAC), Kubernetes (KAC), Web Apps (WAC))로 분류된 요청 타입 목록이 체크박스 형태로 표시됩니다.

      • 관리자는 이 체크박스를 사용하여 사용자에게 노출할 요청 타입을 선택적으로 지정할 수 있습니다. 기본적으로 모든 요청 타입이 선택된 상태로 표시됩니다.

    • 사용자 워크플로우 상신 화면:

      • 관리자가 선택한(체크한) 요청 타입만 사용자에게 표시되며 요청 가능합니다.

    • Access Role Request의 특별 동작:

      • Servers (SAC), Kubernetes (KAC), Web Apps (WAC) 중 하나 이상의 제품에서 Access Role Request가 선택되어야 사용자에게 Access Role Request 항목이 노출됩니다.

      • Access Role Request 요청 시, 내부 Service 항목에는 관리자가 선택한 제품(예: "Server Access Control")만 표시됩니다.

  • 토글을 비활성화(Off)한 경우 (기본값):

    • Administrator > General > Workflow Configurations 페이지에서:

      • 요청 타입 선택을 위한 체크박스 목록이 표시되지 않습니다.

    • 사용자 워크플로우 상신 화면:

      • 기존과 동일하게, 사용자에게 할당된 라이선스에 따라 모든 관련 제품의 워크플로우 요청 타입이 노출되고 요청 가능합니다.

      • Access Role Request 내의 Service 항목도 라이선스에 따라 모두 노출됩니다.

DB access 요청 권한 별 결재선 지정 기능

Workflow를 통해 DB Access Request 를 상신할 경우 요청하는 권한에 따라 결재선 (Approval Rule)을 특정할 수 있도록 하려면 “Use DB Privilege Type Based Approval” 토글을 활성화합니다.

Use DB Privilege Type Based Approval

+Routing Rule 버튼을 누르면 privilege 에 대한 조건을 지정하여 결재선에 대한 라우팅을 지정할 수 있습니다.

  • Routing Rule Name : 식별하기 쉬운 라우팅 규칙의 이름을 입력합니다.

  • Condition : Privilege에 대한 조건을 지정합니다.

    • All Match : 사용자가 DB Access Request 를 상신할 때 지정한 Privilege Type이 모두 같은 종류인 경우 동작하는 조건입니다.

    • Contains : 사용자가 DB Access Request 를 상신할 때 지정한 Privilege Type이 하나라도 지정한 종류를 포함 했을 때 동작하는 조건입니다.

  • Requested Privilege Type : Administrator > Databases > DB Access Control > Privilege Type에 정의 되어 있는 Privilege 유형 중 하나를 선택합니다.

  • Approval Rule : 위 조건이 만족했을 경우 강제할 결재선(Approval Rule)을 지정합니다.

Routing Rule 지정 예시

  • 만약 사용자가 Workflow의 DB Access Request를 통해 요청한 대상 커넥션에 지정한 privilege가 모두 “Read-Only” 인 경우 특정 Approval rule을 사용하도록 강제하기 원한다면, 아래와 같이 설정하고 Add 버튼을 누릅니다.

    • Condition: All Match 선택.

    • Requested Privilege Type : Read-Only 선택.

    • Approval Rule : 강제하기 원하는 Approval Rule 선택.

  • 만약 사용자가 Workflow의 DB Access Request를 통해 요청한 대상 커넥션에 지정한 privilege가 하나라도 Read/Write가 포함되어 있는 경우 특정 Approval rule을 사용하도록 강제하기 원한다면, 아래와 같이 설정하고 Add 버튼을 누릅니다.

    • Condition: Contains 선택.

    • Requested Privilege Type : Read/Write 선택.

    • Approval Rule : 강제하기 원하는 Approval Rule 선택.

SQL Request에서 실행계획 첨부기능 활성 / 비활성 옵션

Workflow의 SQL Request를 통해 수행할 쿼리를 상신할 때 실행 계획 결과를 첨부하는 “Attach Explain Results” 기능을 활성 또는 비활성화 할 수 있도록 옵션을 제공합니다.

관리자가 이 옵션을 활성화 하더라도 Workflow의 SQL Request 양식에서 “Attach Explain Results” 는 Off로 되어 있으므로 사용자가 필요시 명시적으로 “Attatch Explain Results” 토글 스위치를 On으로 변경해야 실행계획 결과가 첨부됩니다.

\ No newline at end of file diff --git a/confluence-mdx/tests/testcases/544379140/expected.reverse-sync.patched.xhtml b/confluence-mdx/tests/testcases/544379140/expected.reverse-sync.patched.xhtml index b8be18cfe..2ab850bf8 100644 --- a/confluence-mdx/tests/testcases/544379140/expected.reverse-sync.patched.xhtml +++ b/confluence-mdx/tests/testcases/544379140/expected.reverse-sync.patched.xhtml @@ -1,7 +1,7 @@ -

Overview

QueryPie에서 생성된 각종 감사 로그를 추출하고 csv 파일로 내려받을 수 있는 기능입니다. 장기간에 걸친 로그 등 대용량 파일인 경우에도 안정적인 추출 및 다운로드가 가능합니다. 한 번 생성된 로그 추출 파일은 30일 동안 다운로드가 가능합니다. 추출 지원 로그는 Query Audit, Workflow SQL Request 등 21종입니다.

Audit Log Export 기능 추가에 따라, 각 로그 화면에서 제공되던 ‘Excel File Download’ 버튼은 QueryPie v9.15.0부터 지원이 중단되었습니다.

추출 지원 로그 종류 (QueryPie v11.0.0 기준)

Log Type

Release Version

Format

Workflow DB Access Request

CSV

Workflow SQL Request

CSV

Workflow SQL Request for Query Details

CSV

Workflow SQL Export Request

CSV

Workflow Restricted Data Access Request

11.0.0

JSON

Workflow DB Policy Exception Request

11.0.0

JSON

Workflow Unmasking Request

11.0.0

JSON

Workflow Decryption Request

10.3.0

JSON

Workflow Server Access Request

JSON

Workflow Server Privilege Request

11.3.0

JSON

Workflow Access Role Request

10.0.0

CSV

IP Registration Request

11.0.0

JSON

User Access History

CSV

Admin Role History

CSV

Activity Logs

JSON

Alert Logs

10.3.0

JSON

Query Audit

CSV

DB Access History

CSV

DB Account Lock History

CSV

DB Access Control Logs

CSV

DML Snapshot

JSON

Restricted Data Access Logs (Legacy)

10.3.0

JSON

Masked Data Access Logs (Legacy)

10.3.0

JSON

Sensitive Data Access Logs (Legacy)

10.3.0

JSON

DAC Policy Audit Log

11.3.0

JSON

Server Access History

JSON

Command Audit

JSON

Session Logs

JSON

Server Access Control Logs

JSON

Server Role History

JSON

Server Account Lock History

JSON

Request Audit

JSON

Kubernetes Role History

JSON

Web App Access History

11.0.0

CSV

Web App Role History

11.0.0

CSV

Web App JIT Access Control Log

11.0.0

CSV

Web App Event Audit

11.0.0

CSV

Audit Log Export 목록 조회하기

Administrator > Audit > General > Audit Log Export

  1. Administrator > Audit > General > Audit Log Export 메뉴로 이동합니다.

  2. 현재까지 생성된 Audit Log Export 태스크 목록을 확인할 수 있습니다.

  3. Status 에서는 태스크의 진행 상태를 확인할 수 있습니다.

    • Processing : 감사 로그 추출이 진행 중입니다.

    • Completed : 감사 로그 추출이 완료되었으며, 파일 다운로드가 가능합니다. (추출 완료 후 30일이 경과하였다면, 파일이 만료되어 다운로드가 불가능합니다.)

    • Failed : 감사 로그 추출이 실패하였습니다. QueryPie Customer Support 를 통해 문의 바랍니다.

로그 추출 작업 생성하기

감사 로그 추출 및 다운로드는 크게 다음과 같은 단계로 진행됩니다. (1) 관련 메뉴 진입 → (2) 로그 추출 작업 생성 → (3) 로그 추출 완료까지 대기 → (4) 추출 완료 시 파일 다운로드

감사 로그 추출을 시작하기 위해서는 ‘Audit > General > Audit Log Export’ 메뉴 접근 후, 우측 상단의 Create Task 버튼을 클릭해야 합니다. 해당 버튼 클릭 시 아래와 같은 화면이 나타납니다.

Administrator > Audit > General > Audit Log Export > Create New Task

  1. Task Name: 로그 추출 작업의 이름을 입력합니다.

  2. Log Type: 추출 대상 로그의 종류를 선택합니다.

    1. Query Audit 등 추출하기 원하는 로그 타입을 선택합니다.

    2. 로그 종류 선택 후 See Log Template and Description을 클릭하면 각 로그의 key 등 상세 정보를 조회할 수 있습니다.

  3. Download File Format: 로그 출력 파일 형식을 지정합니다. (9.17.0 기준, 각 로그마다 다운로드 가능한 형식이 단일로 제한됩니다. 상단의 ‘추출 지원 로그 종류’ 을 참고해주시기 바랍니다.)

  4. For Text Exceeding 32,000 Characters : CSV 파일의 경우 32,000자를 초과하는 글자를 잘라낼지 여부를 선택할 수 있습니다.

    1. Trim Overflowing Text - 32,000자를 초과하는 글자를 잘라냅니다. Excel로 파일을 직접 열어야 하는 경우에 셀당 최대 글자수 초과로 표가 깨지는 현상을 방지합니다.

    2. No Action - 32,000자를 초과하는 글자를 그대로 포함시킵니다.

  5. From : 추출 시작 날짜를 지정합니다.

  6. To: 추출 대상 마지막 날짜를 지정합니다. 11.2.0부터 당일 날짜를 선택할 수 있도록 개선되었습니다.

  7. Filter Expression : 필터 표현식을 지정합니다.

    1. 조건 입력 방법 및 예시는 하단의 ‘필터 표현식’을 참고해주시기 바랍니다.

  8. Generate Preview: 미리보기를 생성합니다.

    1. 미리보기는 필수 단계입니다.

    2. 미리보기 결과를 확인해야 다음 단계인 ‘Create’가 가능합니다.

  9. Create 버튼 : 로그 추출 작업을 생성합니다.

유의 사항

당일 날짜를 선택하여 로그를 추출하는 경우, 실시간으로 데이터가 쌓이기 때문에 Preview 시점의 결과와 실제 Create를 통해 생성된 파일의 내용이 다를 수 있습니다.

note

필터 표현식

(1) 필터 표현식을 사용하기 위해 'See Log Template and Description'을 통해 로그별 key와 각각의 type 및 포함하는 value를 참고해주시기 바랍니다.

(2) 사용 가능한 필터 표현식은 데이터의 종류에 따라 아래와 같이 나뉩니다.

- Number Type

지원하는 표현식 : >, <, <=, >=, ==, !=
예 : x > `10`, x == `10`

- String Type

지원하는 표현식 : == (equals), != (not equals), contains
예 : x == 'abc', x != 'abc',
contains(x, 'ab')

- Boolean Type

지원하는 표현식 : == (equals), != (not equals), && (and), || (or)
예 : x == `true`, x && y,
(x > `0`) && (y == `0`)

- Array Type

예 : x[? @ == 'value'], list[? @ > `10`]

(3) 여러 조건을 함께 사용하기 위해 아래의 문자를 활용할 수 있습니다.

- AND 조건 : && 연산자를 활용합니다.

- OR 조건 : || 연산자를 활용합니다.

- 복합 조건 : 함께 처리해야 하는 조건은 괄호(( ))로 묶어서 활용합니다.

(4) 예시

- Query Audit 중 쿼리 실행 로그만 추출하려는 경우 필요한 표현식 : actionType == 'SQL_EXECUTION'

- Query Audit 중 웹에디터에 수행한 쿼리 실행 로그만 추출하려는 경우 필요한 표현식 : actionType == 'SQL_EXECUTION' && executedFrom == 'WEB_EDITOR'

- DB Access History 중 특정 데이터베이스 2종류에 대해서만 추출하려는 경우 필요한 표현식 : connectionName == 'database1' || connectionName == 'database2'

- DB Access History 중 특정 데이터베이스 2종류이면서 Replication Type이 SINGLE인 경우에 대해서만 추출하려는 경우 필요한 표현식 : (connectionName == 'database1' || connectionName == 'database2') && replicationType == 'SINGLE'

+

Overview

QueryPie에서 생성된 각종 감사 로그를 추출하고 csv 파일로 내려받을 수 있는 기능입니다. 장기간에 걸친 로그 등 대용량 파일인 경우에도 안정적인 추출 및 다운로드가 가능합니다. 한 번 생성된 로그 추출 파일은 30일 동안 다운로드가 가능합니다. 추출 지원 로그는 Query Audit, Workflow SQL Request 등 21종입니다.

Audit Log Export 기능 추가에 따라, 각 로그 화면에서 제공되던 ‘Excel File Download’ 버튼은 QueryPie v9.15.0부터 지원이 중단되었습니다.

추출 지원 로그 종류 (QueryPie v11.0.0 기준)

Log Type

Release Version

Format

Workflow DB Access Request

CSV

Workflow SQL Request

CSV

Workflow SQL Request for Query Details

CSV

Workflow SQL Export Request

CSV

Workflow Restricted Data Access Request

11.0.0

JSON

Workflow DB Policy Exception Request

11.0.0

JSON

Workflow Unmasking Request

11.0.0

JSON

Workflow Decryption Request

10.3.0

JSON

Workflow Server Access Request

JSON

Workflow Server Privilege Request

11.3.0

JSON

Workflow Access Role Request

10.0.0

CSV

IP Registration Request

11.0.0

JSON

User Access History

CSV

Admin Role History

CSV

Activity Logs

JSON

Alert Logs

10.3.0

JSON

Query Audit

CSV

DB Access History

CSV

DB Account Lock History

CSV

DB Access Control Logs

CSV

DML Snapshot

JSON

Restricted Data Access Logs (Legacy)

10.3.0

JSON

Masked Data Access Logs (Legacy)

10.3.0

JSON

Sensitive Data Access Logs (Legacy)

10.3.0

JSON

DAC Policy Audit Log

11.3.0

JSON

Server Access History

JSON

Command Audit

JSON

Session Logs

JSON

Server Access Control Logs

JSON

Server Role History

JSON

Server Account Lock History

JSON

Request Audit

JSON

Kubernetes Role History

JSON

Web App Access History

11.0.0

CSV

Web App Role History

11.0.0

CSV

Web App JIT Access Control Log

11.0.0

CSV

Web App Event Audit

11.0.0

CSV

Audit Log Export 목록 조회하기

Administrator > Audit > General > Audit Log Export

  1. Administrator > Audit > General > Audit Log Export 메뉴로 이동합니다.

  2. 현재까지 생성된 Audit Log Export 태스크 목록을 확인할 수 있습니다.

  3. Status 에서는 태스크의 진행 상태를 확인할 수 있습니다.

    • Processing : 감사 로그 추출이 진행 중입니다.

    • Completed : 감사 로그 추출이 완료되었으며, 파일 다운로드가 가능합니다. (추출 완료 후 30일이 경과하였다면, 파일이 만료되어 다운로드가 불가능합니다.)

    • Failed : 감사 로그 추출이 실패하였습니다. QueryPie Customer Support 를 통해 문의 바랍니다.

로그 추출 작업 생성하기

감사 로그 추출 및 다운로드는 크게 다음과 같은 단계로 진행됩니다. (1) 관련 메뉴 진입 → (2) 로그 추출 작업 생성 → (3) 로그 추출 완료까지 대기 → (4) 추출 완료 시 파일 다운로드

감사 로그 추출을 시작하기 위해서는 ‘Audit > General > Audit Log Export’ 메뉴 접근 후, 우측 상단의 Create Task 버튼을 클릭해야 합니다. 해당 버튼 클릭 시 아래와 같은 화면이 나타납니다.

Administrator > Audit > General > Audit Log Export > Create New Task

  1. Task Name: 로그 추출 작업의 이름을 입력합니다.

  2. Log Type: 추출 대상 로그의 종류를 선택합니다.

    1. Query Audit 등 추출하기 원하는 로그 타입을 선택합니다.

    2. 로그 종류 선택 후 See Log Template and Description을 클릭하면 각 로그의 key 등 상세 정보를 조회할 수 있습니다.

  3. Download File Format: 로그 출력 파일 형식을 지정합니다. (9.17.0 기준, 각 로그마다 다운로드 가능한 형식이 단일로 제한됩니다. 상단의 ‘추출 지원 로그 종류’ 을 참고해주시기 바랍니다.)

  4. For Text Exceeding 32,000 Characters : CSV 파일의 경우 32,000자를 초과하는 글자를 잘라낼지 여부를 선택할 수 있습니다.

    1. Trim Overflowing Text - 32,000자를 초과하는 글자를 잘라냅니다. Excel로 파일을 직접 열어야 하는 경우에 셀당 최대 글자수 초과로 표가 깨지는 현상을 방지합니다.

    2. No Action - 32,000자를 초과하는 글자를 그대로 포함시킵니다.

  5. From : 추출 시작 날짜를 지정합니다.

  6. To: 추출 대상 마지막 날짜를 지정합니다. 11.2.0부터 당일 날짜를 선택할 수 있도록 개선되었습니다.

  7. Filter Expression : 필터 표현식을 지정합니다.

    1. 조건 입력 방법 및 예시는 하단의 ‘필터 표현식’을 참고해주시기 바랍니다.

  8. Generate Preview: 미리보기를 생성합니다.

    1. 미리보기는 필수 단계입니다.

    2. 미리보기 결과를 확인해야 다음 단계인 ‘Create’가 가능합니다.

  9. Create 버튼 : 로그 추출 작업을 생성합니다.

유의 사항

당일 날짜를 선택하여 로그를 추출하는 경우, 실시간으로 데이터가 쌓이기 때문에 Preview 시점의 결과와 실제 Create를 통해 생성된 파일의 내용이 다를 수 있습니다.

note

필터 표현식

(1) 필터 표현식을 사용하기 위해 'See Log Template and Description'을 통해 로그별 key와 각각의 type 및 포함하는 value를 참고해주시기 바랍니다.

(2) 사용 가능한 필터 표현식은 데이터의 종류에 따라 아래와 같이 나뉩니다.

  • Number Type

지원하는 표현식 : >, <, <=, >=, ==, !=
예 : x > 10`, x == 10`

  • String Type

지원하는 표현식 : == (equals), != (not equals), contains
예 : x == 'abc', x != 'abc', contains(x, 'ab')

  • Boolean Type

지원하는 표현식 : == (equals), != (not equals), && (and), || (or)
예 : x == true`,x && y, (x > 0) && (y == 0)`

  • Array Type

예 : x[? @ == 'value'], list[? @ > 10]

(3) 여러 조건을 함께 사용하기 위해 아래의 문자를 활용할 수 있습니다.

  • AND 조건 : && 연산자를 활용합니다.

  • OR 조건 : || 연산자를 활용합니다.

  • 복합 조건 : 함께 처리해야 하는 조건은 괄호(( ))로 묶어서 활용합니다.

(4) 예시

  • Query Audit 중 쿼리 실행 로그만 추출하려는 경우 필요한 표현식 : actionType == 'SQL_EXECUTION'

  • Query Audit 중 웹에디터에 수행한 쿼리 실행 로그만 추출하려는 경우 필요한 표현식 : actionType == 'SQL_EXECUTION' && executedFrom == 'WEB_EDITOR'

  • DB Access History 중 특정 데이터베이스 2종류에 대해서만 추출하려는 경우 필요한 표현식 : connectionName == 'database1' || connectionName == 'database2'

  • DB Access History 중 특정 데이터베이스 2종류이면서 Replication Type이 SINGLE인 경우에 대해서만 추출하려는 경우 필요한 표현식 : (connectionName == 'database1' || connectionName == 'database2') && replicationType == 'SINGLE'

필터 표현식

(1) 필터 표현식을 사용하시기 위해 'See Log Template and Description'을 통해 로그별 key와 각각의 type 및 포함하는 value를 참고해주시기 바랍니다.

(2) 사용 가능한 필터 표현식은 데이터의 종류에 따라 아래와 같이 나뉩니다.

- Number Type

지원하는 표현식 : >, <, <=, >=, ==, !=
예 : x > `10`, x == `10`

- String Type

지원하는 표현식 : == (equals), != (not equals), contains
예 : x == 'abc', x != 'abc',
contains(x, 'ab')

- Boolean Type

지원하는 표현식 : == (equals), != (not equals), && (and), || (or)
예 : x == `true`, x && y,
(x > `0`) && (y == `0`)

- Array Type

예 : x[? @ == 'value'], list[? @ > `10`]

(3) 여러 조건을 함께 사용하기 위해 아래의 문자를 활용할 수 있습니다.

- AND 조건 : && 연산자를 활용합니다.

- OR 조건 : || 연산자를 활용합니다.

- 복합 조건 : 함께 처리해야하는 조건은 괄호(( ))로 묶어서 활용합니다.

(4) 예시

- Query Audit 중 쿼리 실행 로그만 추출하려는 경우 필요한 표현식 : actionType == 'SQL_EXECUTION'

- Query Audit 중 웹에디터에 수행한 쿼리 실행 로그만 추출하려는 경우 필요한 표현식 : actionType == 'SQL_EXECUTION' && executedFrom == 'WEB_EDITOR'

- DB Access History 중 특정 데이터베이스 2종류 대해서만 추출하려는 경우 필요한 표현식 : connectionName == 'database1' || connectionName == 'database2'

- DB Access History 중 특정 데이터베이스 2종류이면서 Replication Type이 SINGLE인 경우에 대해서만 추출하려는 경우 필요한 표현식 : (connectionName == 'database1' || connectionName == 'database2') && replicationType == 'SINGLE'

-

note

Query Audit의 내보내기 파일의 Privilege Type 명시 기준

내보내기 파일의 ‘Privilege Type’ 컬럼에는 실행 시점에는 어느 권한이 필요했는지가 기록됩니다. 아래와 같이 작동합니다.

  1. 기본 권한으로 실행되는 명령어(SET, SHOW 등)는 해당 컬럼의 값이 공백입니다.

  2. INSERT 등 권한에 따라 수행된 로그에는 SQL Type이 명시됩니다.

  3. Redis의 경우에는 커맨드명이 명시됩니다.

+

note

Query Audit의 내보내기 파일의 Privilege Type 명시 기준

내보내기 파일의 ‘Privilege Type’ 컬럼에는 실행 시점에는 어느 권한이 필요했는지가 기록됩니다. 아래와 같이 작동합니다.

  1. 기본 권한으로 실행되는 명령어(SET, SHOW 등)는 해당 컬럼의 값이 공백입니다.

  2. INSERT 등 권한에 따라 수행된 로그에는 SQL Type이 명시됩니다.

  3. Redis의 경우에는 커맨드명이 명시됩니다.

Query Audit의 내보내기 파일의 Privilege Type 명시 기준

내보내기 파일의 ‘Privilege Type’ 컬럼에는 실행시점에는 어느 권한이 필요했는지가 기록됩니다. 아래와 같이 작동합니다.

  1. 기본 권한으로 실행되는 명령어(SET, SHOW 등)는 해당 컬럼의 값이 공백입니다.

  2. INSERT 등 권한에 따라 수행된 로그에는 SQL Type이 명시됩니다.

  3. Redis의 경우에는 커맨드명이 명시됩니다.

추출 작업 완료 시 파일 내려받기

별도의 필터링 조건이 없는 단기간 조회의 경우에는 로그 추출이 몇 분 이내에 완료됩니다. 장기간에 걸친 로그이거나 필터링 조건의 복잡도가 높은 경우 등에서는 로그 추출까지 다소 시간이 소요될 수 있습니다.

추출 작업이 완료된 이후에는 두 가지 방법으로 로그 파일을 내려받을 수 있습니다.

  1. 목록 페이지에서 다운로드: 목록 페이지에서 Download 버튼을 클릭합니다.

  2. 상세 페이지에서 다운로드: 목록 페이지에서 태스크를 클릭하여 상세 페이지로 진입, 우측 상단 Download 버튼을 클릭합니다.

note

다운로드 파일에 암호 포함하기

다운로드 대상 파일은 ‘*.csv 또는 *.json 파일을 압축한 *.zip 파일’입니다.

해당 압축 파일에 대한 암호를 지정하기 위해서는 ‘General Setting > Security’ 메뉴에서 Export a file with Encryption 옵션을 ‘Required’로 지정해야 합니다.

다운로드 파일에 암호 포함하기

다운로드 대상 파일은 ‘*.csv 또는 *.json 파일을 압축한 *.zip 파일’입니다.

해당 압축 파일에 대한 암호를 지정하기 위해서는 ‘General Setting > Security’ 메뉴에서 Export a file with Encryption 옵션을 ‘Required’로 지정해야 합니다.

-

로그 추출 파일 보관 기간 정책 안내

추출이 완료된 로그 파일은 작업 생성일로부터 30일간 보관되며, 해당 기간 이내에는 횟수 제한 없이 내려받기가 가능합니다. 하지만 30일이 경과하면 파일이 만료됩니다. 만료된 로그 파일이 필요해진 경우, 로그 추출 태스크를 다시 생성해주시기 바랍니다.

+

로그 추출 파일 보관 기간 정책 안내

추출이 완료된 로그 파일은 작업 생성일로부터 30일간 보관되며, 해당 기간 이내에는 횟수 제한 없이 내려받기가 가능합니다. 하지만 30일이 경과하면 파일이 만료됩니다. 만료된 로그 파일이 필요해진 경우, 로그 추출 태스크를 다시 생성해주시기 바랍니다.

\ No newline at end of file diff --git a/confluence-mdx/tests/testcases/880181257/expected.reverse-sync.patched.xhtml b/confluence-mdx/tests/testcases/880181257/expected.reverse-sync.patched.xhtml index 20b66da62..5cd9f7e91 100644 --- a/confluence-mdx/tests/testcases/880181257/expected.reverse-sync.patched.xhtml +++ b/confluence-mdx/tests/testcases/880181257/expected.reverse-sync.patched.xhtml @@ -1 +1,12 @@ -26falsenonelisttrue

Custom Data Source 접근 요청

  1. 사용자 화면 상단 Workflow 메뉴로 이동합니다.

  2. 좌측 상단 Submit Request 버튼 클릭후 DB Access Request 항목을 선택합니다.

  3. Approval Rule을 상황에 맞게 설정하고 Title도 작성합니다.

  4. DB Connection 목록에서 Type이 'Custom Data Source'인 항목을 선택합니다.

  5. 다른 벤더들과 다르게 Privilege를 선택할 수 없기 때문에 “-”로 표기됩니다.

  6. Expiration Date과 Reason for Request 항목도 상황에 맞게 설정 및 작성합니다.

  7. 작성을 완료했다면 하단 Submit버튼을 클릭하여 신청을 완료합니다.

  8. 관리자의 승인을 받았다면 좌측 Workflow > Sent Request > Done 메뉴에서 확인할 수 있습니다.

Custom Data Source Type 외 다중 요청 시 주의사항

  • Custom Data Source와 다른 벤더를 함께 선택하는 경우 권한 타입이 다르기 때문에 일괄적으로 선택할 수 없습니다.

  • 이 경우 다음 메시지가 표시됩니다: "Privileges cannot be applied across different types at once (e.g., General, Redis, Custom Data Source). Please assign privileges separately for each connection."

  • 같은 권한 타입의 커넥션끼리는 일괄 적용이 가능합니다.


Agent를 통한 접속

  1. QueryPie Agent 실행

    • QueryPie Agent를 실행합니다.

    • Database 항목에서 Custom Data Source를 확인할 수 있습니다.

  2. Connection Guide 확인

    • Agent에서 Custom Data Source 커넥션 행을 클릭하면 Port 정보를 담은 행이 보입니다.

    • 위 행을 우클릭을 한뒤 Connection Guide를 클릭하면 접속 정보를 확인할 수 있습니다.

    • UID/PW는 수정할 수 없는 db username, db password로 표시됩니다.

    • Privileges는 "-"로 표시됩니다.

  3. SQL Tool에서 접속

    • DataGrip이나 기타 SQL Tool을 실행합니다.

    • Host와 Port는 Connection Guide에 명시되어있는 정보를 입력해야 합니다.

    • 벤더에 따라 추가 정보를 입력합니다.

주의사항

  • 관리자가 설정한 접근 가능 시간 외에 접속 시도 시 에러 메시지가 표시됩니다.

웹으로 접속 시도하는 경우

  1. 웹 커넥션 목록 확인

    • 사용자 화면 상단 Databases를 클릭합니다.

    • 좌측 커넥션 목록에서 QueryPie Connections를 클릭하면 접근 권한이 있는 Custom Data Source가 표시됩니다.

  2. 접속 불가 안내

    • Custom Data Source 선택 시 Connect 버튼이 비활성화됩니다.

    • 아래와 같은 툴팁이 표시되며 웹으로는 접속이 불가합니다.

      "Access is only possible through a proxy and cannot be accessed through the web. Please open the QueryPie Agent to connect to the Custom Data Source."

\ No newline at end of file +26falsenonelisttrue

Custom Data Source 접근 요청

  1. 사용자 화면 상단 Workflow 메뉴로 이동합니다.

  2. 좌측 상단 Submit Request 버튼 클릭후 DB Access Request 항목을 선택합니다.

  3. Approval Rule을 상황에 맞게 설정하고 Title도 작성합니다.

  4. DB Connection 목록에서 Type이 'Custom Data Source'인 항목을 선택합니다.

  5. 다른 벤더들과 다르게 Privilege를 선택할 수 없기 때문에 “-”로 표기됩니다.

  6. Expiration Date과 Reason for Request 항목도 상황에 맞게 설정 및 작성합니다.

  7. 작성을 완료했다면 하단 Submit버튼을 클릭하여 신청을 완료합니다.

  8. 관리자의 승인을 받았다면 좌측 Workflow > Sent Request > Done 메뉴에서 확인할 수 있습니다.

Custom Data Source Type 외 다중 요청 시 주의사항

  • Custom Data Source와 다른 벤더를 함께 선택하는 경우 권한 타입이 다르기 때문에 일괄적으로 선택할 수 없습니다.

  • 이 경우 다음 메시지가 표시됩니다: "Privileges cannot be applied across different types at once (e.g., General, Redis, Custom Data Source). Please assign privileges separately for each connection."

  • 같은 권한 타입의 커넥션끼리는 일괄 적용이 가능합니다.


Agent를 통한 접속

  1. QueryPie Agent 실행 +

    • QueryPie Agent를 실행합니다. +

    • Database 항목에서 Custom Data Source를 확인할 수 있습니다. +

  2. Connection Guide 확인 +

    • Agent에서 Custom Data Source 커넥션 행을 클릭하면 Port 정보를 담은 행이 보입니다. +

    • 위 행을 우클릭을 한뒤 Connection Guide를 클릭하면 접속 정보를 확인할 수 있습니다. +

    • UID/PW는 수정할 수 없는 db username, db password로 표시됩니다. +

    • Privileges는 "-"로 표시됩니다. +

  3. SQL Tool에서 접속 +

    • DataGrip이나 기타 SQL Tool을 실행합니다.

    • +Host와 Port는 Connection Guide에 명시되어있는 정보를 입력해야 합니다. +

    • 벤더에 따라 추가 정보를 입력합니다.

주의사항

  • 관리자가 설정한 접근 가능 시간 외에 접속 시도 시 에러 메시지가 표시됩니다.

웹으로 접속 시도하는 경우

  1. 웹 커넥션 목록 확인

    • 사용자 화면 상단 Databases를 클릭합니다.

    • 좌측 커넥션 목록에서 QueryPie Connections를 클릭하면 접근 권한이 있는 Custom Data Source가 표시됩니다.

  2. 접속 불가 안내

    • Custom Data Source 선택 시 Connect 버튼이 비활성화됩니다.

    • 아래와 같은 툴팁이 표시되며 웹으로는 접속이 불가합니다.

      "Access is only possible through a proxy and cannot be accessed through the web. Please open the QueryPie Agent to connect to the Custom Data Source."

\ No newline at end of file diff --git a/confluence-mdx/tests/testcases/883654669/expected.reverse-sync.patched.xhtml b/confluence-mdx/tests/testcases/883654669/expected.reverse-sync.patched.xhtml index 8e42b409e..446168c9c 100644 --- a/confluence-mdx/tests/testcases/883654669/expected.reverse-sync.patched.xhtml +++ b/confluence-mdx/tests/testcases/883654669/expected.reverse-sync.patched.xhtml @@ -1,4 +1,4 @@ -

Overview

Slack App을 QueryPie에 연동하고, QueryPie로부터 Direct Message 알림을 받기할 수 있습니다.

본 문서는 10.2.6 또는 그 이상의 버전 에 적용됩니다.

10.2.5 또는 그 이하 버전의 Slack 연동 방법은 10.1.0 버전 매뉴얼 문서를 참고해주세요.

12falsediscOverviewlisttrue

구성 시 사전에 필요한 권한

  • Slack Workspace 관리자 권한 계정 (Slack Workspace에 App을 설치하기 위해 필요)

  • QueryPie Owner 및 Approval Admin 권한 계정

Slack API 에서 DM App 생성 (via Manifest Files)

App Manifest를 이용하여 QueryPie DM 연동 전용 Slack App을 생성합니다.

  1. https://api.slack.com/apps 으로 이동하여 Create an App 을 클릭합니다.

  2. Create an app 모달에서, App 생성 방식을 선택합니다. From a manifest 를 클릭합니다.

  3. Pick a workspace 모달에서 QueryPie와 연동할 Slack Workspace를 선택한 뒤 다음 단계로 진행합니다.

  4. Create app from manifest 모달에서 JSON 형식의 App Manifest를 입력합니다.
    미리 채워져 있는 내용들을 삭제하고 아래의 App Manifest를 붙여넣은 뒤 다음 단계로 진행합니다.
    {{..}} 안의 값은 원하는 값으로 변경해 주세요.

    Overview

    Slack App을 QueryPie에 연동하고, QueryPie로부터 Direct Message 알림을 받기할 수 있습니다.

    본 문서는 10.2.6 또는 그 이상의 버전 에 적용됩니다.

    10.2.5 또는 그 이하 버전의 Slack 연동 방법은 10.1.0 버전 매뉴얼 문서를 참고해주세요.

    12falsediscOverviewlisttrue

    구성 시 사전에 필요한 권한

    • Slack Workspace 관리자 권한 계정 (Slack Workspace에 App을 설치하기 위해 필요)

    • QueryPie Owner 및 Approval Admin 권한 계정

    Slack API 에서 DM App 생성 (via Manifest Files)

    App Manifest를 이용하여 QueryPie DM 연동 전용 Slack App을 생성합니다.

    1. https://api.slack.com/apps 으로 이동하여 Create an App 을 클릭합니다.

    2. Create an app 모달에서, App 생성 방식을 선택합니다. From a manifest 를 클릭합니다.

    3. Pick a workspace 모달에서 QueryPie와 연동할 Slack Workspace를 선택한 뒤 다음 단계로 진행합니다.

    4. Create app from manifest 모달에서 JSON 형식의 App Manifest를 입력합니다.
      미리 채워져 있는 내용들을 삭제하고 아래의 App Manifest를 붙여넣은 뒤 다음 단계로 진행합니다.
      {{..}} 안의 값은 원하는 값으로 변경해 주세요.

    5. 설정 내용을 검토하고 Create 버튼을 클릭하여 App 생성을 완료합니다.

    Slack Workspace에 Slack App 설치

    1. Settings > Install App에서 Install to Workspace 버튼을 클릭하여 생성된 앱을 Slack Workspace에 설치합니다.

    2. 권한 요청 페이지에서, 허용을 클릭합니다.

    3. 설정한 Slack Workspace에서 Slack DM 전용 App이 생성된 것을 확인할 수 있습니다.

    Bot User OAuth Token 획득

    Features > OAuth & Permissions 메뉴 내 OAuth Tokens for Your Workspace 섹션에서, Bot User OAuth Token 을 복사하여 기록해 둡니다.

    App-Level Token 생성

    App manifest로 Slack app을 생성할 때 Socket Mode와 관련 권한들을 활성화할 수는 있지만, App Level Token(xapp-)은 자동으로 생성되지 않습니다.

    • App Level Token은 보안 자격 증명(security credential)이기 때문에 manifest로 자동 생성/노출되면 보안상 위험

    • App manifest는 앱의 구성(configuration)만 정의하고, 실제 인증 토큰들은 별도로 생성/관리됨

    다음 단계를 수행하여 App-Level Token을 수동으로 생성합니다.

    1. 앱 설정 페이지의 Settings > Basic Information 메뉴의 App-Level Tokens 섹션으로 이동하고, Generate Token and Scope 버튼을 클릭합니다.

    2. Generate an app-level token 모달에서, Add Scope 버튼을 클릭한 뒤 connections:write 를 추가합니다.

    3. 생성된 App-Level Token 모달에서, 앱 토큰을 복사하여 따로 기록해 둡니다. App-Level Token은 xapp- 으로 시작합니다.

    QueryPie에서 Slack DM 설정하기

    1. Admin > General > System > Integrations > Slack 메뉴로 진입한 뒤, Configure 버튼을 클릭하여 설정 모달을 엽니다.

      Administrator > General > System > Integrations > Slack > Create a New Slack Configuration

    2. 설정 모달에 아까 기록해둔 App Token과 Bot User OAuth Token을 입력합니다.

    3. 추가 설정 값은 다음과 같습니다. DM으로 Workflow 알림을 받고 메시지 안에서 승인/거절을 수행하려면 모든 설정 토글을 활성화 합니다.

      • Send Workflow Notification via Slack DM : 워크플로우 요청에 대한 Slack DM 전송 활성화

      • Allow Users to approve or reject on Slack DM : Slack DM 내에서 승인 또는 거절 기능 활성화

        액션 허용타입 예시 (좌) / 액션 비허용 타입 예시 (우)

    4. Save 버튼을 누르고 설정을 완료합니다.

    Slack DM 설정 관리하기

    1. Slack Configuration을 등록한 뒤, 현재 설정 상태를 화면에서 확인할 수 있습니다.

      Administrator > General > System > Integrations > Slack

    2. Edit 버튼을 클릭하여 입력한 설정을 변경할 수 있습니다.

      Administrator > General > System > Integrations > Slack > Edit the Slack Configuration

    Workflow 요청 시 Slack DM 테스트

    DB Access Request를 예시로, Slack DM 기능이 정상적으로 작동하는지 테스트를 수행합니다.

    1. QueryPie User > Workflow 페이지에서 Submit Request 버튼을 클릭한 뒤, DB Access Request를 선택하여 요청 작성 화면으로 진입합니다. 요청 작성 화면에서 필요한 정보를 입력하고, 요청을 상신합니다.

    2. 승인자는 앞에서 추가한 Slack App과의 DM으로 승인해야 할 요청 알림을 수신할 수 있습니다.
      Allow Users to approve or reject on Slack DM 설정이 켜져 있으므로, DM에서 직접 사유를 입력하고 요청을 승인 또는 거절할 수 있습니다.

    3. DM에서 Details 버튼을 클릭 시, QueryPie Admin에서 결재 요청에 대한 상세 내용을 확인하고 승인 또는 거절할 수 있습니다.

    +}]]>

  5. 설정 내용을 검토하고 Create 버튼을 클릭하여 App 생성을 완료합니다.

Slack Workspace에 Slack App 설치

  1. Settings > Install App에서 Install to Workspace 버튼을 클릭하여 생성된 앱을 Slack Workspace에 설치합니다.

  2. 권한 요청 페이지에서, 허용을 클릭합니다.

  3. 설정한 Slack Workspace에서 Slack DM 전용 App이 생성된 것을 확인할 수 있습니다.

Bot User OAuth Token 획득

Features > OAuth & Permissions 메뉴 내 OAuth Tokens for Your Workspace 섹션에서, Bot User OAuth Token 을 복사하여 기록해 둡니다.

App-Level Token 생성

App manifest로 Slack app을 생성할 때 Socket Mode와 관련 권한들을 활성화할 수는 있지만, App Level Token(xapp-)은 자동으로 생성되지 않습니다.

  • App Level Token은 보안 자격 증명(security credential)이기 때문에 manifest로 자동 생성/노출되면 보안상 위험

  • App manifest는 앱의 구성(configuration)만 정의하고, 실제 인증 토큰들은 별도로 생성/관리됨

다음 단계를 수행하여 App-Level Token을 수동으로 생성합니다.

  1. 앱 설정 페이지의 Settings > Basic Information 메뉴의 App-Level Tokens 섹션으로 이동하고, Generate Token and Scope 버튼을 클릭합니다.

  2. Generate an app-level token 모달에서, Add Scope 버튼을 클릭한 뒤 connections:write 를 추가합니다.

  3. 생성된 App-Level Token 모달에서, 앱 토큰을 복사하여 따로 기록해 둡니다. App-Level Token은 xapp- 으로 시작합니다.

QueryPie에서 Slack DM 설정하기

  1. Admin > General > System > Integrations > Slack 메뉴로 진입한 뒤, Configure 버튼을 클릭하여 설정 모달을 엽니다.

    Administrator > General > System > Integrations > Slack > Create a New Slack Configuration

  2. 설정 모달에 아까 기록해둔 App Token과 Bot User OAuth Token을 입력합니다.

  3. 추가 설정 값은 다음과 같습니다. DM으로 Workflow 알림을 받고 메시지 안에서 승인/거절을 수행하려면 모든 설정 토글을 활성화 합니다.

    • Send Workflow Notification via Slack DM : 워크플로우 요청에 대한 Slack DM 전송 활성화

    • Allow Users to approve or reject on Slack DM : Slack DM 내에서 승인 또는 거절 기능 활성화

      액션 허용타입 예시 (좌) / 액션 비허용 타입 예시 (우)

  4. Save 버튼을 누르고 설정을 완료합니다.

Slack DM 설정 관리하기

  1. Slack Configuration을 등록한 뒤, 현재 설정 상태를 화면에서 확인할 수 있습니다.

    Administrator > General > System > Integrations > Slack

  2. Edit 버튼을 클릭하여 입력한 설정을 변경할 수 있습니다.

    Administrator > General > System > Integrations > Slack > Edit the Slack Configuration

Workflow 요청 시 Slack DM 테스트

DB Access Request를 예시로, Slack DM 기능이 정상적으로 작동하는지 테스트를 수행합니다.

  1. QueryPie User > Workflow 페이지에서 Submit Request 버튼을 클릭한 뒤, DB Access Request를 선택하여 요청 작성 화면으로 진입합니다. 요청 작성 화면에서 필요한 정보를 입력하고, 요청을 상신합니다. +

  2. 승인자는 앞에서 추가한 Slack App과의 DM으로 승인해야 할 요청 알림을 수신할 수 있습니다.
    Allow Users to approve or reject on Slack DM 설정이 켜져 있으므로, DM에서 직접 사유를 입력하고 요청을 승인 또는 거절할 수 있습니다. +

  3. DM에서 Details 버튼을 클릭 시, QueryPie Admin에서 결재 요청에 대한 상세 내용을 확인하고 승인 또는 거절할 수 있습니다.

\ No newline at end of file