※この記事は全文機械翻訳されています。

命名規則がフォルダで有効になると、ファイルはアップロードプロセス中に自動的にスキャンされ、特定の構造パターンと一致することを確認します。

ローカルファイル名に新しいバージョンのたびに常に変わるブロックが含まれている場合、フォルダは動的にそれらを認識するように構成できます。

適切に構成されると、異なるローカルファイルをアップロードして、異なるバージョンデータを同じドキュメントコンテナにマップします。

ファイル変更のたびに個別のクラッタードなドキュメントエントリを作成する代わりに、プラットフォームは共有ベース名を自動的に認識し、単一のドキュメントの下に順序付きrevisionとしてスタックします。

この記事では次のトピックについて説明します：

ファイルが正常にアップロードされると、プラットフォームは静的なドキュメント詳細を変化するバージョンデータから明確に分離します：

ファイルリストからドキュメントを選択し、ページの右側のファイル情報タブを展開すると、セグメント化されたデータが表示されます。

1.1.1 ドキュメント情報

ドキュメントのライフサイクル全体を通じて一定のままである命名ブロックからのデータを表示します。

1.1.2 Revision情報

アップロードされたファイル名から直接、変化するブロックから値を自動的に抽出して表示します。

1.1.3 Revision名

ローカルハードドライブに保存されていた元のローカルファイル名を、まったく同じように明示的にリストします。

メインファイルリスト全体で元のファイル名を一目で表示するには、「Revision名」(元の名前)列をオンに切り替えることができます。

列の可視性調整は個別のアカウントプロファイルに厳密に関連付けられており、ワークスペースをカスタマイズできることを意味します。

チームの残りのデフォルトビューに影響を与えることなく。

静的なドキュメント名から変化するバージョンマーカーを明確に分離する命名規則を構築するには、個別のブロック動作を規則設定内で調整する必要があります。

命名規則ページへのナビゲーションはプロジェクト設定内で完了します。

アクセス必須: 管理者

各リビジョンごとに変わるブロックの場合、ドキュメント識別子をオフに切り替える必要があります。

この設定により、プラットフォームはアップロード中に文字を検証して一貫性を保ちますが、実際のドキュメント名を確定する際には除外します。

これは、異なるバージョン文字列を持つファイルが完全に新しいドキュメントを生成するのではなく、revisionとしてきちんとスタックできるようにする正確なメカニズムです。

これらの動的ブロックで許可される文字を正確に制御するために、カスタムフィールドはブロックソースとして割り当てられます。

追跡要件に応じて、検証制約を強制するために異なるフィールドタイプを利用できます：

2.2.1 テキストカスタムフィールド

このオプションにより、標準の英数字入力に対して、柔軟または固定の文字数を使用できます。

2.2.2 ドロップダウンカスタムフィールド

このオプションはブロックを事前定義された特定の値のセットに制限し、最大1,000個のオプションに制限します。

短いファイル名コードをプラットフォーム内の完全で説明的な名前にマップする必要がある場合、これは非常に有益です。

3.2.3 整数カスタムフィールド

このオプションはブロックを厳密に数値のみを受け入れるように強制します。

数値エントリのみが使用されることを保証しますが、厳密なステップバイステップの順序付きカウントアップを強制するのではなく、システムは有効な整数を受け入れます。