I ran into some issues dealing with M2M relationships resulting in "null" being recorded as the fieldname for adds/removes on changes to proxy models which led me to #207
This PR re-writes get_m2m_field_name to use the sender that gets passed to the signal handler, which happens to be the through model.
Given the through model, the changed instance, and the added model; we can uniquely determine which field on the instance model was changed, even if the originating model has multiple M2M relationships with the remote model (since each will use a different intermediate model).
There was also an issue that I didn't see in the issue tracker that came up for me; if the changed instance was a proxy model then get_m2m_field_name would return None . This also resolves that issue since we are searching for the field directly
rgegriff
commented
7 months ago
I ran into some issues dealing with M2M relationships resulting in "null" being recorded as the fieldname for adds/removes on changes to proxy models which led me to #207
This PR re-writes
get_m2m_field_nameto use thesenderthat gets passed to the signal handler, which happens to be the through model.Given the through model, the changed instance, and the added model; we can uniquely determine which field on the instance model was changed, even if the originating model has multiple M2M relationships with the remote model (since each will use a different intermediate model).
There was also an issue that I didn't see in the issue tracker that came up for me; if the changed instance was a proxy model then get_m2m_field_name would return
None. This also resolves that issue since we are searching for the field directly