SystemUpdate()で承認時のコメントが消える…
タイトルの通りです。
アイテムのバージョンや更新日、承認状態等を変えずにアイテムを更新出来るSystemUpdateメソッドですが、これを行うと承認時のコメントが消えてしまうことが判明…(TдT)
Update()の場合は、承認済み(or却下)から承認待ちに変わるので承認時のコメントが消えるのは分かりますが。
仕方がないので、承認時のコメントはセットし直します。。。
SPListItem item = ***;
string comme = item.ModerationInformation.Comment;
item["列名"] = "更新する値";
item.SystemUpdate();
item.ModerationInformation.Comment = comme;
item.SystemUpdate();
アイテムのバージョンや更新日、承認状態等を変えずにアイテムを更新出来るSystemUpdateメソッドですが、これを行うと承認時のコメントが消えてしまうことが判明…(TдT)
Update()の場合は、承認済み(or却下)から承認待ちに変わるので承認時のコメントが消えるのは分かりますが。
仕方がないので、承認時のコメントはセットし直します。。。
SPListItem item = ***;
string comme = item.ModerationInformation.Comment;
item["列名"] = "更新する値";
item.SystemUpdate();
item.ModerationInformation.Comment = comme;
item.SystemUpdate();
スポンサーサイト
BreakRoleInheritanceメソッドの不思議
SPWeb myWeb = ***;
SPListItem item = ***;
myWeb.AllowUnsafeUpdates = true;
item.BreakRoleInheritance(false);
としたら「このページのセキュリティの検証は正しくありません」というエラーが発生しました。
BreakRoleInheritanceはアイテムの権限の継承を外すというメソッド。
http://msdn.microsoft.com/ja-jp/library/ms441135(v=office.12).aspx
引数falseで、全ユーザー&グループも全て削除します。
(trueなら継承を外すだけ)
このエラーが発生したあとの権限は、継承が外れただけの状態でした。
継承を外して、ユーザー(グループ)を削除しようかなって時にエラーになったと思われます。
たぶんコレですね。
http://sharepointyuzuki.blog54.fc2.com/blog-entry-9.html
ちなみにシステムアカウントで実行した場合は同じコードを実行してもエラーにはなりません。
システムアカウントに偽装した場合にだけ発生しました。
仕方がないので、継承をはずしてから1個ずつ外す。
SPWeb myWeb = ***;
SPListItem item = ***;
myWeb.AllowUnsafeUpdates = true;
item.BreakRoleInheritance(true);
myWeb.AllowUnsafeUpdates = true;
SPRoleAssignmentCollection roleColl = item.RoleAssignments;
for (int i = roleColl.Count - 1; i >= 0; i--)
{
roleColl.Remove(roleColl[i].Member);
}
…ついでにいつもやってしまうエラー(笑)
foreach (SPRoleAssignment role in item.RoleAssignments)
{
item.RoleAssignments.Remove(role.Member);
}
エラー:Collection was modified; enumeration operation may not execute
追記
色々見てたら見つけた。
なるほど。こうでも良いのか。
while(item.RoleAssignments.Count > 0)
{
item.RoleAssignments.Remove(0);
}
SPListItem item = ***;
myWeb.AllowUnsafeUpdates = true;
item.BreakRoleInheritance(false);
としたら「このページのセキュリティの検証は正しくありません」というエラーが発生しました。
BreakRoleInheritanceはアイテムの権限の継承を外すというメソッド。
http://msdn.microsoft.com/ja-jp/library/ms441135(v=office.12).aspx
引数falseで、全ユーザー&グループも全て削除します。
(trueなら継承を外すだけ)
このエラーが発生したあとの権限は、継承が外れただけの状態でした。
継承を外して、ユーザー(グループ)を削除しようかなって時にエラーになったと思われます。
たぶんコレですね。
http://sharepointyuzuki.blog54.fc2.com/blog-entry-9.html
ちなみにシステムアカウントで実行した場合は同じコードを実行してもエラーにはなりません。
システムアカウントに偽装した場合にだけ発生しました。
仕方がないので、継承をはずしてから1個ずつ外す。
SPWeb myWeb = ***;
SPListItem item = ***;
myWeb.AllowUnsafeUpdates = true;
item.BreakRoleInheritance(true);
myWeb.AllowUnsafeUpdates = true;
SPRoleAssignmentCollection roleColl = item.RoleAssignments;
for (int i = roleColl.Count - 1; i >= 0; i--)
{
roleColl.Remove(roleColl[i].Member);
}
…ついでにいつもやってしまうエラー(笑)
foreach (SPRoleAssignment role in item.RoleAssignments)
{
item.RoleAssignments.Remove(role.Member);
}
エラー:Collection was modified; enumeration operation may not execute
追記
色々見てたら見つけた。
なるほど。こうでも良いのか。
while(item.RoleAssignments.Count > 0)
{
item.RoleAssignments.Remove(0);
}
アイテムを承認したときの更新者と更新日
あけましておめでとうございます!(遅すぎですね。。)
今年もよろしくお願い致しますm(__)m
今年もSharePoint2007の情報をボチボチと発信していきたいと思います。
興味のある方はお付き合い下さい。
では、さっそくリストとライブラリで困る現象。
アイテムを承認した時、更新者列と更新日列の値は以下のようになります。
【リスト】
更新者 =承認したユーザー
更新日時=承認した日時
【ライブラリ】
更新者 =変更なし
更新日時=承認した日時
ん~~( -人-).。oO
リストとライブラリで動作が違うのは何でや!と言うのは置いといて、と言うかそういうもんだと諦めて(笑)。
この動作って結構困りますよね。。。
承認者の名前が残るのはモチロン重要です。
承認=アイテムの更新な訳なので、更新者列に名前が残るのも理解できるのですが…。
でも、最新Verのアイテムの中身を書いた人&日時も重要ですよね~。
Ver変わらず更新者が書き換えられてしまったら、本当の更新者が分からなくなってしまうと言う…。
カスタムワークフローを使用しているリストでは、その辺は別の列を作ってうまくやっていますが。。
更新者列みたく、承認者列・承認日列ってのが元々あっても良いと思うのです。
SharePoint2010では改善されてるのかな…。
…導入の予定は当分ありませんけどね(TдT)
今年もよろしくお願い致しますm(__)m
今年もSharePoint2007の情報をボチボチと発信していきたいと思います。
興味のある方はお付き合い下さい。
では、さっそくリストとライブラリで困る現象。
アイテムを承認した時、更新者列と更新日列の値は以下のようになります。
【リスト】
更新者 =承認したユーザー
更新日時=承認した日時
【ライブラリ】
更新者 =変更なし
更新日時=承認した日時
ん~~( -人-).。oO
リストとライブラリで動作が違うのは何でや!と言うのは置いといて、と言うかそういうもんだと諦めて(笑)。
この動作って結構困りますよね。。。
承認者の名前が残るのはモチロン重要です。
承認=アイテムの更新な訳なので、更新者列に名前が残るのも理解できるのですが…。
でも、最新Verのアイテムの中身を書いた人&日時も重要ですよね~。
Ver変わらず更新者が書き換えられてしまったら、本当の更新者が分からなくなってしまうと言う…。
カスタムワークフローを使用しているリストでは、その辺は別の列を作ってうまくやっていますが。。
更新者列みたく、承認者列・承認日列ってのが元々あっても良いと思うのです。
SharePoint2010では改善されてるのかな…。
…導入の予定は当分ありませんけどね(TдT)
3つ以上のソートの条件を指定したビューを作成する方法
ビューにソート条件は2つしか設定できません。

