적용 대상
Microsoft 365의 SharePoint Microsoft 365 Small Business의 SharePoint

작성자: Justin Joyce, LANtek

참고: 이 문서는 SharePoint 최종 사용자에 대한 지점 가져오기 블로그의 4년 게시물 모음에 속합니다.

개요: 코드가 없는 사용자 지정 노화 보고서

SharePoint 사이트의 자주 요청되는 기능 중 하나는 작업 또는 목록 항목에 대한 노화 보고서입니다. 즉, 이 목록 항목이 마지막으로 수정된 이후의 일/월은 몇 개월입니까?

표면상으로는 매우 간단한 요청인 것 같습니다. 결국, 생성 및 수정되는 항목에 대한 날짜가 있으므로 이벤트 수신기를 통해 항목에 대한 특정 변경 내용이 발생하는 경우 사용자 지정 날짜를 저장할 수 있습니다. Excel과 유사한 수식을 포함하여 정보를 사용할 수 있는 계산 열이 있습니다. 이것은 꽤 똑바로 제안처럼 보인다. 날짜 필드를 선택하고 계산 열을 만든 다음 [DateField] – [오늘]의 줄을 따라 수식을 만듭니다. 아, 하지만 너무 빠르지 않아! 이 "간단한" 작업을 시도한 사람은 누구나 알고 있듯이 계산 열에서 [Today]와 같은 작업을 사용하려고 하면 문제가 발생합니다. 계산 열의 수식 상자에 [오늘]을 삽입하면 다음과 같은 오류 메시지가 표시됩니다.

오류 메시지

왜 이것인가요? 계산 열이 계산되는 방식과 관련이 있습니다.

간단한 수식을 예로 들어 보겠습니다.

= IF( [Column1]<=[Column2], "OK", "Not OK")

이 모든 것은 Column1이 Column2보다 작거나 같으면 확인을 표시하고 그렇지 않으면 NOT OK를 표시한다는 것입니다. 계산 열에 대한 일반적인 기본 수식이며 이러한 열이 포함된 목록 항목에 대한 기본 가정이 됩니다. Column1 및 Column2의 값은 목록 항목의 Update 이벤트 없이는 변경할 수 없습니다.

맞습니다. 계산 열은 계산하는 정보가 항목 자체에 포함되어 있다고 가정하므로 목록이 업데이트되거나 생성될 때만 다시 계산됩니다. 이렇게 하면 오늘 날짜와 같이 항목의 필드와 관계없이 변경되는 항목을 사용하려고 할 때 문제가 발생합니다.

지금은 그들이 계산 열이 작동하는 방식이라고 결정한 회의에 참석하지 않았지만, 교육을 받은 추측을 해야한다면 성능을 위해 이런 식으로 작동한다고 가정할 것입니다. "라이브" 업데이트가 필요한 계산 열이 각각 포함된 수천 개의 항목 목록이 있다고 상상해 보십시오. 즉, 타이머 작업일 수 있는 일부 메커니즘은 계산 열이 포함된 각 항목을 자주 반복하고 해당 값을 업데이트해야 합니다. 더 큰 배포를 사용하면 이 작업이 지속적으로 실행되고 변경될 수 있으므로 성능 측면에서 매우 부담이 될 수 있습니다. 그건 그냥 내 추측, 하지만 그것은 당신이 그것에 대해 생각 하는 경우 꽤 의미가.

SharePoint를 속여 Today라는 열을 먼저 만든 다음 수식에 추가한 다음 삭제하여 Today 값을 수락하도록 속이는 유사한 솔루션에 대한 몇 가지 제안이 있습니다. 이들은 모두 잘 좋은,하지만 계산 열이 업데이트 될 때 내가 말한 것을 기억하십시오. 이 값은 항목이 업데이트될 때만 변경되며, 이는 특히 하루 계산의 경우 값이 곧 올바르지 않음을 의미합니다.

다른 사용자가 영리한 JavaScript를 사용하여 페이지에 값을 쓰는 것을 보았습니다. 이것은 또한 작동하지만, 나는 그것을 피할 수있는 경우 클라이언트 스크립트에 대해 거의 명백하게입니다.

이행:

