2011-05-11 41 views
3

我們已經開發了多個控件的自定義web部件並將其部署到SharePoint 2010的網站,其中接受輸入從用戶,一旦用戶點擊提交按鈕所有的值存儲在其中一列是超鏈接的共享點列表中。當用戶點擊這個超鏈接時,通過查詢字符串,他將重新定向到同一個表單。防止多個用戶在SharePoint編輯同一個列表項2010

我想知道用戶是否點擊了這個超鏈接來製作這個表單的版本,我們可以避免另一個用戶更改這個表單嗎?

請在此分享您的看法。

回答

4

如果我正確理解你的問題,你想阻止更多的用戶編輯列表項目,如果有人已經編輯它。可以使用一些類型的鎖,可能存儲在列表本身來完成,但是這種策略從兩個重要缺陷所害:

  • 認爲第一用戶點擊鏈接切換到編輯模式,我們鎖定列表項。如果用戶只是關閉瀏覽器,而不進行任何進一步的(或他的網絡出現故障,或者他的系統崩潰,或他的電腦死了),該項目將保持鎖定別人將編輯它,直到我們發佈防止它以某種方式(通常在一段時間之後,或者在網頁部分之外修改它)。

  • 我們的Web部件將強制執行該鎖定,但不會有其他代碼執行此操作,包括SharePoint本身(通過其他Web部件或服務器端代碼)和整個外部世界(通過客戶端對象模型)。因此,在用戶編輯它時,任何給定的列表項目仍然易於改變,並且如果發生這種情況,SPListItem.Update()仍然會引發異常。

一個更好的策略是使用SharePoint的自己的鎖定機制,通過檢查的項目時,第一個用戶切換到編輯模式,當然,僅啓用如果該項目沒有已簽出的鏈接。

然而,這並不能解決揮之不去的鎖定問題(我們檢查的項目回來,如果用戶關閉瀏覽器?)。此外,CheckOut()SPFile實現的,而不是SPListItem,這意味着你必須使用一個文檔庫,從該功能中受益。總而言之,我不認爲有一個真正用戶友好的解決方案來解決您的問題:您要麼讓用戶同時編輯同一個項目並處理後果(只有其中一個獲勝),或者你不這樣做,你可能會留下陳舊的鎖(每個人都會失去)。

+1

當有人使用UI,而另一個用戶編輯並保存更改,而他們正在編輯,保存界面後會提醒他們衝突。 – 2011-05-11 20:53:33

+1

@brian,假設你在談論臭名昭着的「保存衝突」。您的更改與另一個用戶消息同時發生的更改衝突,這是SharePoint自己的方式來處理問題(通過捕獲由'SPListItem.Update()'拋出的異常)。該消息還會告訴您刷新頁面並重新提交您的更改,從而重新加載衝突列表項,然後再次嘗試自己更新它。當然,仍然不能保證某件事情在你做之前不會再次更新該項目*,如果發生這種情況,你會回到原點。 – 2011-05-11 21:07:15

0

您可以使用SharePoint中的簽出/簽入機制。

1

用途和檢查,然後結賬具有清除已鎖定超過設定的時間更多的鎖的工作流...

相關問題