フィルタ条件は3つ以上出来るのに…。
って訳で、Designerを使ってやってみました。
コード画面からListViewWebPartパーツのコードを探します。
↓こんな感じの所。
-------------------------------------------------------------------------------------------
<WebPartPages:ListViewWebPart ~~~~
~~~~~~
~~~~~~
~~~~~~
<ListViewXml xmlns="http://schemas.microsoft.com/WebPart/v2/ListView">~~①ごちゃごちゃ~~
-------------------------------------------------------------------------------------------
編集するのは①の辺り。
<Query> って所があります。
エンコードされているので「< = <」「> = >」と変換して読みます。
つまり<Query>。
クエリが書いてあるところです。フィルタとかソートとか。
<OrderBy><FieldRef Name="ID"/></OrderBy>
とあれば
<OrderBy><FieldRef Name="ID"/></OrderBy>
って事でID昇順と言う条件です。
ここに第二条件以降を書き足す。
例:ID昇順、field1昇順、field2降順
<OrderBy><FieldRef Name="ID"/><FieldRef Name="field1"/><FieldRef Name="field2" Ascending="FALSE"/></OrderBy>
クエリの書き方についてはここを参考に。
http://msdn.microsoft.com/ja-jp/library/ms467521.aspx
ページを保存します。
完成!
この方法でビューの条件を変更しても、ブラウザからビューの条件を変更すると、この条件は消えてしますのでご注意を。