그렇다면 어떻게 해야 할까요? 계산된 열은 Today와 같은 소위 "volatile" 함수에 대한 문제에서 벗어났습니다. 계산 열, 타이머 작업 또는 예약된 프로세스와 같이 이를 처리하기 위한 몇 가지 사용자 지정 코드를 개발하여 이 계산이 필요한 모든 단일 항목을 업데이트할 수 있습니다. 이렇게 하면 지난 단락에서 언급한 성능 문제가 다시 발생하며, 또한 문제의 사이트/목록/열과 매우 관련이 있는 부서지기 쉬운 솔루션입니다. 그 두 가지 문제 외에도, 당신은 또한 코딩하고 당신을 위해이 솔루션을 개발하기 위해 그를 설득하는 방법을 알고, 나 같은 괴상한 사람을 찾아야 할 것입니다. 그러나 더 쉬운 방법이 있습니다!

사이트에서 필드를 만들고 페이지를 편집할 수 있는 권한이 있고 XSLT 및 뷰 만들기에 대한 지식이 있는 경우 목록 보기에 포함할 수 있는 XSL 템플릿을 조합하여 페이지가 요청될 때마다 값을 충실하게 계산할 수 있습니다. 이 시나리오는 성능에 대한 우려를 제거하고 솔루션을 통해 사용자 지정 코드를 개발하고 배포할 필요가 없습니다.

완벽합니다. 그렇다면 어떻게 해야 할까요?

  1. 원본 역할을 할 필드를 만들거나 선택합니다. 날짜 형식이어야 합니다.

  2. 계산되는 값의 자리 표시자 역할을 하는 필드를 만듭니다.

  3. 이러한 두 필드를 콘텐츠 형식에 추가하고 해당 콘텐츠 형식을 목록에 추가합니다.

  4. 원본 열과 자리 표시자 열을 모두 포함하는 해당 목록의 보기를 만듭니다.

  5. 스타일 라이브러리에 XSL 템플릿을 업로드합니다.

  6. UI를 통해 목록 보기 웹 파트에 대한 "XSL 링크" 속성을 설정합니다.

  7. 성공!

예제 사용 사례를 살펴보고 구현을 살펴보겠습니다. 고객은 특정 목록 항목이 상태 얼마나 오래 앉아 있었는지 알려주는 기본 목록을 보고 싶었습니다. 이 목록에는 항목 유형에서 파생되어 목록에 추가된 사용자 지정 사이트 콘텐츠 형식이 포함되어 있습니다. 목록 항목의 상태 필드가 변경되고 해당 날짜를 "날짜 상태 변경됨"이라는 열에 저장할 때마다 를 캡처하는 이벤트 수신기가 이미 있습니다. 이 모든 배선은 필요하지 않으며 모든 날짜 필드로 수행할 수 있습니다(구현이지만 자유롭게 실험할 수 있음). 사이트의 다른 위치에서 이 솔루션을 다시 사용하려는 경우 사이트 열 및 사이트 콘텐츠 형식을 사용하는 것이 좋습니다. 하지만 최소한 원본 날짜 필드와 자리 표시자 필드가 목록에 추가된 계산(다음 단락에서 자세히 설명)을 보관하는 것입니다.

따라서 오늘 날짜에 대한 계산에 사용할 수 있는 원본 날짜가 있습니다. 이제 계산된 값의 컨테이너로 사용할 사용자 지정 사이트 열을 만들 수 있습니다. 이 경우 새 항목 또는 편집 항목 양식에서 변경할 수 없으므로 계산 열을 사용하도록 선택했지만 사용자가 이 열에 임의의 값을 입력하지 않도록 하므로 보기에 표시되도록 선택할 수 있습니다. 보기 등에 표시되지 않는 이유에 대해 혼동될 수 있습니다.

이제 사이트 열이 있으므로 목록에서 사용할 콘텐츠 형식에 추가할 수 있습니다. 다음으로, 나중에 XSLT를 사용하여 사용자 지정할 뷰를 만들어야 합니다. 원본 날짜 열과 계산된 값의 자리 표시자 역할을 하는 새 계산 열을 포함하는 표준 뷰를 만들어야 합니다.

이제 사용자 지정 노화 보고서를 지원하는 데 필요한 모든 것이 준비되었습니다. 남은 것은 XSL 템플릿을 만들고, 사이트의 스타일 라이브러리에 업로드하고, 목록 보기에 연결하는 것입니다. 사용할 XSL 템플릿에는 보기를 생성하기 위한 몇 가지 일반적인 SharePoint 생성 태그와 이 부분의 특정 부분을 재정의하고 원하는 값을 계산하는 데 사용되는 사용자 지정 태그가 포함됩니다.

