첫번쨰 프로젝트의 ShipToParty 관련 정리를 마친 후

해당 내용에 대한 문의를 발송했는데

특이하게도 배송지를 제외한 거래처 부분은 SoldToParty를 적용해야 했다.

 

다행히 기존 코드를 그대로 사용하기 때문에 추가 수정 부분은 없었고

그 다음 자동화 스케줄 작동 기록을 확인했는데

아쉽게도(?) 전날 추가된 데이터가 없어서 스케줄 배치로 돌아간 내역은 없었고

저번부터 문제였던 게스트유저가 수락, 거절등의 행동을 한 경우

담당자에게 알림 메일이 가는 부분을 수정할 시간이 되었는데

프로필에 들어가서 시스템 권한 부분의 Send Email을 설정해도 메일이 가지 않았고

Process Automation -> Workflow Rules을 설정하고

Process Automation -> Workflow Actions → Email Alerts을 작성하라는 부분이 있었는데

Email Alerts를 생성한 다음 WorkFlow를 생성하려고 보니

이제 지원하지 않는다고 하며 Flow로 넘어가버렸다.

 

flow에서라도 잘 작동하면 문제는 없겠지만

flow 내부에서도 동일한 “invalid cross reference id”문제가 발생했는데

결국 게스트 유저의 권한 때문에 Send Email 시스템 권한이 부여되고

Workflow Action의 Email Alerts를 설정해서 보내도 의미가 없었다.

 

마침내 해결책을 발견할 수 있었는데

그냥 클래스에서 without sharing을 사용하는 것 처럼

이메일 템플릿 태그 내부에 renderUsingSystemContextWithoutSharing="True”를 추가하면 해결할 수 있었다..

<messaging:emailTemplate **renderUsingSystemContextWithoutSharing="True"** subject="{!IF(relatedTo.Status__c == 'A', relatedTo.Name + ' - A State', relatedTo.Name + ' - B State')}" recipientType="User" relatedToType="ObjectApi">
    <messaging:htmlEmailBody >
        <html> 
            <body> 
                Dear {!relatedTo.Owner.Name}
								
									내용	
	
                Thank you 
            </body> 
        </html> 
    </messaging:htmlEmailBody> 
</messaging:emailTemplate>

 

해당 코드가 수정된 후

다시 첫번째 프로젝트로 돌아가 리스트뷰를 수정해 uat와 운영서버가 같은 목록을 보게 변경했고

리스트뷰 외에 검색 레이아웃(Search Layouts)도 수정해서 기본적으로 같은 필드들이 보이게 했다.

 

권한을 확인하던 도중 들어오지 않은 부분들에 대해서는

해당 담당자분에게 전달해서 권환 확인을 요청해두고

다시 두번쨰 프로젝트 이메일 알림 쪽으로 돌아왔다.

 

이메일 알림이 개발서버에서 전송되는 부분까지는 복구했지만

운영에 바로 적용하는 것이 아니라 개발에서 적용된 부분을 운영으로 올려야 하는 방식이기 때문에

템플릿, Email Alert, 플로우, 변경된 기존 Ttigger 등을 운영으로 배포한 다음

그래도 작동하지 않아 확인해보니 해당 Sites의 프로필 권한에 Send Email을 체크해서

이메일이 정상 작동하는 부분까지 확인할 수 있었다.

 

도중에 레코드 유형을 바꾸면 flow 권한 문제가 발생할 수 있다고 했지만

전혀 문제가 발생하지 않아서 의아했었는데

알고보니 flow도 수동 생성이 아닌 배포 방식으로 가져왔기 때문에

기존에 적용한 설정이 그대로 남아있어서 권한설정이 없어도 가능한 것이었다.

 

원래는 아래와 같이 flow 내부에서 설정을 변경해야 한다.

Flow -> 버전 속성 편집 -> 고급 표시 -> 플로 실행 방법 공유를 사용하지 않는 시스템 컨텍스트 - 모든 데이터에 엑세스

주요 프로필들의 권한을 확인하고

최종적으로 레이아웃을 변경한 다음 해당 내용을 전달했는데

충격적이게도 권한이 부여된 프로필 하나 대신 다른 프로필을 넣어야 한다고 하고

전체 프로필들에도 읽기 권한을 줘야 한다고 전달받았다.

 

기존 권한에서 읽기 외의 권한을 제거하지만

빌더 등의 상호작용과 내가 관여하지 않은 개체들이 존재해서 상당히 혼란스러웠다.

 

또한 레코드 유형 관련해서도 추가 설정을 진행해야 하는 부분이 있었는데

프로필 -> 레코드 유형 및 페이지 레이아웃 할당 수정으로 기본값 및 새로만들기 선택으로

해당 개체에서 새로만들기를 선택할 때 선택 옵션이 나오지 않고

지정한 레코드 유형으로만 생성할 수 있는 설정도 필요했다.

 

 

(1).백준 25756번 방어율 무시 계산하기는 해당 퍼센트의 비율의 방어도를 무시할 때

현재 방어 무시율이 어떻게 중가되고 있는지를 계산해야 하는 문제였다.

 

재미있게도 무시 확률만 주어지고 감소된 퍼센트를 곱하는 방식이 아니기 때문에

100에서 해당 비율을 더한 다음 100으로 나눈 값을 곱해줘서 값을 구해주고

해당 값을 다시 100에서 뺀 값으로 현재 방어 무시율을 계산했다.

 

이후에도 계속해서 무시율이 곱연산으로 적용되기 때문에

같은 과정을 반복하며 매 과정마다 result에 값을 저장해두고

문제 포맷에 맞게 줄바꿈으로 출력했다.

const input = `5
20 20 20 20 20`.split('\n')[1].split(' ').map(Number)

const result = []
let point = 100
for(let i = 0 ; i < input.length ; i++){
    point *= (100 - input[i]) /100 
    result.push(100-point)
}

console.log(result.join('\n'))

'회고' 카테고리의 다른 글

[개발일지] - 154(연차)  (1) 2023.12.01
[개발일지] - 153  (0) 2023.11.30
[개발일지] - 151  (0) 2023.11.28
[개발일지] - 150  (1) 2023.11.27
[개발일지] - 149(주말)  (0) 2023.11.26

+ Recent posts