I have table ‘projects’ with field ‘phase’. this field has relation to table ‘phases’ (to id). in this table records has fields ‘projectId’ (related to ‘projects’ table - id)’ and “name” (not unique)(i.e. ‘starting’, ‘in progress’). so each row in ‘phases’ associated with project and project can have several “phases”.
So, when I edit one project I want to set its phase but in dropdown I get all phases names (with duplicated names but which have different ids) from table ‘phases’. But I need listed here only phases related to current project I edit (it has id already).
I found that in this case that customizing this field as dynamic with fetching to my back which will extract project id from request and return only related to this project list of options. but I should return phases ‘ids’ because no sense return just “name”. but when I will select available phases for project I should see their ‘names’ for better understanding. I thought I can response to forest UI with something like { data: [ { id: phaseIdToInsert, name: phaseNameToShow }, … ] }. but in doc I see it accepts only array of strings. if I correctly understand it.
In other words: options of dropdown depend on “id” of current edited project.
So, maybe other ways to implement this functionality? Maybe I have to combine it with hooks?
Feature(s) impacted
Observed behavior
Expected behavior
Failure Logs
Context
- Project name: …
- Team name: …
- Environment name: …
- Agent technology: (nodejs, php, rails, python)
- Agent (forest package) name & version: …
- Database type: …
- Recent changes made on your end if any: …
Hello @Jeremy2024,
welcome to the community.
In order to better understand how we can help you, we would need you to fill in the following template:
- Project name: …
- Team name: …
- Environment name: …
- Agent technology: (nodejs, php, rails, python)
- Agent (forest package) name & version: …
- Database type: …
- Recent changes made on your end if any: …
Thank you
1 Like
Hello @Jeremy2024
If your agent version is compatible with this feature (it should be).
You can do so via front configuration:
- on your project table, with Edit mode enabled
- select your field to customize (documentation to access this view)
- the edit widget should be a “BelongsTo Typeahead”
- Access the configuration via the cog icon
- you should be able to define a filter like so:
Best regards,
1 Like
thanks. it looks great. but I forgot about similar case I also have to implement.
we have additional table ‘contracts’. with records that include ‘projectId’ and ‘phaseId’ fields related to primary keys of ‘projects’ and ‘phases’ tables.
and when we create or edit record on it, firstly we specify contract`s ‘project’ (projectId) and then we specify ‘phase’ which should have to depend on value specified in ‘‘project’’ right before. because now it listed all ‘phases’ table records but we have to filter that it lists only ‘phases’ related to ‘project’ (projectId) specified in previous field.
is it possible? as you explained it will look like {{ currentRecord.projectId }} for edit records with already presented ‘project’ (projectId). and will it work?
but in case we haven’t created record yet (adding new record) can we get value of prev ‘project’ field like {{ currentForm.projectId.value }} or something like that and list ‘phases’ options using their ‘name’ to better understanding (I know that forest admin make it automatically).
sorry for complicated explanation but now I don’t have rights to customize collection settings, only send recommendations to our project admins. in other case, I would explore it by myself.
I have been able to do something like this:
It is possible via templating to retrieve the id of deeper related records. However I discovered an issue; the templating is resolved by the frontend so if the record has not been queried before it may fail to properly fetch the value.
I am currently working on a “shortcut” that would try to retrieve the data from another path but it may not work in your case. This is all in the meantime that a proper fix is put in place, it may require a longer time to solve.
I will keep you updated via this thread.
1 Like
We are opting for the proper fix, the shortcut will not be merged as it would be useless if the path is 2 levels deep with unloaded records.
1 Like
thanks for investigation. so I will try to make it using hooks (to parse back responses and set ids instead of names but showing names) and fetching to my back as I described it on first post.
1 Like
If you are using the @forestadmin/agent you can do so using the replaceSearch customization on your collection, the context is forwarded by the frontend allowing you to modify the search for this use case exclusively.
2 Likes
Anyway, it will work only on edit with present projectId. Is it possible just show dropdown items of phase in format ${phase.name} - ${phase.projectId}? phases also have ‘projectId’ related to records in ‘projects’. it will great that we also can put there related ‘project.name’ based on ‘phase.projectId’
I see when I enter search values in ‘phase’ I get responses in format
{ data: [ { attributes: { id: '...', name: '...' } }, ...] }.
is there any way to customize that ‘name’ value using agent?
or I can add extra computed field in ‘phases’ collection using agent - ‘phaseNameAndProjectName’ which will concatinate and show value as
${phase.name} ${projects.find(({id}) => id === phase.projectId)?.name}
then on drop down we listed this ‘phase.phaseNameAndProjectName’
You can totally customise the value displayed inside the dropdown, it in fact displays the reference field of the collection. You can define a new field in Forest that will be set as your Reference field later on.
1 Like
Hello @Jeremy2024,
As promised, I’m keeping you updated 
The fix allowing to define the filter only in the frontend is live. You should be able to implement the solution we discussed initially.
Note that this will make the calls to your agent to fetch the records if they were not previously loaded in the frontend as it is responsible of constructing the filters.
Best regards,
2 Likes
Thanks a lot. I made it simpler, but this fix will come in handy in the future.
1 Like