Request query context

Feature(s) impacted

Many-to-many search and other scoped routes.

Observed behavior

request.query.context is now undefined.

Expected behavior

request.query.context used to contain the context surrounding the query, and very importantly the record type.

This notably allowed to filter field inputs using many-to-many relationships. For example, given Artists and Bands, you could filter the CurrentlyActiveBand input to only show the bands that the artist is in.

Is there another way to achieve the same result?

Context

  • Agent type & version: forest-express-sequelize 8.5.12

Can you provide me a bit more information so that I can check?

The closest system I know about, that seems related to your thread, is the forest-context-url that the frontend sends as a header to tell the agent which page is requesting a given resource.

request.query.context is now undefined.

I understand the frontend was sending a context key in the query-string and not anymore?
Can you tell me the exact route?

Can you know when we stop sending that key so that I can check the changelog?

Hey @anon39940173

I found the answer that I used back in the day : Relationship dropdown edit widget filter - how to filter dataset based on current entity - Help me! - Forest Admin Developers Community.

There was indeed a context object on the query which contained various data about, well, the context in which the query was made. Kind of the same information you would get from the header you talk about, but already properly parsed.

I started logging crashed for this (TypeError: Cannot read properties of undefined (reading 'record')) in either April or June of this year, when we upgraded our forest-express-sequelize version.

I’m not sure I understand your use case, (nor @anon34731316 reply last year for that matter :sweat_smile:).

Relationships should be natively handled without the need to override any route as long as they are declared in the sequelize models ( Artists.belongsToMany(Band) ).

And the route you are overriding is the one powering the main list, not relationships.

So if you take the context of the original question, there was never any need for a custom route handler?

What was not natively handled was restricting a field’s displayed values on the front-end depending on an arbitrary condition.

On which page?
Can you explain the whole use case?

You organize meetings

  • Meetings have Participants
  • Meetings have Groups
  • Each Participant has one Group

When editing a participant to set its group, Forest will list and allow every single group of every single meeting. In my case, I want Forest to only display the meeting’s groups, not groups of other meetings.

OK! I think i got it finally.

The issue is about the widget that is used to select the group in the edition form.
I’ll check for request payload changes for that widget and come back to you

1 Like

Can you check for me if you are using a BelongsToTypeahead or a BelongsToSelect widget on that field (in the participant.group field)

Using both, I’m actually getting the context query string parameter, can you check on chrome inspector that this is not the case for you?

2 Likes

Ah it seems I was using a dropdown in the end! That’s why no context was provided.

Thanks for your help =D

1 Like