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-6022 Product Sources List Actions (improvements after QA) #4479

Merged
merged 5 commits into from
Jan 31, 2024

Conversation

alannadolny
Copy link
Collaborator

No description provided.

}

Throwable root = ExceptionUtils.getRootCause(request.getAttribute('exception'))
render([errorCode: 500, errorsMessages: [root.getMessage()]])
Copy link
Collaborator

Choose a reason for hiding this comment

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

you have a typo here - errorsMessages instead of errorMessages.
By the way if we have a single message, I'd consider using errorMessage.

Copy link
Member

Choose a reason for hiding this comment

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

you have a typo here - errorsMessages instead of errorMessages.

Good catch.

By the way if we have a single message, I'd consider using errorMessage.

Can you elaborate on that? I assume our convention is to use the "errorMessages" key, so why would it be better to have a duplicate key "errorMessage" that requires the API client to check for values under both keys?

Copy link
Collaborator

Choose a reason for hiding this comment

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

@jmiranda we already have errorMessage - e.g. look at handleValidationErrors - we pass both errorMessage and errorMessages. Frontend side (error handler) is already prepared for both options, so we wouldn't have to introduce anything new. It's just that if we have a single message (like in this), not an array of messages (like for validation errors), we should pass errorMessage in my opinion, because in the end frontend would still destruct this array and make it a single message.

id: 'react.productSupplier.deleted.label',
defaultMessage: `Product Source ${productSupplierId} deleted`,
data: {
id: productSupplierId,
Copy link
Collaborator

Choose a reason for hiding this comment

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

wow, I've never seen this. 👏

Copy link
Member

@jmiranda jmiranda Jan 28, 2024

Choose a reason for hiding this comment

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

Can you elaborate on that? What does "this" refer to?

(that is a question related to @kchelstowski comment in case it wasn't clear)

Copy link
Collaborator

@kchelstowski kchelstowski Jan 29, 2024

Choose a reason for hiding this comment

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

@jmiranda "this" refers to using data property of translate method. I haven't known we could pass custom params for translation on the react side and then use it in the messages.properties like he did:

react.productSupplier.deleted.label=Product Source ${id} deleted

@@ -854,6 +856,7 @@ class UrlMappings {
"500"(controller: "errors", action: "handleNotFound", exception: ObjectNotFoundException)
"500"(controller: "errors", action: "handleValidationErrors", exception: ValidationException)
"500"(controller: "errors", action: "handleUnauthorized", exception: AuthenticationException)
"500"(controller: "errors", action: "handleSqlIntegrityConstraintViolationException", exception: SQLIntegrityConstraintViolationException)
Copy link
Member

Choose a reason for hiding this comment

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

This is minor, but let's just call this handleConstraintViolation to avoid readability issues.

}

Throwable root = ExceptionUtils.getRootCause(request.getAttribute('exception'))
render([errorCode: 500, errorsMessages: [root.getMessage()]])
Copy link
Member

Choose a reason for hiding this comment

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

you have a typo here - errorsMessages instead of errorMessages.

Good catch.

By the way if we have a single message, I'd consider using errorMessage.

Can you elaborate on that? I assume our convention is to use the "errorMessages" key, so why would it be better to have a duplicate key "errorMessage" that requires the API client to check for values under both keys?

id: 'react.productSupplier.deleted.label',
defaultMessage: `Product Source ${productSupplierId} deleted`,
data: {
id: productSupplierId,
Copy link
Member

@jmiranda jmiranda Jan 28, 2024

Choose a reason for hiding this comment

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

Can you elaborate on that? What does "this" refer to?

(that is a question related to @kchelstowski comment in case it wasn't clear)

@awalkowiak awalkowiak merged commit 3e23b8b into feature/product-supplier-list-redesign Jan 31, 2024
@awalkowiak awalkowiak deleted the OBPIH-6022-2 branch January 31, 2024 11:25
awalkowiak pushed a commit that referenced this pull request Mar 12, 2024
* OBPIH-6022 Add new translations

* OBPIH-6022 Add success message after deleting product supplier

* OBPIH-6022 Add handling sql integrity constraint violation exception

* OBPIH-6022 Hide redirects to product source edit page

* OBPIH-6022 Fixes after review
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

5 participants