Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

APP-2983: Implementation of user service in BDK 2.0 #195

Merged
merged 7 commits into from
Sep 4, 2020

Conversation

symphony-hong
Copy link
Contributor

@symphony-hong symphony-hong commented Sep 1, 2020

Create UserService class to wrap all the user api endpoints provided
by the pod to retrieve user, list of users, perform action to get and
update role, delegate, entitlements, avatar, disclaimer, status of user.

Create an entry to user service in SymphonyBdk by calling method SymphonyBdk#user

Create an example for user service

Update javadoc

Unittest added with code coverage >90%

Create UserService class to wrap all the user api endpoints provided
by the pod to retrieve user, list of users, perform action to get and
update role, delegate, entitlements, avatar, disclaimer, status of user.

Create an entry to user service in SymphonyBdk by calling method SymphonyBdk#user

Create an example for user service

Update javadoc
@thibauult
Copy link
Member

@symphony-hong How do the services will handle OBO authentication? At the moment, it is only possible to call those services using the regular bot authentication (i.e. bot's AuthSession). I think that we should also provide prototypes that accept an AuthSession as parameter. WDYT?

@symphony-hong
Copy link
Contributor Author

How do the services will handle OBO authentication?

I thought, for handling the OBO authentication, we just need pass the obo's AuthSession to the constructor like what is being implemented in MessagaeService, isn't it?

@thibauult
Copy link
Member

I thought, for handling the OBO authentication, we just need pass the obo's AuthSession to the constructor like what is being implemented in MessageService, isn't it?

MessageService was more a POC than a definitive implementation. The problem with this design is that we need to create a new instance each time we want to call in OBO mode. Which can be very costly in terms of memory if an application has to manage a lot of OBO sessions.

@symphony-hong
Copy link
Contributor Author

I have several ideas for it:

  • Take the authentication out of the SymphonyBdk, accept AuthSession as parameter
  • Create service for both normal and obo mode, store in hashmap (Flyweight Pattern)

@thibauult
Copy link
Member

@symphony-hong could you make a small demo for both of each?

@symphony-hong
Copy link
Contributor Author

symphony-hong commented Sep 2, 2020

could you make a small demo for both of each?

Okay I will do it when we're working with the ticket about Fluent API

Using MapperStruct to create a mapper for user detail to make it more generic

Refactor user service entry

Update a more complicated example for user service
Define UserService#authSession for setting up the authSession
using by UserService instance.

In SymphonyBDK, passing the authSession or oboSession to UserService
instance to make it run with normal or obo session respectively.
@symphony-hong
Copy link
Contributor Author

@symphony-thibault or we can do like what I did in last update. Is this your point at the beginning?


private final UserApi userApi;
private final UsersApi usersApi;
private AuthSession authSession;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In a multi-threaded environment (Spring for instance): this will cause big issues for sure :) Also, we should also keep in mind that OBO is not supported for all API endpoints (cf. https://developers.symphony.com/restapi/reference#obo-enabled-endpoints).

We should enforce developers to use OBO authentication on OBO-Enabled endpoints only.

@symphony-hong symphony-hong marked this pull request as ready for review September 3, 2020 12:16
@symphony-hong symphony-hong requested a review from a team September 3, 2020 12:16
Copy link
Contributor

@symphony-elias symphony-elias left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

pom.xml Outdated Show resolved Hide resolved
symphony-bdk-bom/pom.xml Outdated Show resolved Hide resolved
@thibauult
Copy link
Member

Last minute idea: we could create a custom annotation @OBOEnabled that we would place on top of methods that actually accept OBO authentication. Not very useful at the moment since we don't support OBO for services yet, but that could be really interesting in the future, I think...


/**
* Retrieve user details of a particular user.
* @see <a href="https://developers.symphony.com/restapi/reference#get-user-v2">Get User v2</a>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@see is usually placed at the end of the Javadoc comment block (cf. https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html)

Copy link
Member

@thibauult thibauult left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

@symphony-hong symphony-hong merged commit cbe02e8 into finos:master Sep 4, 2020
* @param uid User Id
* @return User found by uid
*/
public UserV2 getUserById(@NonNull Long uid) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could have a getUser(UserId id) method to cover both cases (long id and string email)

And then UserId.id(123) and UserId.email("bob@mail.com")
This way we don't mess up with primitive types and avoid having methods suffixed with byId/byEmail

But maybe the API does not always support id and email?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the API for getting user accept only one of the params: username, uid or email. If we pass more than one param, the error 400 is returned. That's why I splitted it to 3 different methods.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does not prevent the UserService to have the logic to set the username/uid/email based on the UserId passed as a parameter

but do all the APIs related to user support passing username, uid or email? (otherwise we would not have a consistent API where UserId can be used everywhere)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

* @param image The avatar image for the user profile picture.The image must be a base64-encoded.
* @see <a href="https://developers.symphony.com/restapi/reference#update-user-avatar">Update User Avatar</a>
*/
public void updateAvatarOfUser(@NonNull Long uid, @NonNull String image) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a API user in Java I would perhaps prefer to send an inputstream here (and then have the SDK do the encoding for me)

* @param image The avatar image in bytes array for the user profile picture.
* @see <a href="https://developers.symphony.com/restapi/reference#update-user-avatar">Update User Avatar</a>
*/
public void updateAvatarOfUser(@NonNull Long uid, @NonNull byte[] image) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah that one is better :)

@symphony-hong symphony-hong deleted the APP-2983 branch September 11, 2020 16:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants