Self-hosting, schema, and database permissions

Help me!
1

Creating a new post based on https://community.forestadmin.com/t/issue-with-relationships-not-showing-in-a-database-and-cannot-be-configured-web-interface/7642/9?u=mderriey-makerx.

Feature(s) impacted

The ability to use an admin user in local dev for smart relationships to be discovered and persisted into the .forestadmin-schema.json file, while the deployed version uses a user that can’t introspect the schema.

Observed behavior

For tables that have relationships, the dashboard shows the following. Tables without relationships work fine.

image
image720×452 13.5 KB

Expected behavior

Table that have relationships show data based on the JSON schema.

Failure Logs

warning: [400] GET /personal_wallet - 326ms

===== An exception was raised =====
GET /personal_wallet?{
 timezone: Europe/Paris,
 fields[personal_wallet]: address,created_date,external_id,id,updated_date,user,
 fields[user]: Name,
 page[number]: 1,
 page[size]: 15,
 sort: -id
}

 Invalid projection: The 'personal_wallet.user' field was not found. Available fields are: [id,created_date,updated_date,user_id,external_id,address]. Please check if the field name is correct.

Context

I could reproduce this locally.

The starting point is a working dashboard, where the JSON schema doesn’t contain relationships as it’s using the Forest Admin database user that doesn’t have permissions.

Actions:

  1. Update the database user to be the admin user.
  2. Restart the app.

At this stage, the typings and JSON schema files are updated.
Refreshing the Forest Admin dashboard shows all the tables with smart relationships working as expected.

Actions:

  1. Stop the app.
  2. Update the agent configuration with skipSchemaUpdate: true.
  3. Update the database user to be the Forest Admin specific user.
  4. Start the app.

The logs show the following as expected:

warning: Schema update was skipped (caused by options.skipSchemaUpdate=true)

However, navigating to a collection that has relations shows the error page above, and the log output contains the block pasted above.

  • Project name: mderriey-moja
  • Team name: Operations
  • Environment name: Development
  • Agent technology: Node.js
  • Agent (forest package) name & version: @forestadmin/agent v1.60.1
  • Database type: Postgres
  • Recent changes made on your end if any: None
1 Like
3

Hello @mderriey-makerx,

Thanks for the detailed report, I’ll try to reproduce first and come back to you :slight_smile:

4

I think there might have been a misleading configuration somewhere.

The option skipSchemaUpdate=true will not only prevent the generation of the schema but it will also prevent the POST of the schema to our server. What you should be aiming at is simply preventing the re-generation of your schema in a production environment.

Could you replace skipSchemaUpdate by isProduction, and redeploy your project in production and/or remote.

5

Hi,

Thanks for the reply.

I tried that and the behaviour is the same.
I could see the schema being posted to Forest Admin.

Actions:

  1. Update the database user to be the admin user.
  2. Restart the app.

At this stage, the typings and JSON schema files are updated.
I can also see in the logs that a new schema was posted.
Refreshing the Forest Admin dashboard shows all the tables with smart relationships working as expected.

Actions:

  1. Stop the app.
  2. Update the agent configuration with isProduction: true
  3. Update the database user to be the Forest Admin specific user.
  4. Start the app.

There, I can see that the schema is posted, but no updated happened (Schema was not updated since last run (hash: b3f4f0900c7d571703895ab12b070c7bd9c3ad28)).

However, upon clicking on a collection that has relationships, the same error occurs.

6

Could you try to set the loggerLevel: 'Debug' on your agent startup options ?

I have not been able to reproduce yet, on my side everything works properly but that might be due to how I’ve configured the roles on my side.

7

Sure thing.

Strangely, the specific ===== An exception was raised ===== error message disappeared, but the issue remains.

I could observe on startup that the agent seems to introspect the database, although I confirmed that the JSON schema was loaded from the file system (this code block).
If that’s expected, then it’s probably the source of the issue, as the database user cannot introspect the Postgres schema, especially the constraints.

Then, when accessing a collection that has relationships defined, the logs show the following:

warning: [400] GET /user - 6ms
debug: User null is allowed to perform collection:user:browse
debug: SELECT COUNT(*) AS "__aggregate__" FROM "public"."user" AS "user" ORDER BY "__aggregate__" DESC NULLS LAST;
info: [200] GET /user/count - 17ms
info: [200] GET /authentication/callback - 270ms

Similar log entries can be seen when accessing other collections.

Let me know if that helps, happy to try something else to help debugging the issue.

8

Sorry I was confused yesterday, I mixed up the workings of the @forestadmin/datasource-mongoose with @forestadmin/datasource-sql.

In your case, the datasource-sql will still perform an introspection even with the option isProduction=true, to avoid having the introspection done you will need to cache the introspection and commit it to your production environment along with the code changes. Here is the doc page on how to do so.

1 Like
9

Legend, thanks a lot, that worked a treat :tada:

2 Likes