適用先
Microsoft 365 の SharePoint Microsoft 365 Small Business の SharePoint

作成者: Justin Joyce、LANtek

注: この記事は、SharePoint のエンド ユーザーを対象とする Get the Point ブログ (英語) で 4 年間にわたって集めた投稿の一部です。

概要:コードを使用しないカスタム エージング レポート

SharePoint サイトでよく要求される機能部分の 1 つは、タスクまたはリスト アイテムのいずれかのエージング レポートです。 つまり、リスト アイテムの最終更新日以降どれだけの日数または月数が経過したかということです。

この問題は表面的には非常に単純に見えます。 結局、アイテムの作成日および修正日があり、イベント レシーバーを介してアイテムに特定の変更が行われたときそのカスタム日付を格納する機能があります。 Excel のような数式を含めて情報に対して動作させることができる、計算列があります。 これは、非常に簡単な問題のように見えます。 日付フィールドを選択し、計算列を作成し、[DateField] – [Today] に似た数式の計算を行うことです。 でも、そんなに簡単にはいきません。 この "単純な" タスクを試みた人なら誰でも知っているように、計算列で [Today] のようなものを使用しようとすると問題が発生します。 計算列の数式ボックスに [Today] を挿入しようとすると、次のようなエラー メッセージが表示されます。

エラー メッセージ

それはなぜか。 まあ、計算列の計算方法と関係があります。

簡単な数式を例として見てみましょう。

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

これは、Column1 が Column2 以下の場合は [OK] を表示し、それ以外の場合は [OK] を表示します。 これは、計算列のかなり一般的な基本的な数式であり、これらの列を含むリスト アイテムに関する基本的な前提となります。Column1 と Column2 の値は、リスト アイテムの Update イベントなしでは変更できません。

つまり、計算対象の列は、計算する情報がアイテム自体に含まれていると見なされるため、一覧が更新 (または作成) されたときにのみ再計算されます。 これにより、今日の日付など、アイテムのフィールドとは無関係に変更される何かを使用しようとすると、問題が発生します。

今、私は彼らが計算列が機能する方法であると決めた会議にいませんでしたが、教育を受けた推測をする必要がある場合、私は彼らがパフォーマンスのためにこのように機能すると仮定します。 数千の項目のリストがあり、それぞれに "ライブ" 更新が必要な計算列が含まれていたとします。 つまり、タイマー ジョブであるメカニズムによっては、その計算列を含む各項目を頻繁に反復処理し、その値を更新する必要があります。 これは、大規模なデプロイでは、このジョブが常に実行され、変更される可能性があるため、パフォーマンスの面で非常に課税される可能性があります。 それは私の推測に過ぎませんが、考えるとかなり意味があります。

最初に Today という名前の列を作成し、それを数式に追加し、次いで削除して、Today の値を受け入れるように SharePoint をだます同様のソリューションの提案がいくつかあります。 これらはすべて問題ありませんが、計算列が更新されることについて私が説明したことを思い出してください。 この値は、アイテムの更新時にしか変更されず、これはつまり、値 (特に日にちにの計算) がすぐに不正になることを意味します。

私は賢いJavaScriptを使用してページに値を書き込む他の人を見てきました。 これでも機能しますが、私は使用しないで済むのであればクライアント スクリプトは使用しない方がよいと考えています。

実装:

それではどうすればよいのでしょうか。 計算列は、Today のような"volatile" 関数と呼ばれるため、問題外です。 計算列、タイマー ジョブ、スケジュール済みの処理などのカスタム コードを開発して、この計算を行う必要のあるすべてのアイテムを完全に更新させることも可能です。 その場合、前のパラグラフで触れたパフォーマンスの問題にまた戻ってきてしまい、加え、これは問題のサイト、リスト、列に固有なものとなってしまうため、もろいソリューションでもあります。 これらの 2 つの懸念に加え、私などのようなコードを作成できるオタクを見つけてきて、このソリューションを開発してくれるよう説得する必要もあります。 しかし、別の簡単な方法もあります。

サイトにフィールドを作成しページを編集する権限があり、XSLT とビューの作成に関する知識が少しある場合、リスト ビューに含めることができる XSL テンプレートを組み合わせて、ページの要求があるたびに値をきちんと計算させることができます。 このシナリオでは、パフォーマンスに対する懸念が解消され、ソリューションを介してカスタム コードを開発してデプロイする必要はありません。

