Different admin sites for blueprints? about flask-admin

[mrjoes]

Blueprint name collision happens because you need unique endpoint names for each view. If endpoint is not explicitly passed to the constructor, it will be automatically generated and might collide with other views.

I modified multi.py example to illustrate how to avoid name collisions: https://gist.github.com/mrjoes/b42defe0f420097f40c7

[techniq]

The issue is if you don't set an index_view when creating the Admin instance (ex. admin = Admin(index_view=SomeView)), the extension will create an instance of AdminIndexView, which creates a blueprint at the same endpoint ('admin'). I tried to get around this myself by setting an index_view for my second instance of Admin, but there is a hard check to make sure only 1 instance of the extension exists for the app (see: https://github.com/mrjoes/flask-admin/blob/master/flask_admin/base.py#L442).

I was looking to create multiple Admin instances for different levels (Global admin, Organization admin, etc). I think part of the issue with having more than 1 instance will be how the templates can generate the UI with more than 1. I was a bit surprised that each View within the extension is a blueprint, and not just 1 blueprint for the extension (maybe I'm not understanding the code flow).

@mrjoes your thoughts on supporting multiple instances?

[mrjoes]

It is not a problem to support multiple Admin instances per one Flask application. Will require some changes in localization support, but it should not be a big deal.

There are few reasons why each view is encapsulated into separate blueprints: views are independent of each other, it is possible to use Flask built-in blueprint helpers (like url_for('.view') to get "local" URLs) and so on.

As for the administrative interface structure: I'd go with permission based approach. If is_accessible() returns False for the view, it won't be displayed in menu either. So, you can create few base classes (or mixins) one for each administrative "level". Then, compose your admininstrative interface using these pieces.

I guess having separate administrative interfaces might also work as well, but each "level" will be its own UI.

@mrjoes Exactly, I've made a work around by creating multiple views with different implementations of is_accessible().

I guess the different UIs might be something to consider. For instance:

/app/admin - contains user data/global objects
/app/sub-app/admin - contains app specific stuff but uses user/global objects

Could have a need for separate UI views.

[techniq]

That was fast, thanks. I'll be trying this out in the next few days and will report any issues.

[techniq]

I set this up without any issue. Thanks again.

[nickjbyrne]

This doesn't work for me (1.0.5). I have one instance configured in file1 and another in file2 with a similar set of models configured but with different configurations (column_list etc). I have passed a different url and endpoint to each Admin instance, but when i import and init_app these i get a blueprint name collision.

[nickjbyrne]

Awsome thanks, i new i was missing something obvious