크레딧이 기한인 경우 크레딧을 제공하면서 이 솔루션에 사용 중인 실제 계산을 수행하기 위한 XSL 템플릿은 MSDN 포럼에서 "swirch"에 의해 정중하게 제공되었습니다:http://social.msdn.microsoft.com/Forums/en-US/sharepointcustomization/thread/aeda905b-9bc6-40c4-bd22-21306c5cb0d2/

여기에 있는 XSL 스타일시트(aging.zip)를 다운로드합니다.https://OneDrive.live.com/?cid=c262e8e2d59a86d9&permissionsChanged=1&id=C262E8E2D59A86D9!104

즐겨 찾는 텍스트 편집기에서 이 항목을 열면 보기를 렌더링하기 위한 일반적인 SharePoint XSL 태그가 많이 표시됩니다. 357줄까지 계속 스크롤하면 태그에 추가한 사용자 지정 템플릿의 시작이 표시되며, 첫 번째 템플릿은 "calculate-julian-day" 및 "FieldRef_printTableCell_EcbAllowed.Days_x0020_At_x0020_Status"가 뒤에 오는 "DateDiff" 템플릿입니다. 이 세 가지 템플릿은 계산을 만들고 뷰에 표시합니다. 이 문서의 앞부분에서 지정한 것과 다른 필드 이름을 사용하려는 경우 이러한 템플릿을 살펴보고 다른 이름에 대한 참조를 바꿔야 합니다. 이를 위해 표시 이름이 아닌 필드의 INTERNAL 이름을 사용하려고 합니다.

템플릿이 준비되면 스타일 라이브러리로 이동하여 "XSL 스타일시트" 폴더 아래에 업로드한 다음, 파일에 대한 링크를 복사합니다. 이렇게 하면 나중에 쉽게 변경하거나 원하는 대로 사이트의 다른 부분에 추가할 수 있습니다.

다음으로 목록으로 이동하여 이 문서의 앞부분에서 만든 보기를 선택합니다. "사이트 작업" 메뉴에서 "페이지 편집"을 클릭합니다.

사이트 작업 메뉴에 있는 페이지 편집 명령

페이지에서 목록 보기 웹 파트를 찾고 오른쪽 위 모서리에 있는 작은 아래쪽 화살표를 클릭하여 웹 파트 메뉴를 엽니다. 이 메뉴에서 "웹 파트 편집"을 선택합니다.

웹 파트 메뉴의 웹 파트 편집 명령

그러면 브라우저 창의 오른쪽에 웹 파트 메뉴가 열립니다.

웹 파트 메뉴

"기타" 섹션의 +를 클릭하고 "XSL 링크" 속성을 찾습니다.

웹 파트 메뉴의 XSL 링크 속성

이전에 복사한 스타일 라이브러리의 XSL 파일에 대한 링크를 붙여넣습니다(상대 링크 또는 절대 링크일 수 있습니다).

붙여 넣은 XSL 파일 링크

"확인"을 클릭하여 변경 내용을 저장한 다음 페이지 위쪽의 "페이지" 리본에서 "편집 중지" 단추를 클릭합니다.

페이지 탭의 편집 중지 단추

모든 항목이 올바르게 구성된 경우 이제 "상태의 일" 열에 숫자가 표시됩니다.

상태 일수 열에 숫자 표시

마지막으로, 다양한 날짜의 일부 테스트 데이터와 함께 다음과 같이 표시됩니다.

테스트 데이터를 표시하는 에이징 보고서

요약:

SharePoint에서 에이징 보고서를 만드는 좋은 형식의 강력하고 더 나은 성능의 방법이 있습니다. 간단한 코드 없는 구현을 완료합니다. 여기서 살펴보던 한 가지 사용 사례 외에 몇 가지 잠재적인 애플리케이션이 있습니다. 이러한 유형의 보고서에 대한 또 다른 일반적인 시나리오는 작업 목록을 작업 목록에 첨부하여 작업이 만들어진 이후의 기간을 한눈에 확인할 수 있도록 하는 것입니다.

사용을 즐겨 보세요!

--저스틴

저스틴 조이스, LANtek

메모

누락된 단계 2012년 10월 8일 오전 3:51 확인 단계를 수행했지만 누락된 항목이 있어야 합니다. XSL에서 사용할 날짜 또는 이후 날짜를 추가할 필드를 어떻게 알 수 있나요? 단계가 누락되면 싫어합니다.

코드 없음, 동의했습니다! 2012년 8월 30일 오후 12:12 나는 동의합니다 - 나는 이것이 정말로 "코드 없음"으로 계산되지 않는다고 생각합니다.흥미롭게도, SharePoint의 일부 나사를 통해, 나는 오늘을 사용하여 작업 계산 열을 가지고 ... 나는 그것을 다시 할 수 없기 때문에 어떻게 또는 왜 확실하지 않지만, 하나는 여전히 거기에 있고 일하고 있습니다.

