カスタマイズされたレコードを OOB に戻し、アップグレード性のために更新セットを介して転送しますSummary<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 更新セットは、アプリケーションのテーブル、フィールド、およびレコードに対するカスタマイズを追跡できます。 インスタンスのカスタマイズに関する FAQ とガイドライン カスタマイズすると、2 つのテーブルにエントリが作成されます。 sys_update_version ==> は、保存ごとにそれぞれ 1 つのレコードと、アップグレードを介して提供される OOB レコードを維持します。sys_update_xml ==> 進行中の更新セットがある場合、最後の SAVE の最新レコードのみがその更新セットにリンクされて保存されます。別のインスタンスから更新セットをコミットすると、sys_update_xmlにもエントリが作成されます 一部のレコードはtable_name_sysidによってタグ付けされています 一部のレコードは sys_*_table_name_field_name によって追跡されます。これらは、結合戦略によって比較が決定されるレコードです 現在の進行中の更新セットを閉じると、加えた変更は別の更新セットに保存され、特定のsys_idの更新セットごとに 1 つのエントリしかsys_uopdate_xmlありません。これは、現在のカスタム/デフォルトの更新セット。 したがって、5 回変更して SAVE を 5 回行った場合、保存中に進行中だった更新セットにリンクされたsys_idの sys_update_version テーブルに 5 つのレコードが存在しますそれぞれの更新セットに対して、sys_update_xmlにそれぞれ 1 つのレコードがあります アップグレード中、アップグレードエンジンはsys_update_xmlテーブルで追跡されたカスタマイズのみを検索します このフィールドは、sys_update_xml テーブルの [アップグレード時に交換] です「アップグレード時に交換」が「false」の場合、アップグレードエンジンはカスタマイズには触れません[アップグレード時に置換] フィールドが「true」の場合、アップグレードエンジンはカスタマイズを上書きします (複数のエントリがある場合、最新のエントリの値が考慮されます) sys_update_xmlで作成されたエントリは、[アップグレード時に置換] をデフォルト値「false」として使用します したがって、組織がアップグレード可能性のためにカスタマイズをOOBに戻すプロセス中の場合 1.構成を特定します (sys_script、sys_ui_action。sys_*...など) は OOB にする必要があります2.table_name.list に移動して、レコードのスコープを特定します。これは「アプリケーション」フィールドにあります3.新しい更新セットを開き、変更するレコードの同じスコープで最新のものにします3.sys_update_versionテーブルに移動し、変更/table_name_field_nameするレコードのsys_idを含む名前を検索します ( の場合 合体戦略)4.OOB レコードを見つけて開き、[] フォームで UI アクションを選択します このバージョンに戻す5.これにより、ポイント 3 の進行中の更新セットに「アップグレード時に置換」が「true」のエントリーが作成されます6.この更新セットを完了し、TTEST/UAT に取得します7.この更新セットは任意のインスタンスにコミットでき、[アップグレード時に置換] の値は [true] のままです。これにより、レコードは OOB のままになり、次のアップグレードで自動的にアップグレードされます。 自分の OOB インスタンスのスクリーンショットが添付されています。sys_ui_actionを例に挙げました。 情報 アップグレード中にカスタマイズを上書き アップグレード中に適用されたワークアラウンドが固定 OOB レコードで上書きされるようにする方法 スコープの検索 レコードが OOB に更新され、ローカル更新セットで [アップグレード時に置換] が「true」にキャプチャされる ターゲットインスタンスでは、コミット後に [アップグレード時に置換] の値が「true」になります Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } }