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

OBPIH-5802 select approver in create request approvals end to end workflow #4286

Conversation

drodzewicz
Copy link
Collaborator

No description provided.

@drodzewicz drodzewicz force-pushed the OBPIH-5802-select-approver-in-create-request-approvals-end-to-end-workflow branch from a8a2638 to ac8c57b Compare September 18, 2023 07:30
@@ -198,6 +231,14 @@ class CreateStockMovement extends Component {
if (this.state.values.origin && this.state.values.destination) {
this.fetchStockLists(this.state.values.origin, this.state.values.destination);
}
if (this.state.values.origin) {
if (this.state.values.origin?.supportedActivities?.includes(ActivityCode.APPROVE_REQUEST)) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

what about destination's supportedActivities? Has it been clarified what we should look at exactly?


return response.data.data;
})
.catch(() => this.props.hideSpinner());
Copy link
Collaborator

Choose a reason for hiding this comment

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

let's maybe add .finally here that would hide the spinner instead of hiding in both in .catch and in .then?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

good idea, I was just copy/pasting the previous fetch methods in the component and followed the "convention"

params.location = session.warehouse?.id
}
List<User> users = userService.findUsers(params).collect {
[id: it.id, label: it.name, value: it.id ]
Copy link
Collaborator

Choose a reason for hiding this comment

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

maybe not for now, but maybe we should think about creating a dto called SelectOptionDto for those select options?
In all places we return the same object which is object with id, label, value.
It'd be easier to manage those select options if we ever wanted e.g. to add a new field to be returned etc.
But as I said - it's probably not for now, but it was a good moment to raise it.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Did the structure of the response change? If yes then it should be a separate endpoint.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Did the structure of the response change? If yes then it should be a separate endpoint.

@@ -82,7 +82,7 @@ class UrlMappings {
action = [GET: "paymentTermOptions"]
}

"/api/users" {
"/api/usersOptions" {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why this change? You should not change an existing endpoint like that.

@@ -82,7 +82,7 @@ class UrlMappings {
action = [GET: "paymentTermOptions"]
}

"/api/users" {
"/api/usersOptions" {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why this change? You should not change an existing endpoint like that.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

In my opinion, this should have been done like that in the first place.
This is an endpoint from selectOptionsApiController and looking at previous "...Options" endpoints, this is the approach we went with for these kinds of endpoints.

Also, this endpoint is only used in debounce fetch for user-select which data was transformed on the frontend.

params.location = session.warehouse?.id
}
List<User> users = userService.findUsers(params).collect {
[id: it.id, label: it.name, value: it.id ]
Copy link
Collaborator

Choose a reason for hiding this comment

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

Did the structure of the response change? If yes then it should be a separate endpoint.

params.location = session.warehouse?.id
}
List<User> users = userService.findUsers(params).collect {
[id: it.id, label: it.name, value: it.id ]
Copy link
Collaborator

Choose a reason for hiding this comment

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

Did the structure of the response change? If yes then it should be a separate endpoint.

@drodzewicz
Copy link
Collaborator Author

As I mentioned before I still believe the previously used /api/users endpoint was supposed to return an option structured like array [label, id, value] like all of the other endpoints in SelectOptionsApiController and have a different endpoint name /api/userOptions just like others.
But to not confuse the API consumer which might have been using this endpoint, I created a UserApiController with list which returns exactly the same data as it returned in the SelectOptionsApiController.
So from the point of view of the Api consumer, nothing has changed.
@awalkowiak

Add ability to search users by RoleType
- add const for roleTypes
- conditionaly render approver multiselect if fulfiling location supports APPROVE_REQUEST
- if only one approver is available then preselct this value by default
- fix userOptions endpoint to match other option endpoint names
- move roleType parameter to other findUsers service method
= transform userOptions on backend to label, value, id
@awalkowiak
Copy link
Collaborator

@drodzewicz but you still changed the url of this endpoint

@drodzewicz drodzewicz force-pushed the OBPIH-5802-select-approver-in-create-request-approvals-end-to-end-workflow branch from 8183f3f to e909ea6 Compare September 18, 2023 16:16
@awalkowiak awalkowiak merged commit 55b6903 into develop Sep 19, 2023
3 checks passed
@awalkowiak awalkowiak deleted the OBPIH-5802-select-approver-in-create-request-approvals-end-to-end-workflow branch September 19, 2023 08:39
awalkowiak pushed a commit that referenced this pull request Oct 26, 2023
…kflow (#4286)

* OBPIH-5802 Add UserApiController
Add ability to search users by RoleType

* OBPIH-5802 Add supportedActivities property on origin and destination of stockMovement response

* OBPIH-5802 Approver field on Create Request form
- add const for roleTypes
- conditionaly render approver multiselect if fulfiling location supports APPROVE_REQUEST
- if only one approver is available then preselct this value by default

* OBPIH-5802 Set initial values for approvers on existing request

* OBPIH-5802 Remove UserAPIController and use userOptions endpoint instead
- fix userOptions endpoint to match other option endpoint names
- move roleType parameter to other findUsers service method
= transform userOptions on backend to label, value, id

* OBPIH-5802 Add subtext to approver select component

* OBPIH-5802 Rollback usersOption list endpoint changes

* OBPIH-5802 Add approvers list on stockMovement
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.

None yet

4 participants