1-N relation not showing display text

[Hackster93]

If there is an attachment widget in the child form, the display text doesn't show, and instead it tries to show the image (even if there is no image attached). Need to be able to specify to display the image or the display text.

[zezzagio]

Why is this not tagged as a bug?

[PeterPetrik]

• The image is not shown because of the bug Photo preview in parent relation feature is broken when photo field is not selected as layer display field #2058
• The display text is only shown when the child feature does not contain any photo widget (attachment widget) and we take it for now as feature. We would need to add some additional settings to determine if to use photos or text in parent feature, or implement such setting in QGIS for qgis forms too. Therefore reclasifying this as enhancement for now

best to add this to whishlist.merginmaps.com and if it gets enough upvotes we can work on it.

Thanks for reporting issues!

[zezzagio]

Maybe it's because I'm not a native English speaker (either a very fluent one), but I don't understand. Isn't the "Display name" setting enough to know what to do? isn't this the behavior in QGis? "The feature display name is used in identify results, locator searches and the attribute table's dual view list"

Why would the user have chosen a text expression, if they actually wanted the photo? to me it seems like an unmotivated and somewhat paternalistic presumption: "How silly, of course you want the photo, this is the best for you"

Why should the attachment always be the most important thing to show? what if it's not a photo? what if there are two or more of them per child record?

[AndyWalsh1]

I’m really pleased this relation bug is being worked on as it has been frustrating ever since we’ve been using the app and has been repeatedly reported to us by end users numerous times. Apologies if I’m misunderstanding how the fix will work but assuming that the photo preview will remain I do agree with @zezzagio comment above that it would be much better if the expression was used/visible to the end user rather than a preview. Given the small size of the preview on most screens is rather meaningless and even more so if there are multiple photos associated with the child feature and/or the photos are likely to be of the same type of object (eg trees, buildings, bore holes etc) or in our case if you’ve added an attachment which provides user guidance (as a result of fields not wrapping so not having enough space for guidance in the form eg #1720)

[zezzagio]

In my opinion (and as per QGis behaviour) the display name expression is not a replacement for the photo if the photo, for some reason, is not available; it's what the user want to be displayed, in any case.

So, I don't understand the problem: the app should do what the user ask; if not, I call it a bug, not a feature.
I don't understand the #2860 issue, either: just choose the attachment field as display name.

But then, there is a lot of things I don't understand, so maybe it's me.

[PeterPetrik]

@AndyWalsh1 thanks for the feedback. We would be glad if you have few minutes to talk to @tomasMizera on video-call to get some broader feedback from using the app.

---

Let me clarify the situation. As of now, the mobile app works in a way that it prefers gallery-mode if child has photo widget, otherwise text-mode (based on display text). This is how it was designed few years ago (good or bad that is matter of discussion and possible change in next releases). I have just fixed the bug in the described implementation (#2058).

Change of the behaviour itself is enhancement. I agree that it would be good to have an option for admin users to choose which mode to use, but how it should work is not that easy to satisfy everyone (probably we need another setting in the Mergin Maps Plugin in QGIS).

Please vote on the https://wishlist.merginmaps.com/p/choose-preview-mode-of-child-layer-features-inside-relation-widget-within-parent-feature-form . More votes it has, the more priority it gets in our development time.

[zezzagio]

Thank you. I read some discussions about this topic and now the problem is clearer to me. You are conditioned by the choice you have made.
In my opinion it was a bad choice, and probably more difficult and complicated to implement than the "right" one (that that I perceive as the right one.) But this is me; and, as you say, is not that easy to satisfy everyone.

[AndyWalsh1]

@PeterPetrik @tomasMizera yep will do!

[saberraz]

I am re-opening the issue, as it has started appearing again in the latest release. Happy to share a project for this issue.