APIで取得される日報データ構造
NipoPlusのアプリを通して見るデータと、APIから取得したデータは見た目が全く異なりますが、両者は同じものです。 NipoPlusのアプリではデータを見やすく変形させることで日報風のデザインに組み立てています。 例えば日報データであれば、次の2つの要素を組み合わせて日報を表現しています。
- 日報本文のデータ
- 日報テンプレートのデータ
日報本文のデータは実際にスタッフが記入したデータです。日報テンプレートのデータはタイトルや項目見出し名、色、フィールドの構造などの情報を持っています。 両者を良しなに組み合わせて日報を形作ります。APIを通じて取得すると見やすくする前のデータが取得されます。 そのため解析の一助として、ここでは組み合わせる前の生のデータ構造について紹介します。
日報本文の生データ
キー | 型 | 説明 |
---|---|---|
id | String | 20文字で構成されるランダムな文字列です。ユニークです(厳密には異なるが考慮の必要はない) |
no | NumberまたはNull | 日報に採番された番号です。連番は日報作成後に非同期で振られるためタイミングによってはNull |
body | Object | 日報文書本体 |
createTs | Number | 13桁の数値(ミリ秒含むUnixタイムスタンプ)。日報がサーバに初回保存された時刻 |
updateTs | Number | 13桁の数値(ミリ秒含むUnixタイムスタンプ)。日報が最後に更新された時刻 |
userTs | Number | 13桁の数値(ミリ秒含むUnixタイムスタンプ)。日報作成者が指定した表示上の日時 |
distId | String | 今現在その日報を承認・棄却出来る権限のスタッフID |
dists | String配列 | 日報の提出先スタッフIDの配列です。配列の序列順に承認を行います。承認や棄却ができるのは上記のdistIdに一致したスタッフのみ |
observer | String配列 | その日報を読むことができるスタッフのID郡です。承認や棄却の権限はありません。 |
readed | String配列 | その日報を読んだフラグを立てたスタッフIDの配列です。承認や棄却をしたスタッフもreadedに含まれます |
tags | String配列 | 日報に付けられたタグのID配列 |
sign | コレクション | 承認や棄却日時を記録したコレクションです。コードで書くと sign:{ uid: string, ts: number, agree: boolean}[]です。承認した日時や承認者IDを確認可能 |
state | String | 承認・棄却・修正・新規・進行 いづれかの文字 |
owner | String | 日報を作成したスタッフのID。共用を使うときに作成者IDとしてセットされる。共用を使わない場合は後述する「account」と常に同じ値が入る |
account | String | 日報を作成したFirebase上のユーザID |
templateId | String | その日報を作成するために使用された日報テンプレートのID |
taskId | String | 日報とタスクを紐付けられたとき、タスクのIDガセットされる |
以下は実際にAPIを使ってロードした日報のデータのサンプルです。
{
"readed": ["mMSejOQa21d9OtXo1BtjFzrEt6J3"],
"id": "V9MGSesp0LUgXUPo0Skv",
"taskId": "none",
"no": 3,
"tags": [],
"owner": "mMSejOQa21d9OtXo1BtjFzrEt6J3",
"updateTs": 1659400505426,
"account": "mMSejOQa21d9OtXo1BtjFzrEt6J3",
"templateId": "uDE74jrGtn90vZZqsaci",
"distId": "mMSejOQa21d9OtXo1BtjFzrEt6J3",
"userTs": 1659400505425,
"sign": [],
"createTs": 1659400505426,
"body": {
"B2x": "あお",
"SAl": ["いちご","ごはん","餃子","干瓢"],
"1ST": ["餃子","うどん","焼きそば","牛乳","ごはん"],
"N70": ["いちご","干瓢","メロン"],
"iif": "あか"
},
"observer": ["mMSejOQa21d9OtXo1BtjFzrEt6J3"],
"dists": ["mMSejOQa21d9OtXo1BtjFzrEt6J3"],
"state": "新規"
}
日報テンプレートの生データ
キー | 型 | 説明 |
---|---|---|
ts | Number | テンプレートが作成された日(ミリ秒含むUnixタイムスタンプ) |
prefix | String | 文書番号の前に付される記号。初期値は"No." |
active | Boolean | テンプレートが有効な場合はTrue。無効にするとFalse |
memo | String | テンプレート自体に付されたメモ。初期値は"テンプレートメモ" |
name | String | テンプレートの大見出し |
noruma | Number? | 1日あたりの提出枚数目安。初期値は0 |
id | String | テンプレートのID |
tags | String[] | テンプレートに付与したタグのID |
body | Collection | テンプレートの本体とも言える項目。詳細は次の表へ |
bodyについての詳細
キー | 型 | 説明 |
---|---|---|
labelSize | String | 見出しの文字サイズ。label_sのような値が入る |
label | String | 見出しの文字列 |
key | String | 入力のデータとテンプレートを紐付けるための鍵。この値が日報本体データ上のKeyとして使用される |
labelColor | 見出しの色 | |
req | Boolean | 入力必須ならTrue |
type | String | 文字入力や数値入力など、データの構造に応じた値が入る |
w | Number | テンプレートで専有する幅 1〜12 |
any | any | その他、入力フォームに応じて必要なパラメータが追加されます… |
bodyはテキスト入力フォームや選択肢入力フォーム、スライダ入力フォームなど、様々な入力フォームの形やサイズ、設定の情報を持っています。 項目によって存在するプロパティ・存在しないプロパティがあり、上記で上げたプロパティはほとんどの入力フォームで使用されている代表的なものをリストアップしました。 最も重要なのはkeyであり、このkeyが実データ上のkey名として使用されます。
例えば次のようなテンプレートがあったとします。(説明のため大幅に簡略)
"body": [
{
"label": "今日の夜食",
"key": "N70",
"type": "text",
"w": 4
},
{
"label": "担当職員名",
"key": "1ST",
"type": "text",
"w": 4
},
{
"label": "スコア",
"key": "A4x",
"type": "number",
"w": 4
],
このテンプレートを使って作成された日報のBodyは次のようになります
"body": {
"N70": "やきうどん",
"1ST": "長谷川研究員",
"A4x": 100
}
データのキーを見ることで項目名を紐解いていくことができます。例えば"N70": “やきうどん"というデータは、日報テンプレートのKeyを探すと"今日の夜食"であることがわかります。 よって、日報上は「今日の夜食: やきうどん」というデータが入力されていることを知ることができます。 同様の手順で、(1ST = 担当職員名):長谷川研究員と解読でき、(A4x = スコア): 100と解読できます。