Include link to support in error message #149
No reviewers
Labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: servala/servala-portal#149
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "error-with-help"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #142
I'm not entirely happy with the implementation, but this is what I could come up with. Maybe there is a better / simpler way to do that?
LGTM – can be merged as-is, just some suggestions for possibly better code structure.
@ -857,0 +879,4 @@
"""
support_url = organization.urls.support
# Combine the main message with the support message template
full_message = _("{message} {support_message}").format(
The full message doesn’t need to be an i18n string – better off as just as
f"{message} {support_message}"
@ -4,3 +6,4 @@
from servala.core.models import Organization
# Import the support message template from the service model
I don't think comments like this add much to the code, FWIW (of course up to you if you want to keep it).
@ -91,2 +96,4 @@
def has_permission(self):
return self.has_organization_permission() and super().has_permission()
def format_error_with_support(self, message, **kwargs):
Pretty repetitive to have this method on both the form and the view – I think it’d be cleaner to centralise this:
@rixx Thanks for the review. I iterated over it again, and I'm happy to get another review before merging it.
Looks good to me! One comment on using
mark_safe
on input that we do not control directly, which I don't have enough k8s knowledge to judge (should be safe?), ready to merge from my POV.@ -606,0 +627,4 @@
error_list = "".join(f"<li>{error}</li>" for error in errors)
# Replace the bracketed section with the formatted list
formatted_message = re.sub(pattern, f"<ul>{error_list}</ul>", error_message)
return mark_safe(formatted_message)
Using mark_safe means that we trust k8s error messages to never contain valid markup/other injections, e.g. by way of user-defined names. I don't know enough about how k8s errors look and are processed, just wanted to point that out.
If we can't rely on that, an alternative would be to use a django template here, which would apply the standard Django safeguards to all rendered variables
With the help of Copilot and some manual tweaking / reviewing I was able to introduce a way to sanitize the error messages, which certainly makes sense. I hope it's not overengineered now.
Looks good to me!