完璧です。 では、これはどのようにすればよいのでしょうか。

  1. ソースとして動作するフィールドを作成または選択します。 これは Date 型である必要があります。

  2. 計算する値のプレースホルダーの役割を果たすフィールドを作成します。

  3. これらの 2 つのフィールドをコンテンツ タイプに追加し、そのコンテンツ タイプをリストに追加します。

  4. ソースとプレースホルダー列の両方を含むそのリストのビューを作成します。

  5. XSL テンプレートをスタイル ライブラリにアップロードします。

  6. UI を使用してリスト ビュー Web パーツの "XSL Link" プロパティを設定します。

  7. 成功です。

ユース ケースの例を調べ、実装について説明します。 Microsoft の顧客は、特定のリスト アイテムが状態に座っていた期間を示す、メインリストのビューを望んでいました。 このリストには、Item 型から派生し、リストに追加されたカスタム サイト コンテンツ タイプが含まれていました。 リスト アイテムの状態フィールドが変更され、その日付が "Date Status Changed" という列に保存されるたびにキャプチャするイベント レシーバーが既に存在していました。 この配線はすべて必須ではなく、任意の日付フィールドで行うことができます(これは実装ですが、自由に実験してください)。 リストに追加された計算を保持するために必要な最低限のソース日付フィールドとプレースホルダー フィールド (次の段落の詳細) ですが、サイト上の他の場所でこのソリューションを再利用する場合は、サイト列とサイト コンテンツ タイプを使用することをお勧めします。

そのため、今日の日付に対する計算で使用できるソース日付があります。 これで、計算値のコンテナーとして使用できるカスタム サイト列を作成できます。 この場合、計算列は新しいフォームや編集アイテムフォームでは変更できないため使用することを選択しましたが、ユーザーがこの列に任意の値を入力したくないので、ビューに表示するように選択できます。 ビューに表示されないなど理由がわからなくなる可能性があります。

これでサイト列があるので、リストで使用するコンテンツ タイプに追加できます。 次に、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 行目までスクロールし続けた場合、マークアップに追加したカスタム テンプレートの先頭が表示されます。最初のテンプレートは "DateDiff" テンプレートの後に "calculate-julian-day" と "FieldRef_printTableCell_EcbAllowed.Days_x0020_At_x0020_Status" になります。 これらは、ビューで計算を行って表示する 3 つのテンプレートです。 この記事で前に指定したフィールド名とは異なるフィールド名を使用する場合は、これらのテンプレートを参照し、他の名前への参照を置き換える必要があります。 そのためには、表示名ではなくフィールドの INTERNAL 名を使用する必要があります。

テンプレートの準備ができたら、スタイル ライブラリに移動し、[XSL スタイル シート] フォルダーの下にアップロードし、ファイルへのリンクをコピーします。 これにより、後で楽に変更したり、お好みでサイトの別の部分に追加することができます。

次いで、リストに移動し、この記事で既に作成したビューを選択します。 [サイトの操作] メニューから [ページの編集] をクリックします。

[サイトの操作] メニューの [ページの編集]

ページでリスト ビュー Web パーツを探し、右上隅の小さい下向き矢印をクリックして、Web パーツ メニューを開きます。 このメニューから [Web パーツの編集] を選択します。

[Web パーツ] メニューの [Web パーツの編集] コマンド

これにより、ブラウザー ウィンドウの右側に Web パーツのメニューが開きます。

[Web パーツ] メニュー

[その他] セクションの [+] をクリックし、"XSL Link" プロパティを見つけます。

[Web パーツ] メニューの [XSL リンク] プロパティ

前にコピーしたスタイル ライブラリ内の XSL ファイルへのリンクを貼り付けます (相対または絶対リンクが可能です)。

貼り付けられた XSL ファイル リンク

[OK] をクリックして変更を保存し、ページの上部にある [ページ] リボンの [編集を停止] ボタンをクリックします。

[ページ] タブの [編集の終了] ボタン

すべてが正しく構成されている場合は、[状態の日] 列に数値が表示されます。

数値が表示される [状態の日数] 列

最後に、さまざまな日付のいくつかのテスト データがどのように示されるかの例を次に示します。

