日本語の情報は案あまり見ないです。
- erpws.fflib_SecurityUtils.CrudException: You do not have permission to view scheduled jobs.
- DLRS throwing an error of UNABLE_TO_LOCK_ROW
Error Occurred: The flow tried to update these records: 500Rh000001Gu0yIAC. This error occurred: CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY: dlrs_CaseTrigger: execution of AfterUpdate caused by: System.DmlException: Update failed. First exception on row 1 with id 005Dn000008LCU8IAO; first error: CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY, erpws.UserTrigger: execution of AfterUpdate caused by: erpws.fflib_SecurityUtils.CrudException: You do not have permission to view scheduled jobs. (erpws): [] (dlrs) Trigger.dlrs_CaseTrigger: line 7, column 1.
The error you mentioned is due to a recent Certinia update (Summer '23). It is a flaw in their update and they have prepared a fix in Summer 2023.1 SP1. We've had the same error, but a different use case. User records could not be updated by Community User that created them. Their workaround was granting permission to 'View Scheduled Jobs', but that didn't work for us. I advise you to create a support ticket with Certinia/FinancialForce to have them deploy the SP1 to your org,
あなたが指摘したエラーは、最近の Certinia アップデート (Summer '23) が原因です。これはアップデートの欠陥であり、Summer 2023.1 SP1 で修正が準備されています。同じエラーが発生しましたが、使用例は異なります。ユーザー レコードを作成したコミュニティ ユーザーはユーザー レコードを更新できませんでした。彼らの回避策は「スケジュールされたジョブの表示」権限を付与することでしたが、私たちにはうまくいきませんでした。 Certinia/FinancialForce でサポート チケットを作成し、SP1 を組織に導入してもらうことをお勧めします。
I can explain what is happening, long story short we borrow a session from the UI and use it to talk to the Salesforce API's from the server, thus it is a different IP address than the client's browser that originated the session.
I can say the team is actively working on some alternative workflows, watch this space over the next month or two.
何が起こっているのか説明できます。簡単に言えば、UI からセッションを借用し、それを使用してサーバーから Salesforce API と通信するため、セッションを開始したクライアントのブラウザとは異なる IP アドレスになります。
チームはいくつかの代替ワークフローに積極的に取り組んでいると言えます。今後 1 ～ 2 か月間この分野に注目してください。
WHERE は指定しなくてもよさそう
Error:
Relationship Criteria: Relationship Criteria 'WHERE Name NOT LIKE 'Inspectie%'' is not valid, see SOQL documentation http://www.salesforce.com/us/developer/docs/soql_sosl/Content/sforce_api_calls_soql_select_conditionexpression.htm, error is 'unexpected token: 'WHERE''
Please check this article.
https://github.com/SFDO-Community/declarative-lookup-rollup-summaries/issues/697
レコードタイプでの検索
Rollup Helper
- Rollup Helper - The Trusted, Scalable, Roll-Up Engine for Salesforce
- 実行モードは、手動実行のみとオブジェクトトリガーがすでに有効になっていることを示しています
- RollupHelperをアンインストールできません
MISSING LABEL PropertyFile - val WorkflowLogOnlyException_desc not found in section Exception : INTERNAL_ERROR ()
基準としたいトリガで起動するFlowを作ってその中からDLRSをキックすることで回避したようです。
相対日付
- Creating a Roll-Up Summary Field using "Smart Date" Filters
- DLRS query- Status = 'Fundraiser' AND Campaign_Name__c = '%example%' AND CreatedDate = LAST_N_MONTHS:12
- DLRS-相対日付が機能しない
Error
FIELD_CUSTOM_VALIDATION_EXCEPTIONは、レコードの処理中にカスタムエラーが発生したことを示すエラーメッセージです。これは、検証ルール、またはこの場合はApexトリガーのいずれかです。
-
FIELD_CUSTOM_VALIDATION_EXCEPTION、アカウントの検証エラー：ロールアップヘルパーは親レコードを更新できません
-
"We can't save this record because the "Assign Case Closed By User" process failed.
Error: Active: Apex Trigger dlrs_ContactTrigger has not been deployed. Click Manage Child Trigger and try again.
It's Setup > Custom Metadata Types > Lookup Rollup Summary then to left of that click the Manage Records link. Then I edited the particular rollup and set Active = True.
The Manage Lookup Rollup Summaries page is basically the UI for creating/editing these metadata records.
Directly setting Active = True on the metadata record won't work though if the trigger wasn't already deployed. In my case we already had a Contact to Account rollup and in Setup > Apex Triggers I could see that the trigger that the Managed Lookup Rollup Summaries page claims does not exist does in fact exist. So all I needed to do was get Active = True on the new rollup.
「ルックアップ ロールアップ概要の管理」ページは、基本的に、これらのメタデータ レコードを作成/編集するための UI です。
ただし、トリガーがまだデプロイされていない場合、メタデータ レコードに Active = True を直接設定しても機能しません。私の場合、取引先責任者から取引先へのロールアップがすでにあり、[設定] > [Apex トリガー] で、管理検索ロールアップ概要ページに存在しないと主張されているトリガーが実際に存在することがわかりました。したがって、必要なのは、新しいロールアップで Active = True を取得することだけでした。
-
子トリガーをデプロイしてデータをnpsp__Allocation__cからOpportunitiesにロールアップしようとすると、エラーが発生します。
-
Salesforce Metadata API connection failure, click link below to configure
After some digging it turns out I had to add the Modify Metadata Through Metadata API Functions permission and that resolved the issue.
いくつか調べた結果、メタデータ API 関数を使用してメタデータを変更する権限を追加する必要があることがわかり、これで問題は解決されました。
you have exceeded the maximum number (100) of apex scheduled jobs
積み上げ集計項目
次の場所で積み上げ集計項目を作成します。
- 主従関係の主側にあるカスタムオブジェクト
- カスタムオブジェクトとの主従関係の主側にあるすべての標準オブジェクト
- 関連する商談商品の値を使用する商談
- 関連する商談の値を使用する取引先
- キャンペーンメンバーの状況またはキャンペーンメンバーのカスタム項目の値を使用するキャンペーン
ただし、ロールアップサマリーを使用してアカウントに関連する連絡先をカウントすることはできません（多くの人は機会の例外のみを理解していません）： Roll-up Summary Fields for Account - Contact Standard Relationship
dlrs パッケージをアンインストールできない
最後に、Workbench と破壊的な変更 xml スキーマを使用して Prod から厄介な dlrs トリガーを削除することができた
これが、パッケージのインターフェイスを介して DLRS ロールアップを削除し、同じ UI を使用して関連付けられているトリガーを削除しないというばかげた間違いを犯した私のような他の人に役立つことが判明した場合は、これをどのように機能させたかを示します。
私の手順:
- アンインストールを妨げていた同じ DLRS クラスとトリガーを持つアクティブなサンドボックスが既にあったため、サンドボックスで非アクティブ化するために必要な TRIGGER を編集しました。
- トリガーのステータスをアクティブから非アクティブに変更しました。
- 次に 、トリガーのアクティブな部分 (削除前、挿入前などのステートメントの後の実際のコマンドを含むビット) をコメントアウトしました。コマンドの前 に /** と * を追加することで、その部分をコメントアウトできます。 */ コマンドの後 （これにより、トリガーが実行された場合、トリガーが実行された場合、本質的に何も起こらないため、他の何かに干渉する機能が削除されます。）
2./ 次に、サンドボックスでも非アクティブ化する必要があるクラスを編集しました。
- サンドボックスでクラスのステータスを変更できなかったので、文字通り、トリガー内で実行されているコマンドを削除しました。これを行うには、コードの中括弧の間に表示されるコマンドを削除するだけです。
3./ 両方の変更を保存した後、サンドボックスのアウトバウンド変更セットに CLASS と TRIGGER を追加し、それを本番環境にアップロードし、検証して正常にデプロイし、 最終的に エラーなしで Declarative Lookup Rollup Summaries パッケージをアンインストールできました。
これを見た人がこれを試してうまくいった場合は、私に知らせてください! これを試してもうまくいかない場合は、ご連絡ください。
最後に、これは単純なプロセスではなく 、この作業を行う前に何度か失敗したため、 フラストレーションを軽減するために、失敗したいくつかのことを以下に示します。
- 以下の記事の手順に従って、Workbench を使用して (コードを編集する前に) クラスだけを削除しましたが、うまくいきませんでした。クラスとトリガーの両方を一緒に試していればうまくいったかもしれませんが、この記事ではトリガーに対してこれを行う方法について説明していなかったので、私はしませんでした。
2./サンドボックスでトリガーとクラスを編集し、それらを別々に本番環境に送信しようとしました（理論的根拠：一方が他方を失敗させ、一方を非アクティブ化できる場合、他方は機能するはずです）が、それも機能しませんでした。
3./ Eclipse のような IDE を使用することの推奨事項を検討し始めましたが、Eclipse のインストール手順だけでは複雑すぎるように見えたので、Workbench を使用してから直接サンドボックス ルートを使用しました。
私からは以上です - これがこの問題を抱えている 1 人でも役立つなら、これを書く価値がありました :) そして、これをすべて読んで、組織から DLRS を削除しようとしていて、まだ DLRS ロールアップを削除していない場合は、自分で行ってください:)パッケージのインターフェースを介してトリガーと一緒にロールアップを優先して削除することで、これらの問題を回避できます。
This version of the tool no longer requires the field dlrs__LookupRollupSummary__c on dlrs__LookupRollupSummaryScheduleItems__c. For optimum configuration and performance please delete it after reading the further information provided.
What do I do?
- Run a report or create list view on the Lookup Rollup Summary Schedule Items object that filters for records that do not contain a value in the Lookup Rollup Summary 2 field. If you have records like this its possible they are very old, since this field has been being populated since v1.15 and beyond. If you want you can delete these records and re-run a full calculate for the associated Rollups.
- Next you need to go to the Object Manager in Setup and find the Lookup Rollup Summary Schedule Items object. Locate the field Lookup Rollup Summary (its a Master-Detail) with the API name dlrs__LookupRollupSummary__c.
- Delete this field and don't worry about accidentally deleting others the platform will block this. This will not effect any other data in your org as it is was purely used for the operation of the tool in prior releases and is now no longer needed.
Note: If you do not see the Delete option for the above field - try switching to Salesforce Classic UI mode.
- レポートを実行するか、ルックアップ ロールアップ サマリー 2 フィールドに値を含まないレコードをフィルターするルックアップ ロールアップ サマリー スケジュール アイテム オブジェクトのリスト ビューを作成します。このようなレコードがある場合、このフィールドは v1.15 以降から入力されているため、非常に古いレコードである可能性があります。必要に応じて、これらのレコードを削除し、関連するロールアップの完全な計算を再実行できます。
- 次に、[設定] の [オブジェクト マネージャー] に移動し、[ルックアップ ロールアップ サマリー スケジュール アイテム] オブジェクトを見つける必要があります。 API 名が dlrs__LookupRollupsummary__c のフィールド Lookup Rollup Summary (Master-Detail) を見つけます。
- このフィールドを削除すると、他のフィールドを誤って削除するとプラットフォームがこれをブロックすることを心配する必要はありません。このデータは、以前のリリースではツールの操作にのみ使用されており、現在は不要になっているため、組織内の他のデータには影響しません。
注: 上記のフィールドに [削除] オプションが表示されない場合は、Salesforce クラシック UI モードに切り替えてみてく
アップグレードのエラー
When was your sandbox last refreshed? If a retry fails, I would probably clone this Dev sandbox and try to reproduce this error. If the error persists, try to upgrade to the next version, which is either 2.11.1 or 2.12
https://sfdo-community-sprints.github.io/DLRS-Documentation/ReleaseNotes/Release_history.html
I guess one of the reasons for getting this error is if there is something obsolete on the current packages (this may apply to Remote Site Settings as well), which is not so surprising because your current version is outdated.
サンドボックスが最後に更新されたのはいつですか?再試行が失敗した場合は、おそらくこの Dev サンドボックスのクローンを作成して、このエラーを再現しようとします。エラーが解決しない場合は、次のバージョン (2.11.1 または 2.12) にアップグレードしてみてください。
このエラーが発生する理由の 1 つは、現在のパッケージに古いものがある場合だと思います (これはリモート サイトの設定にも当てはまる可能性があります)。現在のバージョンが古いため、これはそれほど驚くべきことではありません。
子のフィールドを使っているからエラー？
Your current setup won't work because we can only reference Relationship Criteria and fields from the child object. An exception applies to the parent if we decide to schedule the rollup. Then and only then can we add a filter for the parent. My solution is to create a formula checkbox field on the Activity object (Buyer__c= true), which checks if the Economic Buyer is the same as the Event contact. I have tested this in my Dev org, and it should work (screenshot below).
子オブジェクトからはリレーションシップ基準とフィールドしか参照できないため、現在の設定は機能しません。ロールアップのスケジュールを決定した場合、例外が親に適用されます。そうして初めて、親のフィルターを追加できます。私の解決策は、Activity オブジェクト (Buyer__c= true) に数式チェックボックス フィールドを作成することです。これは、Economic Buyer が Event 連絡先と同じかどうかをチェックします。私は自分の開発組織でこれをテストしましたが、うまくいくはずです (下のスクリーンショット)。
Error occured processing component dlrs__LookupRollupSummary2.Case_Note__Total_Hrs. Cannot create a new component with the namespace: Case_Note. Only components in the same namespace as the organization can be created through the API (FIELD_INTEGRITY_EXCEPTION).
I just encountered the same namespace error, and I think the issue was that the API name of the Lookup Rollup Summary I was trying to save started with "Account_".
This was being interpreted by the system as a namespace prefix.
When I renamed the API name so it didn't start with "Account_", I was able to save successfully.
同じ名前空間エラーが発生しました。保存しようとしたルックアップ ロールアップ サマリの API 名が「Account_」で始まっていたことが問題だったと思います。
これは、システムによって名前空間プレフィックスとして解釈されていました。
API名を「Account_」で始まらないように名前を変更したところ、正常に保存できました。
未解決
dlrs_ServiceAppointmentTest.testTrigger System.DmlException: Insert failed. First exception on row 0; first error: CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY, FSL.TR001_Service_BeforeInsert: execution of BeforeInsert caused by: System.NullPointerException: Attempt to de-reference a null object (System Code): [] (dlrs) Class.dlrs_ServiceAppointmentTest.testTrigger: line 11, column 1
I can explain what is happening, long story short we borrow a session from the UI and use it to talk to the Salesforce API's from the server, thus it is a different IP address than the client's browser that originated the session.
I can say the team is actively working on some alternative workflows, watch this space over the next month or two.
何が起こっているのか説明できます。簡単に言えば、UI からセッションを借用し、それを使用してサーバーから Salesforce API と通信するため、セッションを開始したクライアントのブラウザとは異なる IP アドレスになります。
チームはいくつかの代替ワークフローに積極的に取り組んでいると言えます。今後 1 ～ 2 か月間この分野に注目してください。