Annoying child table filter issue. Change to filter is not always respected

Frappe Framework
,
1

Problem: It seems that, that once a child table row is open for editing, its link fields no longer recognize changes to their query filter criteria.

I have a Select field called direction in a parent form, and a Link field called item in a child table row.

Each item in the child table DocType has an attribute called state.

My event handler on direction changes the list of allowed items by resetting the filter on item. For example:

returnablesTable.get_field('bottle').get_query = 
      () => ({ filters: [["Returnable", "state", "=", "Empty"]] });

It all works as expected, except…

The issue I face is this: a user might select a direction, then open an item for edit, then select a different direction. When that happens the filter from the first choice of direction continues to be applicable, the second choice is ignored.

Questions:

  1. Is this a bug?
  2. Is there a workaround?
  3. Short of refreshing the whole page, is there a way to tell the child table to forget all recent edits and revert to its state when the page was first setup?
2

Maybe, you should reset the filter when you change the value of direction.
direction: …

3

I reset the filter for every change of direction.

Once a row field has been the focus for editing, it will ignore subsequent filter changes, even if a different row gets editing focus.

4

try also refresh_field on the row field

5

Is this what you mean?

  returnablesTable.get_field('bottle').get_query = () => ({ filters: [["Returnable", "state", "=", "Empty"]] });
  returnablesTable.refresh_field('bottle');

Ultimately I tried …

  returnablesTable.get_field('bottle').get_query = () => stateLookUp[dir](from_stock, from_customer);
  returnablesTable.refresh_field('bottle');
  frm.refresh_field('bottles_moved');
  frm.refresh();

It looks right, and it does not throw a error…

… but, the problem remains.

6

Maybe debugger can help trace the cause of the problem?
Another thing to consider is the python end. Does the code involve whitelisted python?

7

We keep running into each other here on the forums @MartinHBramwell :slight_smile:

I can confirm that this get_query = function() “hack” no longer works as I have just tested it myself with my own issue

8

That sounds like a black hole. :frowning:

However, reading the code might help. Would you know where I might find the it in GitHub for someField.get_query()

No, it all happens in the browser, apart from the actual filter execution.

9

Heh! Yeah maybe some sort of collaboration is in order? :wink:

If you examine the code of, for example …

apps/erpnext/erpnext/accounts/doctype/sales_invoice/sales_invoice.js

… you’ll see that get_query = function() is used extensively, just about everywhere. If it stopped working, it’d break just about every DocType.

Actually, it DOES work for me, but it’s as if I only get one shot at it. Once I alter an affected field, it ceases to be possible to change its filter.

10

Ah, you’ve pointed me in the right direction!

One thing I noted was that the sales_invoice.js module you linked only does this get_query = () -> {} either on javascript load or during setup.

Here’s my solution for the issue:

        frm.fields_dict.items.grid.get_field('delivery_zone').get_query = function (doc) {
            return {
                query: "myapp.mymodule.doctype.delivery_zone.delivery_zone.get_zone_query",
                filters: my_filters_object
            };
        };

Separate your filters object to something you can edit outside the context of this get_query declaration; you can then change the filters object as needed.

2 Likes
11

The easy way to achieve that is via a custom script as follows

frappe.ui.form.on("Sales Invoice", "onload_post_render", frm => {
   frm.set_query("delivery_zone", "items", (doc, cdt, cnd) => {
        return {
            query: ".....",
            filters: {...}
        }
});
});
5 Likes