Actually I changed sqlalchemy version to sqlalchemy==1.4.46, It works.

I think this does indicate that Flask-Admin does not work as one would expect for SqlAlchemy>2.0 and the requirements should be pinned to indicate that or else a patch to make relationship fields work properly out of the box as you would expect.

Have the same issue. It makes impossible using flask-admin with sqlalchemy 2.0 and it's painful!

Here's the code to reproduce:

from flask import Flask
from flask_admin import Admin
from flask_admin.contrib.sqla import ModelView
from flask_sqlalchemy import SQLAlchemy

db = SQLAlchemy()
admin = Admin()

app = Flask(__name__)

app.config["SQLALCHEMY_DATABASE_URI"] = "sqlite:///project.db"
app.config["SECRET_KEY"] = "secret"


db.init_app(app)
admin.init_app(app)


class User(db.Model):
    id = db.Column(db.Integer, primary_key=True)
    username = db.Column(db.String)
    email = db.Column(db.String)


class Post(db.Model):
    id = db.Column(db.Integer, primary_key=True)
    text = db.Column(db.String)
    user_id = db.Column(db.Integer, db.ForeignKey('user.id'))
    user = db.relationship('User')


admin.add_view(ModelView(User, db.session))
admin.add_view(ModelView(Post, db.session))

with app.app_context():
    db.drop_all()
    db.create_all()

app.run()

Here's requirements:

attrs==22.2.0
blinker==1.6.2
click==8.1.3
Flask==2.3.2
Flask-Admin==1.6.1
Flask-SQLAlchemy==3.0.3
iniconfig==2.0.0
itsdangerous==2.1.2
Jinja2==3.1.2
MarkupSafe==2.1.2
packaging==23.0
pluggy==1.0.0
pytest==7.2.2
SQLAlchemy==2.0.13
typing_extensions==4.5.0
Werkzeug==2.3.4
WTForms==3.0.1

There's no any user or user_id in views for Post model:

I made PR.

What happens if you add the foreign key manually?

from flask import Flask
from flask_admin import Admin
from flask_admin.contrib.sqla import ModelView
from flask_sqlalchemy import SQLAlchemy

db = SQLAlchemy()
admin = Admin()

app = Flask(__name__)

app.config["SQLALCHEMY_DATABASE_URI"] = "sqlite:///project.db"
app.config["SECRET_KEY"] = "secret"


db.init_app(app)
admin.init_app(app)


class User(db.Model):
    id = db.Column(db.Integer, primary_key=True)
    username = db.Column(db.String)
    email = db.Column(db.String)


class Post(db.Model):
    id = db.Column(db.Integer, primary_key=True)
    text = db.Column(db.String)
    user_id = db.Column(db.Integer, db.ForeignKey('user.id'))
    user = db.relationship('User')

class PostAdmin(ModelView):
    column_list = ('user', 'text')


admin.add_view(PostAdmin(Post, db.session))

with app.app_context():
    db.drop_all()
    db.create_all()

app.run()

@ElLorans then it works properly. But manual adding for every relationship is not what we are used to while using flask admin with sqla < 2.0.

I understand, but this workaround makes possible to use SQLAlchemy >2.0, so I thought sharing could be useful.

@ElLorans surely. You did great, thanks! I will use it while waiting for a fix from developers not to use any workarounds for a long time

There is an open PR here that would allow full usage of flask-admin with SQLAlchemy>2.0 - is there something blocking it from being merged?

Is this also the reason why when using the example below and trying to tap on "Create" will give:

ValueError: not enough values to unpack (expected 4, got 3)

Or is that unrelated?

Is this also the reason why when using the example below and trying to tap on "Create" will give:

ValueError: not enough values to unpack (expected 4, got 3)

Or is that unrelated?

That looks like WTForms 3.1.0 #2391.

I'm so glad I was able to find this issue posted. I have been stuck with this for ages. I was able to implement the workaround where I would specify the column myself but I will have many models and it wouldn't make sense to do that for each of them.

I had to downgrade sqlalchemy to 1.4.46 as mentioned above and also Flask-SQLAlchemy to 3.0.5 so it works with this sqlachemy version.

I hope a fix will be implemented soon.

Edit: It works on the older version but the relationship from the Parent to Child is still not displaying unless you specify the column manually which apparently has been an issue for a longer time.