File Index
configPM.js
nas.system で利用する各管理情報の基礎データテーブル Object nas.Pm の初期プロパティを設定するファイル
この内容は nas.pmdb としてアプリケーションから参照される。
このファイルのデータを個別にカスタマイズすることも可能（要注意）
これはスタンドアロン動作用のデフォルトのデータ群となる
DBとの通信が正常に初期化された後、DBから受信したデータで nas.pmdb が置き換えられる
DBとの通信が確立できなかった場合引き続き基礎DBとして機能する
UAT documentPanel
サーバ対応ドキュメントパネル機能
調整後はxUIに統合予定
- Version:
- 0.9.1 20190221
pmio.js
production managemaent io
nas.Pm は 管理情報を分離するためのオブジェクト群
PmUnitを中核にしてそれに含まれる被管理情報をオブジェクトとして保持する
ServiceAgent モジュール
サービスエージェント
一旦このモジュールを通すことで異なる種別のリポジトリの操作を統一する
サービスエージェントは、ログイン管理を行う
test data:
var username = kiyo@nekomataya.info
var password = 'devTest'
var client_id = "b115aead773388942473e77c1e014f4d7d38e4d4829ae4fd1fa0e48e1347b4cd";
var client_secret = "54c0f02c38175436df16a058cc0c0e037038c82d3cc9ce4c212e3e4afe0449dd";
http://remaping.scivone-dev.com/oauth/token?
Object ServiceAgent
.servers サーバコレクション
.repositories リポジトリコレクション
.currentRepository 現在選択されているリポジトリへの参照
サーバは複数のリポジトリを持つことができる
リポジトリは、いずれかのサーバに属しそのサーバへの参照を持つ
ローカルリポジトリはアプリケーション自身がサーバの代用をする
アプリケーションはリポジトリセレクタでリポジトリを選ぶ
ドキュメントリストにはリポジトリから取得した内容と、実際にオープンした内容の履歴を表示する
履歴は、ローカルリポジトリにするか？
そうする場合は、ローカルリポジトリはセレクタに入れずに表示にマーキングをする
特に現在開いている（又は開いていない）リポジトリのカットとカブっている場合
リポジトリ分類
以下のような段階的な差を付けてアカウントを取得してもらう＋制作会社に対する有料サービスを販売しやすくしたい
ローカルリポジトリ
オフライン作業用のリポジトリ
常に使用可能、このリポジトリのデータは対応する作品を管理するサーバと同期可能にする？
作業中に認証を失ったり、ネットワーク接続が切れた作業はこのリポジトリに保存することが可能
サービスノード（サーバ）としてはダミーの値を持たせる
（作業バックアップ領域とは別 作業バックアップは常時使用可能）
ローカルリポジトリは容量が制限されるので保存できるカット数に制限がある（現在５カット 2016.11.15）
この部分は作業履歴や作業キャッシュとして扱うべきかも
履歴として扱う場合は、「最終5カットのリングバッファ」という風に
ホームリポジトリ
ログインしたサーバ上でデフォルトで提供されるリポジトリ
ログイン時は常に使用可能
＝チーム
追加リポジトリ
個人用のリポジトリとは別に設定される共同制作用リポジトリ
ある程度の管理サービスが追加される
プロダクションリポジトリ（有料サービス）
個人用のリポジトリとは別に設定される業務用リポジトリ
会社単位での作品制作のための管理サービスが追加される
こんな感じか？
同時にアクセス可能なリポジトリの数を制限したほうが良い
あまり多くのリポジトリを開いて一律に表示すると混乱する
とくに、ローカルリポジトリはバックアップの性格が強くなるので、他のリポジトリのタイトルを表示することになる
リポジトリセレクタで選んだ単一のリポジトリのみにアクセスするように設定する
サーバのメニュー上でリポジトリにプロダクト（制作管理単位）を登録すると、そのプロダクトに対してカットの読み書きが可能になる
プロダクト毎にアクセス可能な（リポジトリ共有＝スタッフ）グループにユーザを登録することができる
登録されたユーザはそのリポジトリにスタッフとしてアクセスしてデータを編集又は閲覧することが可能
Repository.ouganization
Repository.pmdb.orgnizations
Repository.pmdb.users 当該リポジトリ内の基礎ユーザDB
Repository.pmdb.staff 同基礎スタッフDB（ここにユーザを含む必要はないツリー下位のDBが優先）
Repository.pmdb.lines 同ラインテンプレート（テンプレート ツリー下位のDB優先）
Repository.pmdb.stages 同ステージテンプレート（同上）
Repository.pmdb.jobNames 同ジョブテンプレート (同上)
Repository.pmdb.assets アセット定義テーブル
Repository.pmdb.medias 同メディアテンプレート
Repository.pmdb.workTitles 作品タイトルコレクション
Repository.pmdb.opuses プロダクトコレクション
Repository.users アクセスの可能性がある全ユーザのリスト
Repository.productsData.staff アクセス可否情報 リポジトリに対するユーザとその所属・役職のDB
Repository.productsData[px].staff アクセス可否情報 リポジトリに対するユーザとその所属・役職のDB
Repository.productsData[px].episodes[ex].staff アクセス可否情報 リポジトリに対するユーザとその所属・役職のDB
Repository.productsData[px].episodes[ex].cuts[cx].staff アクセス可否情報 リポジトリに対するユーザとその所属・役職のDB
エントリごとにスタッフに対して以下の権利を設定することができる
true (アクセス可)
false (アクセス不可)
内部状態として、以下の状態があるがユーザが設定可能なのはtrue/falseの２状態のみとする
X リスト
R 読出
W チェックイン
権利に対して レイヤー構造がある
リポジトリは組織として プロダクト（workTitle）を含む
プロダクト（workTitle）はエピソード（opus）に分割される
opusは制作話数であり、個々のドキュメント（pmunit）を含む
各ドキュメントはライン/ステージ/ジョブの構造を持つ
このアトリビュート毎・ユーザ毎に 権限が異なるケースがある
リポジトリ *
プロダクト *
各話 *
カット *
ライン *
ステージ *
ジョブ *
サーバごとに権限グループを設ける基本は作業部毎
制作管理部
演出部
撮影部
美術部
原画部
動画部
仕上部
等
グループ・ユーザの権限は、エントリ毎に設定可能に
基本はグループに対する権限設定
イレギュラー処理が必要なケースのみユーザごとの権限をエントリの設定に追記する
イレギュラーや変更がなければエントリの権限設定は上位のレイヤから継承するので記載は無くとも良い
グループ権限・作品データ・管理基礎データ等の保存管理
基本的なDBへの登録等は、リポジトリ内に設定データを置いてその読み書きで対処する
RDBMのサポートのないファイル（ストレージ）上でリポジトリを築く際に必要
サービスエージェントを介してのDBへの情報請求をここで解決
これらの権利関連を別紙にまとめる
サービスエージェントはこのまま拡張 pmdb,xMap,Xpstを統合する