オプティミスティック コンカレンシー例外をユーザーに説明するための適切な言葉を考え出そうとしています。思っていたよりずっと難しいことがわかりました。私がこれまでに持っている最高のものは次のとおりです。
他の誰かが、あなたが作業していたレコードを既に変更しています。それらの新しい値を以下に示します。行った変更をやり直してください。
これは私にはちょっとくだらないと感じます。彼らはもっと良いものでなければなりません。何かご意見は?
オプティミスティック コンカレンシー例外をユーザーに説明するための適切な言葉を考え出そうとしています。思っていたよりずっと難しいことがわかりました。私がこれまでに持っている最高のものは次のとおりです。
他の誰かが、あなたが作業していたレコードを既に変更しています。それらの新しい値を以下に示します。行った変更をやり直してください。
これは私にはちょっとくだらないと感じます。彼らはもっと良いものでなければなりません。何かご意見は?
あなたのケースで技術的に実現可能かどうかはわかりませんが、次の情報はユーザーにとって役立つと考えられます。
この「顧客」レコードへの変更は保存できません。
これは、ユーザー「aliceb」が変更したためです。変更をやり直す必要があります。フィールド「住所」と「名前」が更新されます。
どうですか。
作業中のレコードは別のユーザーによって変更されています。このレコードの新しい値を以下に示します。行った変更は保存されていません。再送信してください。
競合するフィールドと同様に、変更を行った以前のユーザーがわかっている場合は、それも提供してください。ユーザーはメッセージの意味を完全に認識しているかもしれませんが、誰が変更を行ったかを知ることは、彼らに連絡して自分の変更がより関連性があるかどうかを確認できるようにするのに役立ちます。
メッセージはおそらくエンドユーザーにとって意味のあるものになると思います-彼らは技術的なものですか、それとも非技術的なものですか(概念を非常に認識しています)、役立つビジネス用語はありますか?
対象となる 4 つのシナリオがあることに注意してください。
これに照らして、単一のメッセージが必要な場合は、これを試してください:
別のユーザーがレコードを更新または削除したため、操作は失敗しました。変更は失われました。再試行する前に、変更内容を確認してください。
特定の条件に基づいてメッセージのいくつかのバリエーションを提供し、可能であれば、他のユーザーが誰であるかを伝えることは、さらに優れています (ただし、より多くの作業が必要です)。
ユーザーエクスペリエンスも考慮する必要があります。
削除はグリッドから行われることが多いため、シナリオ 1 (更新/更新) を除いて、「新しい値が下に表示されます」と言うのは適切ではない場合があります。
また、シナリオ 2 (更新/削除) は、おそらくユーザーを新しいフォームにリダイレクトする必要があるため、注意が必要です。そうではなく、更新したいレコードが削除された場合、何を表示しますか?
シナリオ 4 (削除/削除) は、ほぼ間違いなく無視できます。他の誰かがあなたを打ち負かしたので、何ですか?
このレコードは別のユーザーによって変更されました。変更を保存するには <> または <> を押して、最新の更新を取得します。