Closed grantfitzsimmons closed 1 month ago
There are likely other tables with this issue. We need to go through each of the tables that have attachments and try it out.
This issue has been mentioned on Specify Community Forum. There might be relevant details there:
https://discourse.specifysoftware.org/t/attachment-save-errors/1126/2
Perhaps a duplicate of #2409 and #2477. Also related to #2525
@grantfitzsimmons can you please merge the duplicate issues?
Once you fix the issue :wink: /s
Will do!
This does not happen with a new CT record.
https://willemcatno-edge.test.specifysystems.org/specify/view/collectingtrip/1057/
Steps to Recreate:
Edit the Latitude field (text5) (I have been able to recreate this with any field, but this was in the initial bug report)
Save
See error:
Invalid response code 500. Expected one of 200, 201, and 409. Response:
TypeError at /api/specify/collectingtrip/1057/
cannot unpack non-iterable NoneType object
Same database as https://github.com/specify/specify7/issues/2409. Seems to be a back-end error, but needs to be resolved ASAP.
Reported By: Willem at SAIAB
This is a problem in edge
and testability
.
TypeError at /api/specify/storage/91843/
cannot unpack non-iterable NoneType object
@melton-jason Is the fix you used here relevant to these issues?
@melton-jason Is the fix you used here relevant to these issues?
2744
I believe so. I have not looked at the Storage or Collecting Trip issue and uncovered the cause, but I think it is the same issue which means the fix should be the same as the fix for exchange in/exchange out.
The problem occurs as an attachment business rule problem and occurs at this line. https://github.com/specify/specify7/blob/0345888388ccf2d0366c96117b3c58469e770b80/specifyweb/businessrules/attachment_rules.py#L25
More specifically, Scoping(attachee)()
is returning None
, which python then tries to unpack into the scopetype and scopeid of the object's attachment
For quick reference, here is the Scoping class.
I tried to alleviate potential issues like this in #2744 by implementing a way to infer the table's scoping, but (obviously) it seems there is a bug in the code. According to the code's intended behavior, Collecting Trip (and thus its attachments) would be scoped to Discipline.
Aside from also fixing the bug, I will add scoping tests on the backend to reduce the possibility of this happening again.
That scoping.py file is criminally bug-prone. @melton-jason Can it be refactored to scan whether a table has collectionmemberid, division_id or discipline_id or etc and automatically determine scope based on that rather than have the programmer manually add scope like this to every table?
def locality(self): return self._simple_discipline_scope()
It is needlesly bug prone and causes issues like https://github.com/specify/specify7/issues/2525
That scoping.py file is criminally bug-prone. @melton-jason Can it be refactored to scan whether a table has collectionmemberid, division_id or discipline_id or etc and automatically determine scope based on that rather than have the programmer manually add scope like this to every table?
def locality(self): return self._simple_discipline_scope()
It is needlesly bug prone and causes issues like #2525
@maxpatiiuk
That is what I tried to do by adding an _infer_scope()
method in #2744: it checks if the object has collectionmemberid
, division_id
, or discipline_id
attributes and returns the respective scoping. If the object does not have any of those attributes, I assume the scoping is institution-wide.
I can fix the bug, add testing, then remove the redundant table methods and save that space for any tables that we wish to manually override.
oh that would be awesome! I didn't notice that. Thanks!
Same issue happens with DNA Sequencing Run attachments
Fixed
https://fwri-edge.test.specifysystems.org/specify/view/collectingtrip/991/
After uploading an attachment, you are unable to save without a crash.
Short error:
Full error:
Specify 7 Crash Report - 2023-04-03T18 45 35.340Z.txt
https://user-images.githubusercontent.com/37256050/229598925-40b92f9d-95bc-453e-8348-bf0553deb3fe.mov
Reported By: @Plarson at the Speciforum