フィルタ条件は3つ以上出来るのに…。
って訳で、Designerを使ってやってみました。
コード画面からListViewWebPartパーツのコードを探します。
↓こんな感じの所。
-------------------------------------------------------------------------------------------
<WebPartPages:ListViewWebPart ~~~~
~~~~~~
~~~~~~
~~~~~~
<ListViewXml xmlns="http://schemas.microsoft.com/WebPart/v2/ListView">~~①ごちゃごちゃ~~
-------------------------------------------------------------------------------------------
編集するのは①の辺り。
<Query> って所があります。
エンコードされているので「< = <」「> = >」と変換して読みます。
つまり<Query>。
クエリが書いてあるところです。フィルタとかソートとか。
<OrderBy><FieldRef Name="ID"/></OrderBy>
とあれば
<OrderBy><FieldRef Name="ID"/></OrderBy>
って事でID昇順と言う条件です。
ここに第二条件以降を書き足す。
例:ID昇順、field1昇順、field2降順
<OrderBy><FieldRef Name="ID"/><FieldRef Name="field1"/><FieldRef Name="field2" Ascending="FALSE"/></OrderBy>
クエリの書き方についてはここを参考に。
http://msdn.microsoft.com/ja-jp/library/ms467521.aspx
ページを保存します。
完成!
この方法でビューの条件を変更しても、ブラウザからビューの条件を変更すると、この条件は消えてしますのでご注意を。
ドキュメントライブラリで困る現象
理解は出来るけど困る事。
よくある(笑)バグだと言いたい謎の現象と言うわけではないんですが(´ヘ`;)
以下のようなファイルがあるとします。
①Aさんがアップロードしたけれど、まだチェックインしていないファイル(例:test.txt)
②カスタム権限を設定してAさんは閲覧できるが、Bさんは閲覧出来ないファイル(例:test.txt)
Aさんで見るとこう。

当然Bさんでは、どちらのファイルも存在を確認する事はできません。

この状態でBさんが同じ名称のファイルをアップロードするとどうなるか。
①のチェックインされていないファイルの場合

②の権限のないファイルの場合

他人がチェックアウト中のファイルは上書き保存できない。
権限のないファイルは上書き保存できない。
って言うのは、我々の立場では理解できますが、Bさんにしてみたら「何で?!」ってなりますよね。。。
こう、もう一歩かゆい所に手が届いていると助かるんですけどね( -人-).。oO
よくある(笑)バグだと言いたい謎の現象と言うわけではないんですが(´ヘ`;)
以下のようなファイルがあるとします。
①Aさんがアップロードしたけれど、まだチェックインしていないファイル(例:test.txt)
②カスタム権限を設定してAさんは閲覧できるが、Bさんは閲覧出来ないファイル(例:test.txt)
Aさんで見るとこう。

当然Bさんでは、どちらのファイルも存在を確認する事はできません。

この状態でBさんが同じ名称のファイルをアップロードするとどうなるか。
①のチェックインされていないファイルの場合

②の権限のないファイルの場合

他人がチェックアウト中のファイルは上書き保存できない。
権限のないファイルは上書き保存できない。
って言うのは、我々の立場では理解できますが、Bさんにしてみたら「何で?!」ってなりますよね。。。
こう、もう一歩かゆい所に手が届いていると助かるんですけどね( -人-).。oO