内部ユーザーと外部ユーザーで分けてアクセス権を設定できる。
「公開/参照のみ」で更新権限を与えたい場合、SharingRuleで追加する。
「公開/参照・更新可能」にした場合、これ以上権限を広げる事はできない
Customer CommunityではExperience Cloud特有の機能である、共有セットや共有グループを使って、レコード共有を制御する。
自分が所属する取引先の子供のレコードは見れても良いという思想。
3階層以上ある場合、レコード作成時にプロセスビルダーやフローで取引先を参照するようにすれば、共有可能になる場合もある。
参照のみの設定はなく、必ず編集権限を内部ユーザーに与える事になる。
ライセンスによってスーパーユーザーの設定方法と機能が異なるの注意
取引先にのみ使用可能。
テリトリーといっても、住所だけでなく、業種のような住所以外のくくりも可能。
取引先もユーザーも複数のテリトリーのくくりに所属可能
暗黙的とはいっても、実際はロールの設定で、どのようなアクセス権を付与するかを決めるので、明示的ともいえる。
自分と自分の所属する取引先は参照出来るという思想。見せたくない項目がある場合、項目レベルセキュリティーで制御する。
独自の理由を設定しておくと、デバッグで分かりやすくなる。
独自の理由を設定しておくことで、所有者変更でも共有が解除されず柔軟な開発が出来る。
逆に独自の理由を所有者変更時に削除したい場合、プログラムで削除する作りこみを行う必要がある。
Apexだけでなく、フローでもShareオブジェクトにレコードの作成と削除が可能なので、独自の理由を設定する事が可能
面接官を指定した時、Shareオブジェクトにレコード作成するプログラムを作り事で実現できる。
この場合、応募者レコードの所有者が変わっても面接官のアクセス権を残したい場合、RowCauseをManualから独自の理由にすればよい。
Apexコードはその組織の最高権限で実行される。実行者の権限で実行して良い場合は、セキュリティーの為に出来るだけその実行者で実行する様にする。
With sharingはそのClassの中では共有ルールを考慮して実行される。
Without Sharingは、そのClassの中では共有ルールを無視して実行される。
Without Sharingで共有ルールを適用する事ができるが、オブジェクトや項目への権限は制限していない。スキーマクラスを使って、権限を確認してコーディングする事が出来る。しかしこれはコーディングが大変なので、with sechurity_enforceやstripInaccessibleを使うと便利。
テストでのみ使えるメソッドとなる。
ロール変更は処理に時間がかかる場合がある。
取引先の子供を更新する場合、データ整合性を保つため、取引先をロックする。取引先のロックを10秒待っても取得できないとUnable_to_lockエラーが発生する。
例:BtoCでダミーの取引先を作って、大量の個人取引先を取引先責任者として登録している場合
要するに一つの親レコードに大量の子レコードをぶら下げるなという事。目安は10,000レコード以内。
共有ルールの適用の延期は大量データをロードする場合にも適用すると良い。
ロールは組織図と同じでなくてもよい。
工事不要!契約期間縛りなし!【GMOとくとくBB光】月額3,430円(税込3,773円)〜!
コメント