/d2l/api/lp/1.4/enrollments/myenrollments/現在のユーザーの登録リストを取得するために使用しています。ここで、ユーザーがインストラクターの役割を果たしている登録を取得したいと思います。だから、私は使用しようとしています：
/d2l/api/lp/1.4/enrollments/users/{userId}/orgUnits/?roleId=105
それを使用すると、roleId が指定されているかどうかに関係なく、アイテムの空のリストが返されます。
私の期待は、 roleId なしで呼び出すだけで、 と同じリストが返されること/d2l/api/lp/1.4/enrollments/myenrollments/です。ただし、システム管理者としてログインする場合を除いて、常に空のリストが表示されます。その場合にのみ、私は何かを取り戻します。
私が間違っているかもしれないことについて何か提案はありますか?
さまざまなmy*API 呼び出しは、エンド ユーザーが知っておくべきシステムに関する詳細を取得できるようにするために特に存在しますが、知っておくべきではない情報から分離されています (特定の領域のより一般的なルートを介して入手できます)。登録はこの良い例です。また、エンド ユーザーは自分の登録を表示できる必要がありますが、登録レコードへの一般化されたアクセスは許可されません。特に、D2L システムは、登録に属する D2L ユーザー ロールをかなり特権的な情報として扱います。これの副作用として、一般にエンド ユーザーには表示されません。
エンドユーザー自身が実行できない目標の達成にアプリケーションとサービスが対処できる方法の 1 つは、アプリが管理上の性質の呼び出しを行うために使用できる「サービス アカウント」を設定し、使用できるデータを取得することです。エンド ユーザーへの情報提示に関するビジネス ロジック。この特定のケースでは、たとえば、サービス アカウントを使用してユーザーの登録に関する呼び出しを行い、「これらは学生のものであり、これらは学生のものであり、これらは学生のものです。あなたが教師であり、家庭教師である場所など」.
ただし、クライアント LMS のポリシーと管理の意図とのバランスを取りながら、この種のアクティビティの影響を慎重に検討する必要もあります。このレベルの情報でさえ、クライアントの LMS 管理者の目には、エンド ユーザーに提供しすぎている可能性があります。
サービス アカウントを使用してアプリが管理者レベルの呼び出しを行えるようにする場合は、エンド ユーザーへの情報/機能の漏洩の問題に常に細心の注意を払って行う必要があります。