Hey there, thanks! I agree, "Relation between <x> and <y>" will work in all cases.
Here’s a draft implementation: https://github.com/django/django/compare/master...julianklotz:feature_better_m2m_relation_labels Here’s what needs to be improved: - `create_many_to_many_intermediary_model`: The method uses both model classes and model class names; to access the verbose name, class names need to be resolved to “real” classes first. Any hints how to do that? `resolve_relation` doesn't to the job, because it returns both model names and classes, too. - Not sure how to implement tests for __str__ method without creating migrations? Let me know what you think about it. Julian Adam Johnson schrieb am Montag, 2. November 2020 um 10:21:06 UTC+1: > I don't think we can use just "Relation to" because M2M relationships are > two-way by default. Whilst a ManyToManyField can be declared on one model, > it adds a reverse field on the other model. We'd have to show both sides of > the relation e.g. "Relation between <x> and <y>". > > On Tue, 27 Oct 2020 at 08:56, Julian Klotz <jul...@pinabausch.org> wrote: > >> … one last thought: >> >> The verbose name could be: “Media Item-Piece relation” >> The string presentation could be: “Relation to <string presentation of >> to-instance>”, e.g. “Relation to Piece xyz” >> >> Together: >> *Media Item-Piece relation: Relation to Piece xyz (ID: 11773)* >> >> >> Julian Klotz schrieb am Dienstag, 27. Oktober 2020 um 09:30:59 UTC+1: >> >>> Hi Adam, >>> >>> thanks for picking this up so quickly. >>> I considered setting custom “through” models to set verbose name and >>> __str__, but I currently can’t “afford” changing all m2m fields throught >>> the application. >>> >>> Here’s the feedback I got concerning the usability issues (e.g. for >>> MediaItem_pieces_relation object (11773)) >>> >>> - Some people thought “11773” was the number of objects to be >>> deleted, even though the UI clearly states something else – it isn’t >>> obvious for some people that relations have their own IDs >>> - People asked where they could change the (then-deleted) relation >>> to a different object >>> >>> >>> >>> *It can also help with debugging as the label appears in the default >>> str/repr.* >>> Thanks for giving me that hint. It’s the __str__ method of models.Model. >>> Changing the default string presentation may be dangerous and also too >>> generic. It would make sense to define a custom to-string method in >>> `create_many_to_many_intermediary_model` (fields/related.py)*.* >>> Instead of showing *MediaItem_pieces_relation object (11773),* >>> something like “Media Item-Piece relation, ID: 11773) would be good*; >>> *moreover, >>> it may be a good idea to show the “from” model’s edit link to point people >>> to the place where they can change this relation. >>> >>> *My main question is, does this not trigger migrations on user projects?* >>> Good point. I just checked – interestingly, neither changing the verbose >>> name nor the __str__ method triggers new migrations 🥳 >>> >>> >>> >>> Best regards >>> Julian >>> >>> Adam Johnson schrieb am Montag, 26. Oktober 2020 um 19:56:15 UTC+1: >>> >>>> Hi Julian >>>> >>>> It should be noted that you can improve the display today by creating >>>> explicit through models. However this is more longwinded. >>>> >>>> This change does look like a neat usability improvement to me. It can >>>> also help with debugging as the label appears in the default str/repr. My >>>> main question is, does this not trigger migrations on user projects? >>>> >>>> Thanks, >>>> >>>> Adam >>>> >>>> On Mon, 26 Oct 2020 at 16:28, Julian Klotz <jul...@pinabausch.org> >>>> wrote: >>>> >>>>> >>>>> Hey there, >>>>> >>>>> here’s a little topic that impacts the usability of Django admin’s >>>>> delete views. >>>>> >>>>> When deleting an object using django admin, you get a nice summary of >>>>> all deleted objects. >>>>> I really like the overview, but the labels used to describe m2m >>>>> relations that will be deleted aren't user-friendly at all: >>>>> >>>>> […] >>>>> >>>>> - MediaItem-subseries-relation: MediaItem_sub_series_relation >>>>> object (11482) >>>>> - MediaItem-piece-relation: MediaItem_pieces_relation object >>>>> (11773) >>>>> >>>>> So I’d like to improve the labels a bit, using the from and to model’s >>>>> verbose names. This can be easily accomplished by changing >>>>> `create_many_to_many_intermediary_model` in fields/related.py. >>>>> >>>>> To be honest, I don’t know how to update the tests for something >>>>> rooted deeply in Django’s core.Is anyone who is more competent than me >>>>> interested in fixing this? It would greatly improve the “delete >>>>> confirmation“ views. >>>>> >>>>> Here’s what I’ve got so for; it only fixes the model’s verbose name, >>>>> not its string presentation. >>>>> >>>>> Best regards >>>>> Julian >>>>> >>>>> >>>>> […] >>>>> to = make_model_tuple(to_model)[1] >>>>> from_ = klass._meta.model_name >>>>> >>>>> if isinstance(to_model, str): >>>>> to_label = to >>>>> to_label_plural = to >>>>> else: >>>>> to_label = to_model._meta.verbose_name >>>>> to_label_plural = to_model._meta.verbose_name_plural >>>>> >>>>> from_label = klass._meta.verbose_name >>>>> from_label_plural = klass._meta.verbose_name_plural >>>>> >>>>> if to == from_: >>>>> to = 'to_%s' % to >>>>> from_ = 'from_%s' % from_ >>>>> >>>>> meta = type('Meta', (), { >>>>> 'db_table': field._get_m2m_db_table(klass._meta), >>>>> 'auto_created': klass, >>>>> 'app_label': klass._meta.app_label, >>>>> 'db_tablespace': klass._meta.db_tablespace, >>>>> 'unique_together': (from_, to), >>>>> 'verbose_name': _('%(from)s-%(to)s relationship') % {'from': >>>>> from_label, 'to': to_label}, >>>>> 'verbose_name_plural': _('%(from)s-%(to)s relationships') % >>>>> {'from': from_label_plural, 'to': to_label_plural}, >>>>> 'apps': field.model._meta.apps, >>>>> }) >>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Django developers (Contributions to Django itself)" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to django-develop...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/django-developers/69b6f2e0-8f0e-4cd0-b608-46fb9040b355n%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/django-developers/69b6f2e0-8f0e-4cd0-b608-46fb9040b355n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> >>>> >>>> -- >>>> Adam >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-develop...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/3157b818-5b0d-46c8-8a27-239357235273n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/3157b818-5b0d-46c8-8a27-239357235273n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > Adam > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9e23a5d9-163c-4647-aecd-3e6d48729cf5n%40googlegroups.com.
