Impossible to create smart action

Help me!
1

Expected behavior

Following this tutorial: https://docs.forestadmin.com/documentation/reference-guide/actions/create-and-manage-smart-actions

When in the forest folder, in my collection file, I add this:

  actions: [{ 
    name: 'Mark as Live'
  }],

I expect, when I rebuild the back container, to see the action appear on the web interface (after I refresh the browser, obviously).

Actual behavior

Nothing happens, the smart action does not appear on the web interface, even after a refresh.

2

When I check Chrome dev tools, I see this endpoint:

https://api.forestadmin.com/api/collections/76bd3a30-9526-11ea-9f36-4f4d1a1e01d9/custom-actions

returns {data: [ ]}

So what is configured in the backend code does not seem to be transmitted to FA web app

3

hello @francois_Ruty, me again, I wrapped your code in ` apices so that the syntax highlighter does not get confused and create a clickable todo: . You can create a code block of one or multiple lines by pressing on this button in the editor toolbar:
image

4

ok thanks

It would be great if a person from FA could give me a way to debug why the backend code does not return the custom actions properly

5

@francois_Ruty :wave:

To be absolutely sure, do you mean you restarted your admin backend?
On which collection did you try to add this smart action?
Can you share a screenshot of your collection definition and of the actions you see / donā€™t see on the web browser?

Thank you.

6

Hello, OK so I figured this out.
When I say rebuild the container, I mean rebuild, = docker-compose build.

I changed my DB schema today so I re-run Lumber to generate the models.
Problem is, Lumber changed convention and my DB table gsheet_clients became ā€˜gsheetClientsā€™ collection (it was not the case 3 months ago)

The file in forest folder still used the old collection name gsheet_clients which explains why the actions defined there were not picked up.
I think this convention change may also explain why I lost all web UI layout configuration (cf my other ticket), since models changed names.

To tell you the truth Iā€™m a bit disappointed, all this is due to the fact that Lumber docker container is not versioned, I reported this in february already, and the docker hub still has no version tags!
It literally takes 5min to start versioning a container.

Without this, itā€™s gonna be a constant pain to work with ForestAdmin since each time I use Lumber to update something I donā€™t know what breaking changes Iā€™m gonna get since Iā€™m forced to use lumber last version all the timeā€¦

7

Hi @francois_Ruty,

Sorry to read your frustration.

I am not really sure to understand your development workflow.
I feel that you use Lumber commands to update your models.
This is not really advised so far.
The best thing to do is to manually edit your models according to your database changes.

I may be wrong about your workflow, it would help a lot if you could detail step by step your actions for a new column addition for instance.

Thanks for your feedback

8

Hello, thatā€™s correct, I sometimes use Lumber to update backend code

What I donā€™t understand is, if Lumber is not meant to be used to update backend code, why force people to use it? ForestAdmin could just ask for a REST API to be set up that complies with a set of specs, and then people can develop the API however they want

This means that right now, when I set up ForestAdmin, Iā€™m forced to initialize the API code with Lumber and then I canā€™t use it anymore which means Iā€™m stuck with editing manually Lumber-generated boilerplate code

At the very least Lumber should be usable to update the models. All ORMs on the market do that, if people had to edit manually ORM-generated code, nobody would use Django and other frameworks

9

Hello @francois_Ruty :wave:

It is clear you have been struggling to get your smart action working, and we apologise.

Let me just answer to your previous message to add some more explanations about our vision of the admin panel.

Lumber has first been dedicated to create a backend application compatible with ForestAdmin as fast as possible. So forcing people to adapt / create their own API to be pluggable with ForestAdmin is not our vision, and could be quite deterrent to be honest. Regarding lumber on its own, we plan to add some more feature to enrich development experience, but this is not the intended behaviour for now.

In fact this is part of our vision, we provide isolated, out-of-the-box admin panel on which you have full control. Which implies having to maintain your own code.

I understand your remark, please let me push this feedback to our product-board. We are working on a lot of features lately, one of which is to improve lumber update command. But I canā€™t provide you any ETA.

Regarding your docker development experience, you donā€™t need to rebuild the image if you only changed the generated app code. Simply running docker-compose down && docker-compose up -d will restart and take your changes into account :+1: Moreover, as you suggested in the past, we added versioning to our docker containers.

Again we apologise for the inconvenience, and we thank you for your feedbacks.

Donā€™t hesitate if you have any further requests / remarks.

Steve.

2 Likes
10

Thanks for your detailed answer, I only have one remark left, on my side at the moment I indeed need to rebuild the container for changes to be taken into account, because I had to remove the source code volume mapping from the lumber-generated docker-compose.yml, if I didnā€™t the backend nodejs app would crash with ā€œcannot find module dotenvā€, I reported this on Slack 3 or 4 months ago

I think whatā€™s going on is that the Dockerfile installs the node_modules dependencies (including dotenv) but it is inside the container, and this volume mapping overwrites it with the host source code
Itā€™s a classic docker dev environment issue, I donā€™t think there is a good workaround
Personally in dev environment I always use source code volume mappings like you do, but I always need to do a docker-compose exec {container} /bin/bash and then npm install, each time I change the package.json
The source code volume mapping lets you have the hot reloading, but overwrites the node_modules stuff installed by the Docker build

11

Hello @francois_Ruty :wave:

Alright thanks for this additional feedback. I understand the problem with the volume mapping and managing dependencies (present in the container, not in the source folder for mapping). It makes sense now why you are struggling with builds using docker. I have pushed your message to my team.

Improving development experience for our docker stack is definitely on the road, and this kind of feedback really helps out :raised_hands:

Steve.