テスト データが表示されたエイジング レポート

概要​​:

このようにすれば、コードを実装せずに、きちんとフォーマットされた、堅固で、よりよく機能する SharePoint の完全なエージング レポートを作成することができます。 これには、ここでのユース ケース以外に可能なアプリケーションがいくつかあります。 この種類のレポートのもう 1 つの一般的なシナリオは、タスクが一目で作成されてからの時間を確認できるようにタスク リストに添付することです。

最新機能をご利用ください。

--Justin

Justin Joyce、LANtek

コメント

手順がありません 2012/10/8 午前 3:51 OK 私は手順に従ったが、何かが欠けている必要がある - XSLは、使用する日付、または以降の日数を追加するフィールドをどのように知るのでしょうか? ステップが見逃された場合、それを嫌う。

No-Code、agreed! 2012/8/30 午後 12:12 私は同意する - 私はこれが本当に"コードなし"としてカウントされないと思います。興味深いことに、SharePoint のいくつかのねじ込みによって、今日を使用して計算列が動作しています...私は再びそれを行うためにそれを得ることができないので、方法や理由がわからないが、1つはまだそこにあり、働いている。

"状態の日" 計算列の数式? 2012/5/2 午前 7:39 Justin - "Days At Status" の計算サイト列 (プレースホルダー列) に使用した数式は何ですか? "=today" でしたか?

SharePoint 2007 2011/12/2 11:29 am 現在、私はこのソリューションを SharePoint 2007 に適用しようとしていませんが、私はそれを探しています。 残念ながら、UI の Web パーツに XslLink プロパティが表示されません。

素晴らしい投稿 2011/11/30 午前 9:53 Hello, 素晴らしい投稿。SharePoint 2007 を使用しています。私は上記のようにその他のセクションを持っていません。SP2007 構成の手順はありますか? ありがとうございます。

Re: コードなしソリューション: SharePoint リスト アイテムが最後に変更されてからの日数を表示します 2011/10/11 午前 8:24 こんにちはクリス。素晴らしい発見! 私はあなたが今日の後半にうまくいけば投稿したものを見て、私はこのソリューションをもう少し堅牢にすることができるかどうかを確認するつもりです。私はあなたが投稿を気に入ってうれしいです、そして私はあなたがヨーロッパの日付形式の解決策を見つけることができたことをとてもうれしいです。 :) -ジャスティン

ヨーロッパの日付形式のソリューション 2011/10/11 午前 6:45 こんにちは再びジャスティン, FYI では、このページで前述した問題の解決策を見つけました。https://sharepointbydummies.wordpress.com/2011/07/13/possible-work-around-to-date-format-issue-sharepoint-2010/

ヨーロッパの日付形式 2011 年 10 月 7 日午前 3 時 59 分 Hi Justin, これは本当に良い解決策のおかげで、私は最後の2日間を探して過ごしてきたようなものです! しかし、私はそれに少し問題を抱えていると私はあなたが私を助けることができると思っていました。"DateDiff" 関数の最後の行の変数を切り替えることによって、何かが起こるまでの日数を計算するようにコードを少し変更しました。 <xsl:value-of select="$JulianToday - $JulianStartDate"></xsl:value-of> しかし、私は違いを正しく半分の時間を結び付けるためにそれを得ることができるだけです。 したがって、たとえば、この日付 (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)"/> これにより、2 番目の日付の問題が修正されましたが、最初の日付では正しくありませんでした また、ヨーロッパの LCID を使用するように FormatDateTime 呼び出しを変更し、FormatDateTime の最後のパラメーター (例: ddMMyyyy、MMddyyyy) に対するさまざまな変更を、サブ文字列の位置指定パラメーターに適切な調整を加えて成功しませんでした。私はあなたが提供できる任意のアドバイスを大いに感謝します。ありがとう, クリス

コードなし 2011/9/21 午前 4:27 XSL言語を理解することはすべての人のためのものではありませんが、プログラミングを伴わないので、XSLが"コードなし"ソリューションとして適格であるとは思いません。 それに加えて:素敵な解決策、あなたに感謝!

ヘルプを表示

その他のオプションが必要ですか?

サブスクリプションの特典の参照、トレーニング コースの閲覧、デバイスのセキュリティ保護方法などについて説明します。