ereuse/devicehub-django
8
0
Fork 0
Code Issues 5 Pull requests 9 Packages Projects Releases Wiki Activity

Parsing error handling and MAC retrieval on new snapshots #27

Merged
pedro merged 12 commits from pr_25 into main 2024-11-12 13:57:05 +00:00
Conversation 4 Commits 12 Files changed 6 +58 -47
pedro commented 2024-11-10 02:35:05 +00:00
Owner
Copy link

we try again the merge of #25

we try again the merge of https://farga.pangea.org/ereuse/devicehub-django/pulls/25
pedro added 3 commits 2024-11-10 02:35:06 +00:00
pedro requested review from cayop 2024-11-10 02:35:36 +00:00
rskthomas added 3 commits 2024-11-11 07:29:25 +00:00
rskthomas added 3 commits 2024-11-11 17:50:12 +00:00
rskthomas added 1 commit 2024-11-11 17:58:29 +00:00
rskthomas commented 2024-11-11 18:02:32 +00:00
Owner
Copy link

Done again PR #25.

Also reworked the exception handling and error messages on upload/import views.

Added a success message to display for these views.

Changed form validation onto the fields, because if the form itself failed but the file was read, then the file_input field showed a success icon (whilst displaying error messages), which is confusing given that it is the only field.

Done again PR #25. Also reworked the exception handling and error messages on upload/import views. Added a success message to display for these views. Changed form validation onto the fields, because if the form itself failed but the file was read, then the file_input field showed a success icon (whilst displaying error messages), which is confusing given that it is the only field.
rskthomas changed title from WIP: Parsing error handling and MAC retrieval on new snapshots to Parsing error handling and MAC retrieval on new snapshots 2024-11-11 18:02:36 +00:00
pedro commented 2024-11-12 00:38:19 +00:00
Author
Owner
Copy link

I am confused by the raises in proposed code (I also found other ones in the current django app), maybe the use of raise you are doing here is fine, just review it again. Because I saw how a generic rise in django command crashed the application, but maybe when you use this kind of raise everything is fine https://docs.djangoproject.com/en/dev/ref/exceptions

I found a portion of the code that it is old (with other parts might happen the same!), this part; we don't need. We don't need the if settings.DEBUG anymore, we have a logger configuration that when DEBUG is there, a trace is always generated. And the old message is shorter and clearer than the new one. Done here -> fc849f0360

I am confused by the raises in proposed code (I also found other ones in the current django app), maybe the use of raise you are doing here is fine, just review it again. Because I saw how a generic rise in django command crashed the application, but maybe when you use this kind of raise everything is fine https://docs.djangoproject.com/en/dev/ref/exceptions I found a portion of the code that it is old (with other parts might happen the same!), this part; we don't need. We don't need the if settings.DEBUG anymore, we have a logger configuration that when DEBUG is there, a trace is always generated. And the old message is shorter and clearer than the new one. Done here -> https://farga.pangea.org/ereuse/devicehub-django/commit/fc849f0360dc0e9aad251c18cab8b7e441a1c0fa
pedro added 1 commit 2024-11-12 13:33:16 +00:00 
- We don't need the if settings.DEBUG anymore, we have a logger
configuration that when DEBUG is there, a trace is always generated
- restore old error message that is shorter and clearer than the new one
pedro added 1 commit 2024-11-12 13:38:21 +00:00 
specially, do not halt in case of errors, just print them in logs
pedro commented 2024-11-12 13:40:55 +00:00
Author
Owner
Copy link

Reviewed raises with @cayop ( 57f9e28466 )

@cayop needs to test it before merge

Reviewed raises with @cayop ( https://farga.pangea.org/ereuse/devicehub-django/commit/57f9e28466f11ec7903f5f55ddedfbb2648b42d9 ) @cayop needs to test it before merge
pedro changed target branch from real_main to main 2024-11-12 13:46:11 +00:00
pedro force-pushed pr_25 from 57f9e28466 to 65788b36af 2024-11-12 13:49:05 +00:00 Compare
pedro merged commit b7d7b9041d into main 2024-11-12 13:57:05 +00:00
pedro deleted branch pr_25 2024-11-12 13:57:07 +00:00
rskthomas commented 2024-11-12 14:00:53 +00:00
Owner
Copy link

Ive use the exceptions mostly to catch the errors and propagate them with a cleaner message (for ValidationError to display). Mostly because those are shown to the user, which may not know what did wrong. If there is a better and more idiomatic way of raising errors let me know as im new to django.

Ive use the exceptions mostly to catch the errors and propagate them with a cleaner message (for ValidationError to display). Mostly because those are shown to the user, which may not know what did wrong. If there is a better and more idiomatic way of raising errors let me know as im new to django.
Sign in to join this conversation.
Reviewers
No reviewers
cayop
Labels
Clear labels   
Compat/Breaking

Breaking change that won't be backward compatible

  
Kind/Bug

Something is not working

  
Kind/Documentation

Documentation changes

  
Kind/Enhancement

Improve existing functionality

  
Kind/Feature

New functionality

  
Kind/Security

This is security issue

  
Kind/Testing

Issue or pull request related to testing

  
Priority
Critical
The priority is critical

  
Priority
High
The priority is high

  
Priority
Low
The priority is low

  
Priority
Medium
The priority is medium

  
Reviewed
Confirmed
Issue has been confirmed

  
Reviewed
Duplicate
This issue or pull request already exists

  
Reviewed
Invalid
Invalid issue

  
Reviewed
Won't Fix
This issue won't be fixed

  
Status
Abandoned
Somebody has started to work on this but abandoned work

  
Status
Blocked
Something is blocking this issue or pull request

  
Status
Need More Info
Feedback is required to reproduce issue or to continue work

  
Test Deployed

this PR is deployed in a domain, so you can see

No labels
Compat/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
Test Deployed
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: ereuse/devicehub-django#27
No description provided.
Delete branch "pr_25"

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?