LoginSignup
4
2

More than 1 year has passed since last update.

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

Last updated at Posted 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」という記入例をコピーして編集しました。

01.PNG

すると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の管理者画面にアクセスできる権限を持っているのは情報システム部に所属するメンバーのみとして、他部署の役職者や社長であっても管理者画面へのアクセス権は持たせない

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

今後の進め方

以下の順序で作業を進める予定です。

 1.組織を作る
 2.役職を作る
 3.利用権限タイプを作る
 4.ユーザーを作る
 5.設定した利用権限タイプで動作するかチェック!

うーん。。。意外と道のりは長いのか?
諦めず頑張ろうと思います。

長文になってしまったので今回はここまでにします!

あ、postmanの設定を少しだけ

Enviroment

ユーザー登録に限らず他のAPIでも「domainId」をよく使用することがあります。

Developer Consoleに表示されている内容ですね。
都度入力するのも手間ですし、postmanのEnvironmentsに設定を入れました。

06.png

こんな感じで1行追加すればOKです!

Collection

先ほどしれっとユーザー登録APiを実行しましたが、どこから操作するのかという点に触れていませんでした。

画面左側の「Collection」をクリックすると前回取り込んだ「API2.0 demo」があります。
こちらにマウスオーバーすると「・・・」が表示されますので、こちらをクリックして、「Add request」をクリックします。
03.png

そうするとrequestの情報を入力できる画面が表示されます!
入力内容などは追々!
04.PNG

まとめ

4
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
2