[PROPOSAL] Many to Many Relationship

[areski]

Trying to figure out in the code base if many-to-many relation is supported. If not it would be nice to support it in future version.

When we tackle this it might be nice to consider 3 cases:

1. Multi checkboxes

2. 2 Columns to select options, django-admin style:

3. Tag Field: https://ant.design/components/select/#header

4. Multi Select Tree: https://ant.design/components/tree-select/

[aesmail]

Thanks for this. I wouldn't have considered some of the options you mentioned here. Each way has its own pros and cons. I think it might make sense to have checkboxes if there are only a few records. I really like the tag field. I prefer it over django admin's style of two select boxes.

IMHO, django's select boxes confuse people sometimes, especially non-technical admins. The tag field displays only selected records while hiding the rest until an action is explicitly taken to display them (clicking on the field). I find this approach nice, clear, clean, and compact.

My suggestion would be to support only the checkboxes and the tag field options.

What do you think?

[areski]

I actually think we would need the 3 options ideally. We can start with 1 and build up slowly from there or have kaffy extendable enough to let customer overwritting this or building their own.

There is a often recurring scenario where the 2 column Select is the unique , specially when you have a long of permissions, if you have the hundreds of options checkboxes become ugly and unmanageable. Tag also doesn't allow you to quickly select a lot of options.

I think we should take this problem one step at a time, probably start with checkbox, so we try solve it for with one solution and then extend from it.

We could have new form options into resource_form.ex: many_to_many_checkbox, many_to_many_select & many_to_many_tag

[areski]

I have just edited the ticket with a 4th option multi select-tree, it's nice combination

[aesmail]

if you have the hundreds of options checkboxes become ugly and unmanageable. Tag also doesn't allow you to quickly select a lot of options.

Good point. I think Kaffy should have different default behaviors for the number of existing many_to_many records, just like it is with belongs_to records.

If there are just a few records, say 1-10 records, by default choose the many_to_many_checkbox option. If there are 11-100, by default choose many_to_many_tag. If more than 100, by default choose many_to_many_select.

I'm not sure if this is the best thing to do. I'd like to provide the best default experience for the user.

I would also like to slightly change the way "2 select boxes" works. But I'm not sure how.

[areski]

It's a good idea to have Kaffy adapt to suit the best case scenario.

At the same time, I think having 3 different automatic behaviour would be too much, and it might confuse the user. Maybe we should consider only 2 automatic options down the line rather than 3, anyway we will have time to think about this when we get there!

[duck57]

Would any of these options support a child record being added multiple times, or would they function like a unique_together constraint on the two linked records in the join table?

The first demonstration example I've thought of is a list of cities a person has lived in: it's an ordered M2M join between person and city that needs to allow for the person to move back without losing the historical data. (ok, this is more than a simple M2M table, since you'd presumably want a “year moved in” field on the link record, so some table view is the editing widget that's best for a use case like this)

[aesmail]

@duck57 this is an interesting and a very valid point. I think, since all m2m relations basically go "through" a join table whether it has extra fields or not, the m2m support in Kaffy should also provide support for extra fields on the through table by default.

We should also have an option that identifies whether the records can be added multiple times or not.

Something like:

# Person schema
def form_fields(_) do
  [
    name: %{update: :readonly},
    cities: %{extra_fields: [:year_moved_in], unique_together: false}
    # other fields
  ]
end

Maybe we have extra_fields set to an empty list [] and unique_together set to true as default values. I think we could get all the extra information we need from the actual association from the schema.

I'm not sure how this is going to be displayed visually though so that needs to be dealt with.

This will definitely make the code more complex, but I think it's worth it.

[duck57]

Could one way of displaying the relationship be an editable table similar to the main table summary view? This would, of course, need to be limited in what other information is displayed—perhaps numeric, single-line text, and boolean checkboxes are the only valid fields for this display.

[willjleong]

Has anyone made progress on this? I'm using kaffy to handle admin tasks for an app I'm building but the data model has quite a few many-to-many tables. Wondering if anyone made progress on this in a fork since it seems like official Kaffy dev has stalled or stopped in the meantime.