"상태의 일" 계산 열에 대한 수식은? 2012년 5월 2일 오전 7:39 Justin - "Day At Status" 계산된 사이트 열(자리 표시자 열)에 사용한 수식은 무엇인가요? "=오늘"인가요?

SharePoint 2007 2011년 12월 2일 오전 11:29 현재 SharePoint 2007에 이 솔루션을 적용하려고 시도하지는 않지만 찾고 있습니다. 아쉽게도 UI를 통해 웹 파트에 XslLink 속성이 표시되지 않습니다.

그레이트 포스트 2011년 11월 30일 오전 9:53 안녕하세요 위대한 게시물.SharePoint 2007을 사용하고 있습니다.위에서 설명한 대로 Misc 섹션이 없습니다.SP2007 구성에 대한 단계가 있나요? 감사합니다.

Re: 코드 없는 솔루션: SharePoint 목록 항목이 마지막으로 변경된 날짜 표시 2011년 10월 11일 오전 8:24 안녕하세요 크리스.좋은 발견! 오늘 나중에 게시한 내용을 살펴보고 이 솔루션을 좀 더 강력하게 만들 수 있는지 알아보겠습니다.나는 당신이 게시물을 좋아 기뻐요, 나는 당신이 유럽 날짜 형식에 대한 해결책을 찾을 수 있었다 매우 기쁘다. :) -저스틴

유럽 날짜 형식에 대한 솔루션 2011년 10월 11일 오전 6:45 안녕하세요 다시 저스틴, 참고로, 이 페이지에서 이전에 언급한 문제에 대한 해결책을 찾았습니다.https://sharepointbydummies.wordpress.com/2011/07/13/possible-work-around-to-date-format-issue-sharepoint-2010/

유럽 날짜 형식 2011년 10월 7일 오전 3:59 안녕하세요 저스틴, 이것은 정말 좋은 솔루션 감사, 그리고 그냥 종류의 내가 찾고 지난 이틀을 보냈다! 그러나 나는 그것에 약간의 문제가 있어 그리고 난 당신이 나를 도울 수 있기를 바랐다."DateDiff" 함수의 마지막 줄에 있는 변수를 전환하여 문제가 발생할 때까지 일 수를 계산하도록 코드를 약간 변경했습니다. <xsl:value-of select="$JulianToday - $JulianStartDate"></xsl:value-of> 그러나 나는 단지 시간의 절반을 올바르게 차이를 선인장에 얻을 수 있어. 따라서 이 날짜가 있는 instance(dd/MM/yyyy 형식) 2011년 30월 12일 올바르게 계산되지만 이 날짜(동일한 형식)로 계산됩니다. 2011년 12월 10일 2011년 10월 12일이 아닌 2011년 12월 10일인 것처럼 계산됩니다."JulianStartDate" 변수에서 일 및 월 값의 위치를 전환하려고 했습니다. <xsl:with-param name="Month" select="substring(ddwrt:FormatDateTime(string($StartDate), 1033, 'yyyyMMdd'),7,2)"/> <xsl:with-param name="Day" select="substring(ddwrt:FormatDateTime(string($StartDate), 1033, 'yyyyMMdd'),5,2)"/> 그리고 이것은 두 번째 날짜의 문제를 해결, 그러나 그것은 첫 번째 날짜에 대한 잘못된 다음이었다! 또한 FormatDateTime 호출을 변경하여 유럽 LCID 및 다양한 변경 사항을 FormatDateTime의 마지막 매개 변수(예: ddMMyyyyy, MMddy)로 변경하고 부분 문자열 위치 매개 변수를 성공적으로 조정했습니다.나는 당신이 제공 할 수있는 조언을 크게 주셔서 감사합니다.감사 크리스

코드 없음 2011년 9월 21일 오전 4:27 XSL 언어를 이해하는 것이 모든 사람을 위한 것은 아니지만 프로그래밍을 포함하지 않기 때문에 XSL이 "코드 없음" 솔루션으로 자격이 있다고 생각하지 않습니다. 그 외에 : 좋은 솔루션, 감사합니다!

도움이 더 필요하세요?

더 많은 옵션을 원하세요?

구독 혜택을 살펴보고, 교육 과정을 찾아보고, 디바이스를 보호하는 방법 등을 알아봅니다.