プログラミング知識0が挑むLINE WORKS API2.0 part2（計画編）

Last updated at 2022-07-25Posted at 2022-07-22

前回postmanやDeveloper Consoleの設定を行い、APIを実行するための準備ができました。

一応前回立てた目標としては「ユーザーが使用できる」までの設定としていました。

じゃぁユーザー作っちゃえば終わりじゃん！ということで、まずはユーザー登録APIのドキュメントを見てみます。

ユーザー登録APIについて

ユーザー登録APIと聞くと、「まぁユーザー作れるんでしょうね」という感じですが、実際どのような情報を含んでいるんでしょうか。

ざっくり言えば管理者画面のメンバー追加で出来ることですよ。ということになりますが、その説明だと味気ないですね。

必ず必要な情報

ユーザー登録APIのドキュメントの「Request Body」を見ていきます。

「required」と記載されているパラメータはAPIを実行するにあたって必要ということになります（英語つらい）

domainID
email
userName

意外と少ないですよね。
ただし！気を付けてください。

「privateEmail」というパラメータを確認したところ以下の記載があります。

SSOを使用せず、passwordConfig.passwordCreationTypeがMEMBERの場合は必須

今、取り組もうとしている環境はSSOは使用しません。（そもそもそんな環境作る知識ありません）
ということは「passwordConfig」をどうするかによって変わると言う事ですね。

passwordConfig

これは作成対象のユーザーの最初のパスワードを誰が設定するか？という項目です。

ドキュメントにも記載の通り、以下の2パターンです。

ADMIN: 管理者が作成
MEMBER: ユーザーが作成

実際どのように挙動が異なるのかは、後々実際にAPIを実行する時に確認する事にしようと思いますが、この二つの設定があることは理解しました！

もしADMINで作成するなら、初期パスワードを設定すればprivateEmailは不要になりますね。

最低限の情報

では、今までの情報をまとめると、SSOを使用しない環境では以下の情報さえあれば、とりあえずユーザーを作成することはできます。

domainID
email　（これがログインIDになります。
userName
passwordConfig (ADMINで設定する前提）

ではこれでAPI実行してみましょう！

とりあえずユーザーを登録してみる

最低限の情報だと入力する内容は本当にこの程度です。
ちなみにbodyの書き方はユーザー登録APIのドキュメントの「Request Example」という記入例をコピーして編集しました。

するとresponse statusが「201 Created」として以下の実行結果が表示されました。

実行結果

{
    "domainId": xxxxxxxx,
    "userExternalKey": null,
    "email": "beginner@xxxxxxxxxxx.com",
    "userName": {
        "lastName": "初心者",
        "firstName": "",
        "phoneticLastName": "",
        "phoneticFirstName": ""
    },
    "i18nNames": [],
    "nickName": null,
    "privateEmail": null,
    "aliasEmails": [],
    "employmentTypeId": null,
    "searchable": true,
    "organizations": [
        {
            "domainId": xxxxxxxx,
            "primary": true,
            "userExternalKey": null,
            "email": "beginner@xxxxxxxxxxx.com",
            "levelId": null,
            "executive": false,
            "orgUnits": [],
            "organizationName": "demodemo",
            "levelExternalKey": null,
            "levelName": null
        }
    ],
    "telephone": null,
    "cellPhone": null,
    "fax": null,
    "location": null,
    "task": null,
    "messenger": null,
    "birthdayCalendarType": null,
    "birthday": null,
    "hiredDate": null,
    "locale": "ja_JP",
    "timeZone": "Asia/Tokyo",
    "customFields": [],
    "relations": [],
    "userId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx",
    "isAdministrator": false,
    "isPending": true,
    "isSuspended": false,
    "leaveOfAbsence": {
        "startTime": null,
        "endTime": null,
        "isLeaveOfAbsence": false
    },
    "isDeleted": false,
    "suspendedReason": null,
    "employmentTypeExternalKey": null,
    "employmentTypeName": null
}

はい。これでユーザーが登録できました。

...でもさぁ

たしかにログインはできます。
ですが、名前も苗字しか入れていないですしこれでユーザー登録ができたと言って良いのでしょうか？

否！

実際にはユーザーが組織に所属していたり、役職を持っていたり、電話番号を登録したいなど会社によって色々設定しておきたいことはあるはずです。

私に限らず皆さんそうだと思いますが、何度も何度も細かい修正を繰り返すことはできれば避けたいはず！

改めてドキュメントを見てみる

すべての設定項目をここに列挙するのはアレなので、詳しくはユーザー登録APIのドキュメントをご覧いただければと思いますが、気になったパラメータは以下です。

privateEmail
employmentTypeId （利用権限タイプ）
organizations （組織）
telephone

「employmentTypeId」は必ずしも使用するかどうか微妙なところですが、でもまぁこの辺の設定は必要と感じられる人が多いんじゃないかなと思いました。
ちなみに「organizations」の中で役職も設定できます。

「ユーザー作ったぞ！じゃ、次は組織作って、組織にユーザー参加させなきゃ....あ、あと人によっては使わない機能もあるから権限設定して....」

みたいなやり方だと何度もユーザー情報を更新しなければならないのが嫌だなと思いました。
であれば、先に準備できることはしておいた方が良くないですか？

なので、組織や利用権限タイプを先に考えたいと思いました。

と、ここでやっと本題。計画します。

前提

組織構成はとりあえず以下のような感じにしようと思います。

部	課
営業部	1課 2課
開発部	A課 B課
総務部	-
情報システム部	-

また、以下の条件を設定します。

メールやDrive機能を使用できるプランでテストしています
各部・課にはそれぞれ部長・課長がいる
部署によってはアルバイトや派遣社員がいる
業務よってはモバイル端末を使用しない
社長は特定の組織に所属しない
LINE WORKSの管理者画面にアクセスできる権限を持っているのは情報システム部に所属するメンバーのみとして、他部署の役職者や社長であっても管理者画面へのアクセス権は持たせない

今後条件を追加するかもしれませんが、とりあえずということで。