verbose_field_name can break on manytomany relationships

[JamesRamm]

Some change between 1.0.2 and 1.0.3 has meant verbose_field_name can now raise an AttributeError in cases where the related_name on a ManyToManyRel is None, which can happen.

Specifically this line:

names.append(part.related_name.replace('_', ' '))

I suggest changing it to something like:

if part.related_name:
   names.append(part.related_name.replace('_', ' '))
else:
   names.append('None')

which is what you wouldve got from 1.0.2

[carltongibson]

@JamesRamm Yep. Seems reasonable.

If you put together a test case and patch I'll push a new release with that.

[carltongibson]

This is ref #686 and test_utils.py

[rpkilby]

@JamesRamm - can you give a simple example of the models. Would this be related to related_name='+'?

[rpkilby]

Also, names.append('None') would give the old behavior, but it doesn't seem like the desired behavior.

[JamesRamm]

I think this may be to do with use of a 'through' model on an m2m, but I cannot be 100% sure - still working toward a smallest possible scenario to repeat it.

[g-as]

I have this when reversing a ForeignKey, where part is a ManyToOneRel with a None related_name.

[Fingel]

I can confirm this bug. I'm not sure which model in my application is causing it, but I've had to revert to 1.0.2 for now.

[JamesRamm]

@AGASS007
Yes that is essentially what ours amounts to - our model relationships are more convoluted so it is a bit harder to decipher where it is coming from, but after running it through get_fields you do end up with a ManyToOneRel with None.

Anyway, ending up with related_name as None is valid in django so it would be best to handle gracefully.

@rpkilby

Also, names.append('None') would give the old behavior, but it doesn't seem like the desired behavior.

I agree it may not be desired behaviour although I think it should be handled since it is a valid situation. I guess an ideal solution would be to somehow fallback on some name based on the ForeignKey model? (class.name or something?)

[carltongibson]

I'll take a quick patch with test over the perfect solution for this.

[carltongibson]

Right, has anyone got a reproduce for me?

[carltongibson]

#722 provides a test an workaround for this. Can you give it a run and confirm it resolves your issue. (We can come back for v1.1 to improve behaviour.)

Bonus points if you can explain the failing test case behaviour.

[Fingel]

#722 solves our issue. Nice!

[carltongibson]

https://github.com/carltongibson/django-filter/releases/tag/1.0.4 is now available.