Flask-Admin

Flask-Admin is a batteries-included, simple-to-use Flask extension that lets you add admin interfaces to Flask applications. It is inspired by the django-admin package, but implemented in such a way that the developer has total control of the look, feel and functionality of the resulting application.

You can see some examples of how Flask-Admin can be used at http://examples.flask-admin.org.

Browse through the documentation below to learn more about what you can do with Flask-Admin. Or head over to our GitHub repository to find out how you can contribute to the project.

Quick Start

This page gives a quick introduction to the Flask-Admin library. It is assumed that the reader has some prior knowledge of the Flask framework.

If you’re a Django user, you might also find the Migrating from Django guide helpful.

Introduction

The library is intended to be as flexible as possible. And the developer should not need to monkey-patch anything to achieve desired functionality.

The library uses one simple, but powerful concept - administrative pieces are built as classes with view methods.

For example, here is an absolutely valid administrative piece:

class MyView(BaseView):
    @expose('/')
    def index(self):
        return self.render('admin/myindex.html')

    @expose('/test/')
    def test(self):
        return self.render('admin/test.html')

If the user visits the index view, the admin/myindex.html template will be rendered. In the same way, visiting the test view will result in the admin/test.html view being rendered.

So, how does this approach help in structuring an admin interface? With such building blocks, you’re implementing reusable functional pieces that are highly customizable.

For example, Flask-Admin provides a ready-to-use SQLAlchemy model interface. It is implemented as a class which accepts two parameters: the model class and a database session. While it exposes some class-level variables which change behavior of the interface (somewhat similar to django.contrib.admin), nothing prohibits you from inheriting from it and overriding the form creation logic, database access methods or extend existing functionality by adding more views.

Initialization

To start using Flask-Admin, you have to create a Admin class instance and associate it with the Flask application instance:

from flask import Flask
from flask.ext.admin import Admin

app = Flask(__name__)

admin = Admin(app)
# Add administrative views here

app.run()

If you start this application and navigate to http://localhost:5000/admin/, you should see an empty “Home” page with a navigation bar on top

You can change the application name by passing a value for the name parameter to the Admin class constructor:

admin = Admin(app, name='My App')

As an alternative to passing a Flask application object to the Admin constructor, you can also call the init_app() function, after the Admin instance has been initialized:

admin = Admin(name='My App')
# Add views here
admin.init_app(app)

Adding views

Now, lets add an administrative view. The next example will result in two items appearing in the navbar menu: Home and Hello. To do this, you need to derive from the BaseView class:

from flask import Flask
from flask.ext.admin import Admin, BaseView, expose

class MyView(BaseView):
    @expose('/')
    def index(self):
        return self.render('index.html')

app = Flask(__name__)

admin = Admin(app)
admin.add_view(MyView(name='Hello'))

app.run()

One important restriction on admin views is that each view class should have a default page-view method with a root url, ‘/’. The following example is correct:

class MyView(BaseView):
    @expose('/')
    def index(self):
        return self.render('index.html')

but, this wouldn’t work:

class MyView(BaseView):
    @expose('/index/')
    def index(self):
        return self.render('index.html')

Now, create a new index.html file with following content:

{% extends 'admin/master.html' %}
{% block body %}
    Hello World from MyView!
{% endblock %}

and place it in a templates directory. To maintain a consistent look and feel, all administrative pages should extend the admin/master.html template.

You should now see your new admin page in action on the Hello page

To add another level of menu items, you can specify a value for the category parameter when passing admin views to the Admin instance. The category specifies the name of the top-level menu item, and all of the views that are associated with it, will be accessible from a drop-down menu. For example:

from flask import Flask
from flask.ext.admin import Admin, BaseView, expose

class MyView(BaseView):
    @expose('/')
    def index(self):
        return self.render('index.html')

app = Flask(__name__)

admin = Admin(app)
admin.add_view(MyView(name='Hello 1', endpoint='test1', category='Test'))
admin.add_view(MyView(name='Hello 2', endpoint='test2', category='Test'))
admin.add_view(MyView(name='Hello 3', endpoint='test3', category='Test'))
app.run()

will look like

Authentication

Flask-Admin does not make any assumptions about the authentication system you might be using. So, by default, the admin interface is completely open.

To control access to the admin interface, you can specify an is_accessible method when extending the BaseView class. So, for example, if you are using Flask-Login for authentication, the following will ensure that only logged-in users have access to the view in question:

class MyView(BaseView):
    def is_accessible(self):
        return login.current_user.is_authenticated()

You can also implement policy-based security, conditionally allowing or disallowing access to parts of the administrative interface. If a user does not have access to a particular view, the menu item won’t be visible.

Generating URLs

Internally, view classes work on top of Flask blueprints, so you can use url_for with a dot prefix to get the URL for a local view:

from flask import url_for

class MyView(BaseView):
    @expose('/')
    def index(self)
        # Get URL for the test view method
        url = url_for('.test')
        return self.render('index.html', url=url)

    @expose('/test/')
    def test(self):
        return self.render('test.html')

If you want to generate a URL for a particular view method from outside, the following rules apply:

1. You can override the endpoint name by passing endpoint parameter to the view class constructor:

   admin = Admin(app)
   admin.add_view(MyView(endpoint='testadmin'))
   
   In this case, you can generate links by concatenating the view method name with an endpoint::
   
   url_for('testadmin.index')
   

2. If you don’t override the endpoint name, the lower-case class name can be used for generating URLs, like in:

   url_for('myview.index')
   

3. For model-based views the rules differ - the model class name should be used if an endpoint name is not provided. Model-based views will be explained in the next section.

Model Views

Model views allow you to add dedicated admin pages for each of the models in your database. Do this by creating instances of the ModelView class, which you can import from one of Flask-Admin’s built-in ORM backends. An example is the SQLAlchemy backend, which you can use as follows:

from flask.ext.admin.contrib.sqla import ModelView

# Flask and Flask-SQLAlchemy initialization here

admin = Admin(app)
admin.add_view(ModelView(User, db.session))

This creates an admin page for the User model. By default, the list view looks like

To customize these model views, you have two options: Either you can override the public properties of the ModelView class, or you can override its methods.

For example, if you want to disable model creation and only show certain columns in the list view, you can do something like:

from flask.ext.admin.contrib.sqla import ModelView

# Flask and Flask-SQLAlchemy initialization here

class MyView(ModelView):
    # Disable model creation
    can_create = False

    # Override displayed fields
    column_list = ('login', 'email')

    def __init__(self, session, **kwargs):
        # You can pass name and other parameters if you want to
        super(MyView, self).__init__(User, session, **kwargs)

admin = Admin(app)
admin.add_view(MyView(db.session))

Overriding form elements can be a bit trickier, but it is still possible. Here’s an example of how to set up a form that includes a column named status that allows only predefined values and therefore should use a SelectField:

from wtforms.fields import SelectField

class MyView(ModelView):
    form_overrides = dict(status=SelectField)
    form_args = dict(
        # Pass the choices to the `SelectField`
        status=dict(
            choices=[(0, 'waiting'), (1, 'in_progress'), (2, 'finished')]
        ))

It is relatively easy to add support for different database backends (Mongo, etc) by inheriting from BaseModelView. class and implementing database-related methods.

Please refer to flask.ext.admin.contrib.sqla documentation on how to customize the behavior of model-based administrative views.

File Admin

Flask-Admin comes with another handy battery - file admin. It gives you ability to manage files on your server (upload, delete, rename, etc).

Here is simple example:

from flask.ext.admin.contrib.fileadmin import FileAdmin

import os.path as op

# Flask setup here

admin = Admin(app)

path = op.join(op.dirname(__file__), 'static')
admin.add_view(FileAdmin(path, '/static/', name='Static Files'))

Sample screenshot:

You can disable uploads, disable file or directory deletion, restrict file uploads to certain types and so on. Check flask.ext.admin.contrib.fileadmin documentation on how to do it.

Examples

Flask-Admin comes with few examples:

• Simple administrative interface with custom administrative views
• SQLAlchemy model example
• Flask-Login integration example
• File management interface
• Peewee model example
• MongoEngine model example

Migrating from Django

If you are used to Django and the django-admin package, you will find Flask-Admin to work slightly different from what you would expect.

This guide will help you to get acquainted with the Flask-Admin library. It is assumed that you have some prior knowledge of Flask .

Design Philosophy

In general, Django and django-admin strives to make life easier by implementing sensible defaults. So a developer will be able to get an application up in no time, but it will have to conform to most of the defaults. Of course it is possible to customize things, but this often requires a good understanding of what’s going on behind the scenes, and it can be rather tricky and time-consuming.

The design philosophy behind Flask is slightly different. It embraces the diversity that one tends to find in web applications by not forcing design decisions onto the developer. Rather than making it very easy to build an application that almost solves your whole problem, and then letting you figure out the last bit, Flask aims to make it possible for you to build the whole application. It might take a little more effort to get started, but once you’ve got the hang of it, the sky is the limit... Even when your application is a little different from most other applications out there on the web.

Flask-Admin follows this same design philosophy. So even though it provides you with several tools for getting up & running quickly, it will be up to you, as a developer, to tell Flask-Admin what should be displayed and how. Even though it is easy to get started with a simple CRUD interface for each model in your application, Flask-Admin doesn’t fix you to this approach, and you are free to define other ways of interacting with some, or all, of your models.

Due to Flask-Admin supporting more than one ORM (SQLAlchemy, MongoEngine, Peewee, raw pymongo), the developer is even free to mix different model types into one application by instantiating appropriate CRUD classes.

Getting started

At the basis of Flask-Admin is the idea that you can add components to your admin interface by declaring a separate class for each component, and then adding a method to that class for every view that should be associated to the component. Since classes can inherit from one another, and since several instances of the same class can be created, this approach allows for a great deal of flexibility.

Let’s write a bit of code to create a simple CRUD interface for the Post SQLAlchemy model. The example below uses the Flask-SQLAlchemy extension, but you don’t have to use it (you could also use the SQLAlchemy declarative extension):

from flask import Flask
from flask.ext.admin import Admin
from flask.ext.admin.contrib.sqla import ModelView
from flask.ext.sqlalchemy import SQLAlchemy

app = Flask(__name__)
db = SQLAlchemy(app)

class Post(db.Model):
    id = db.Column(db.Integer, primary_key=True)
    title = db.Column(db.Unicode(120))
    text = db.Column(db.UnicodeText, nullable=False)

admin = Admin(app)
admin.add_view(ModelView(Post, db.session))

To customize the behavior of the model’s CRUD interface, you can set values for some of the special properties (as listed below) that are made available through model.BaseModelView, or one of the ORM wrappers:

# ... imports

class PostView(ModelView):
    list_columns = ('title',)

    def __init__(self):
        super(PostView, self).__init__(Post, db.session)

# ... initialization

admin.add_view(PostView())

Because each component is implemented as a class, you can also customize it in the constructor:

class PostView(ModelView):
    list_columns = ('title',)

    def __init__(self, include_id=False):
        if include_id:
            self.list_columns = ('id', 'title')

        super(PostView, self).__init__(Post, db.session)

Here is a list of some of the configuration properties that are made available by Flask-Admin and the SQLAlchemy backend. You can also see which django-admin properties they correspond to:

Django	Flask-Admin
actions	flask.ext.admin.actions
exclude	form_excluded_columns
fields	form_columns
form	form
formfield_overrides	form_args
inlines	inline_models
list_display	column_list
list_filter	column_filters
list_per_page	page_size
search_fields	column_searchable_list
add_form_template	create_template
change_form_template	change_form_template

You might want to check flask.ext.admin.model for basic model configuration options (reused by all model backends) and specific backend documentation, for example flask.ext.admin.contrib.sqla. There’s much more than what is displayed in this table.

Authentication

To restrict access to your admin interface, you can implement your own class for creating admin components, and override the is_accessible method:

class MyModelView(ModelView):
    def is_accessible(self):
        return login.current_user.is_authenticated()

Components that are not accessible to a particular user, will also not be displayed in the menu for that user.

Templates

Flask-Admin uses Jinja2 templating engine. Jinja2 is pretty advanced templating engine and Flask-Admin templates were made to be easily extensible.

For example, if you need to include a javascript snippet on the Edit page for one of your models, you could:

{% extends 'admin/model/edit.html' %}

{% block tail %}
    {{ super() }}
    <script language="javascript">alert('Hello World!')</script>
{% endblock %}

and then point your class to this new template:

class MyModelView(ModelView):
    edit_template = 'my_edit_template.html'

For list of available template blocks, check Working with templates.

Tips and hints

1. Programming with Flask-Admin is not very different from normal application development - write some views and expose them to the user, using templates to create a consistent user experience.
2. If you are missing some functionality which can be used more than once, you can create your own “base” class and use it instead of default implementation.
3. Using Jinja2, you can easily extend the existing templates. You can even change the look and feel of the admin interface completely, if you want to. Check this example.
4. You are not limited to a simple CRUD interface for every model. Want to add some kind of realtime monitoring via websockets? No problem.
5. There’s a so called “index view”. By default it is empty, but you can put any information you need there. It is displayed under the Home menu option.

Working with templates

One great advantage of building an extension on top of Flask, is the great templating engine that comes with the package. Jinja2 allows you to use most of the Python syntax that you are used to, inside of your templates, helping you generate either text or code in a powerful, yet flexible way.

To explore some more of what Jinja2 can offer you, head over to their documentation at http://jinja.pocoo.org/docs/. But the most important features for you to understand in order to get started with Flask-Admin are given below.

Inheritance

Templates can extend other templates. This enables you, for example, to build the standard components of your site into a base template, where they are defined only once. This template can then be extended by other templates, where more specific content may be added.

Large applications may end up having several layers of templates, starting for example with a very general HTML structure, and then growing more and more specific at each level, until the final layer of templates define unique pages in the application. But it needs not be very complicated, and the majority of applications will only really need a handful of well-designed templates.

Building blocks

With Jinja2, templates are made up of blocks of code, which define where a child template’s contents fit into the bigger picture, as defined by the parent template.

A parent template may define any number of these code blocks, and a child template may define content for any number of those. So, by extending an existing template, you get to just fill-in the blanks, rather than having to deal with lots of boilerplate code that is not really relevant to the problem at hand.

Power & Flexibility

When a block is defined in a parent template, it can already be given some content, ensuring that something will be rendered in that place, even if a child template chooses to ignore that block completely.

If content is defined in a child template, you have the option of also rendering the code that the parent template may have defined in that block by calling:

{{ super() }}

anywhere inside that block. But the default behaviour is to simply override the block entirely.

Since these template blocks are defined by name, you have a lot of freedom in how you decide to arrange / nest them in your code.

Jinja2 & Flask Admin

Flask-Admin defines one base template at admin/master.html that all the other admin templates are derived from. This template is a proxy which points to admin/base.html, which defines the following blocks:

Block Name	Description
head_meta	Page metadata in the header
title	Page title
head_css	Various CSS includes in the header
head	Empty block in HTML head, in case you want to put something there
page_body	Page layout
brand	Logo in the menu bar
main_menu	Main menu
menu_links	Links menu
access_control	Section to the right of the menu (can be used to add login/logout buttons)
messages	Alerts and various messages
body	Content (that’s where your view will be displayed)
tail	Empty area below content

Adding an Index Page

You’ll notice that the ‘Home’ page that is created by Flask-Admin at /admin is largely empty. By default, the only content on the page is a set of controls for navigating to the views that you have defined. You can change this by creating a template at admin/index.html in your templates directory.

Working with your Models

By default, Flask-Admin uses three pre-defined templates for displaying your models in the admin-interface:

• admin/model/list.html
• admin/model/create.html
• admin/model/edit.html

All three of these extend the admin/master.html template, and you can override them by defining your own templates, with the same path relative to your templates folder.

You could also choose to extend these templates, rather than overriding them. In this case you will need to point your classes at your own templates, rather than letting them use the defaults. For example, your own template for the edit views could be defined in templates/my_edit_template.html to look something like:

{% extends 'admin/model/edit.html' %}

{% block tail %}
    {{ super() }}
    ...
{% endblock %}

And your classes could be made to use this template by setting the appropriate class property:

class MyModelView(ModelView):
    edit_template = 'my_edit_template.html'

The three available properties are simply called list_template, create_template and edit_template.

Environment variables

While working in any of the templates that extend admin/master.html, you have access to a small number of environment variables:

Variable Name	Description
admin_view	Current administrative view
admin_base_template	Base template name
_gettext	Babel gettext
_ngettext	Babel ngettext
h	Helpers from helpers module

Customizing templates

As noted earlier, you can override any default Flask-Admin template by creating your own template with same name and relative path inside your own templates directory.

You can also override the master template, but then you need to pass your own template name to the Admin constructor:

admin = Admin(app, base_template='my_master.html')

In addition to all of the blocks that are inherited from admin/master.html, the admin/model/list.html template also contains the following blocks:

Block Name	Description
model_menu_bar	Menu bar
model_list_table	Table container
list_header	Table header row
list_row_actions_header	Actions header
list_row	Single row
list_row_actions	Row action cell with edit/remove/etc buttons
empty_list_message	Message that will be displayed if there are no models found

Localization

Flask-Admin makes it possible for you to serve your application in more than one language. To do this, it makes use of the Flask-BabelEx package for handling translations. This package is a fork of the popular Flask-Babel package, with the following features:

1. It is API-compatible with Flask-Babel
2. It allows distribution of translations with Flask extensions
3. It aims to be more configurable than Flask-Babel

Currently Flask-BabelEx is the only supported way of enabling localization support in Flask-Admin.

How to enable localization

1. Install Flask-BabelEx:

   pip install flask-babelex
   

2. Initialize Flask-BabelEx by creating instance of Babel class:

   from flask import app
   from flask.ext.babelex import Babel
   
   app = Flask(__name__)
   babel = Babel(app)
   

3. Create a locale selector function:

   @babel.localeselector
   def get_locale():
           # Put your logic here. Application can store locale in
           # user profile, cookie, session, etc.
           return 'en'
   

4. Initialize Flask-Admin as usual.

You can check the babel example to see localization in action. When running this example, you can change the locale simply by adding a query parameter, like ?en=<locale name> to the URL. For example, a French version of the application should be accessible at: http://localhost:5000/admin/userview/?lang=fr.

Usage Tips

General tips

1. A reasonably obvious, but very useful, pattern is to wrap any shared functionality that your different admin views might need into a base class that they can all inherit from (to help you keep things DRY).

   For example, rather than manually checking user permissions in each of your admin views, you can implement a base class such as

   class MyView(BaseView):
       def is_accessible(self):
           return login.current_user.is_authenticated()
   

   and every view that inherits from this, will have the permission checking done automatically. The important thing to notice, is that your base class needs to inherit from a built-in Flask-Admin view.

2. You can override a default template either by passing the path to your own template in to the relevant ModelView property (either list_template, create_template or edit_template) or by putting your own customized version of a default template into your templates/admin/ directory.

3. To customize the overall look and feel of the default model forms, you have two options: Either, you could override the default create/edit templates. Or, alternatively, you could make use of the form rendering rules (flask.ext.admin.form.rules) that were introduced in version 1.0.7.

4. To simplify the management of file uploads, Flask-Admin comes with a dedicated tool, for which you can find documentation at: flask.ext.admin.form.upload.

5. If you don’t want to the use the built-in Flask-Admin form scaffolding logic, you are free to roll your own by simply overriding scaffold_form(). For example, if you use WTForms-Alchemy, you could put your form generation code into a scaffold_form method in your ModelView class.

SQLAlchemy

1. If the synonym_property does not return a SQLAlchemy field, then Flask-Admin won’t be able to figure out what to do with it, so it won’t generate a form field. In this case, you would need to manually contribute your own field:

   class MyView(ModelView):
       def scaffold_form(self):
           form_class = super(UserView, self).scaffold_form()
           form_class.extra = TextField('Extra')
           return form_class
   

MongoEngine

1. Flask-Admin supports GridFS-backed image- and file uploads, done through WTForms fields. Documentation can be found at flask.ext.admin.contrib.mongoengine.fields.

Database backends

The purpose of Flask-Admin is to help you manage your data. For this, it needs some database backend in order to be able to access that data in the first place. At present, there are four different backends for you to choose from, depending on which database you would like to use for your application.

SQLAlchemy backend

Flask-Admin comes with SQLAlchemy ORM backend.

Notable features:

• SQLAlchemy 0.6+ support
• Paging, sorting, filters
• Proper model relationship handling
• Inline editing of related models

Getting Started

In order to use SQLAlchemy model scaffolding, you need to have:

1. SQLAlchemy ORM model
2. Initialized database session

If you use Flask-SQLAlchemy, this is how you initialize Flask-Admin and get session from the SQLAlchemy object:

from flask import Flask
from flask.ext.sqlalchemy import SQLAlchemy
from flask.ext.admin import Admin
from flask.ext.admin.contrib.sqla import ModelView

app = Flask(__name__)
# .. read settings
db = SQLAlchemy(app)

# .. model declarations here

if __name__ == '__main__':
    admin = Admin(app)
    # .. add ModelViews
    # admin.add_view(ModelView(SomeModel, db.session))

Creating simple model

Using previous template, lets create simple model:

# .. flask initialization
db = SQLAlchemy(app)

class User(db.Model):
    id = db.Column(db.Integer, primary_key=True)
    name = db.Column(db.String(64), unique=True)
    email = db.Column(db.String(128))

if __name__ == '__main__':
    admin = Admin(app)
    admin.add_view(ModelView(User, db.session))

    db.create_all()
    app.run('0.0.0.0', 8000)

If you will run this example and open http://localhost:8000/, you will see that Flask-Admin generated administrative page for the model:

You can add new models, edit existing, etc.

Customizing administrative interface

List view can be customized in different ways.

First of all, you can use various class-level properties to configure what should be displayed and how. For example, column_list can be used to show some of the column or include extra columns from related models.

For example:

class UserView(ModelView):
    # Show only name and email columns in list view
    column_list = ('name', 'email')

    # Enable search functionality - it will search for terms in
    # name and email fields
    column_searchable_list = ('name', 'email')

    # Add filters for name and email columns
    column_filters = ('name', 'email')

Alternatively, you can override some of the ModelView methods and implement your custom logic.

For example, if you need to contribute additional field to the generated form, you can do something like this:

class UserView(ModelView):
    def scaffold_form(self):
        form_class = super(UserView, self).scaffold_form()
        form_class.extra = TextField('Extra')
        return form_class

Check flask.ext.admin.contrib.sqla documentation for list of configuration properties and methods.

Multiple Primary Keys

Flask-Admin has limited support for models with multiple primary keys. It only covers specific case when all but one primary keys are foreign keys to another model. For example, model inheritance following this convention.

Lets Model a car with its tyres:

class Car(db.Model):
    __tablename__ = 'cars'
    id = db.Column(db.Integer, primary_key=True, autoincrement=True)
    desc = db.Column(db.String(50))

    def __unicode__(self):
        return self.desc

class Tyre(db.Model):
    __tablename__ = 'tyres'
    car_id = db.Column(db.Integer, db.ForeignKey('cars.id'), primary_key=True)
    tyre_id = db.Column(db.Integer, primary_key=True)
    car = db.relationship('Car', backref='tyres')
    desc = db.Column(db.String(50))

A specific tyre is identified by using the two primary key columns of the Tyre class, of which the car_id key is itself a foreign key to the class Car.

To be able to CRUD the Tyre class, you need to enumerate columns when defining the AdminView:

class TyreAdmin(sqla.ModelView):
    form_columns = ['car', 'tyre_id', 'desc']

The form_columns needs to be explicit, as per default only one primary key is displayed.

When having multiple primary keys, no validation for uniqueness prior to saving of the object will be done. Saving a model that violates a unique-constraint leads to an Sqlalchemy-Integrity-Error. In this case, Flask-Admin displays a proper error message and you can change the data in the form. When the application has been started with debug=True the werkzeug debugger will catch the exception and will display the stacktrace.

A standalone script with the Examples from above can be found in the examples directory.

Example

Flask-Admin comes with relatively advanced example, which you can see here.

MongoEngine backend

Features:

• MongoEngine 0.7+ support
• Paging, sorting, filters, etc
• Supports complex document structure (lists, subdocuments and so on)
• GridFS support for file and image uploads

In order to use MongoEngine integration, you need to install the flask-mongoengine package, as Flask-Admin uses form scaffolding from it.

You don’t have to use Flask-MongoEngine in your project - Flask-Admin will work with “raw” MongoEngine models without any problems.

Known issues:

• Search functionality can’t split query into multiple terms due to MongoEngine query language limitations

For more documentation, check flask.ext.admin.contrib.mongoengine documentation.

MongoEngine integration example is here.

Peewee backend

Features:

• Peewee 2.x+ support;
• Paging, sorting, filters, etc;
• Inline editing of related models;

In order to use peewee integration, you need to install two additional Python packages: peewee and wtf-peewee.

Known issues:

• Many-to-Many model relations are not supported: there’s no built-in way to express M2M relation in Peewee

For more documentation, check flask.ext.admin.contrib.peewee documentation.

Peewee example is here.

PyMongo backend

Pretty simple PyMongo backend.

Flask-Admin does not make assumptions about document structure, so you will have to configure ModelView to do what you need it to do.

This is bare minimum you have to provide for Flask-Admin view to work with PyMongo:

1. Provide list of columns by setting column_list property
2. Provide form to use by setting form property
3. When instantiating flask.ext.admin.contrib.pymongo.ModelView class, you have to provide PyMongo collection object

This is minimal PyMongo view:

class UserForm(Form):
    name = TextField('Name')
    email = TextField('Email')

class UserView(ModelView):
    column_list = ('name', 'email')
    form = UserForm

if __name__ == '__main__':
    admin = Admin(app)

    # 'db' is PyMongo database object
    admin.add_view(UserView(db['users']))

On top of that you can add sortable columns, filters, text search, etc.

For more documentation, check flask.ext.admin.contrib.pymongo documentation.

PyMongo integration example is here.

If you don’t know where to start, but you’re familiar with relational databases, then you should probably look at using SQLAlchemy. It is a full-featured toolkit, with support for SQLite, PostgreSQL, MySQL, Oracle and MS-SQL amongst others. It really comes into its own once you have lots of data, and a fair amount of relations between your data models.

If you’re looking for something simpler, or your data models are reasonably self-contained, then MongoEngine could be a better option. It is a python wrapper around the popular NoSQL database called MongoDB.

Of course, if you feel that there’s an awesome database wrapper that is missing from the list above, we’d greatly appreciate it if you could write the plugin for it and submit it as a pull request. A special section of these docs are dedicated to helping you through this process. See Adding a new model backend.

Adding a new model backend

Flask-Admin makes a few assumptions about the database models that it works with. If you want to implement your own database backend, and still have Flask-Admin’s model views work as expected, then you should take note of the following:

1. Each model must have one field which acts as a primary key to uniquely identify instances of that model. However, there are no restriction on the data type or the field name of the primary key field.
2. Models must make their data accessible as python properties.

If that is the case, then you can implement your own database backend by extending the BaseModelView class, and implementing the set of scaffolding methods listed below.

Extending BaseModelView

Start off by defining a new class, which derives from from BaseModelView:

class MyDbModel(BaseModelView):
    pass

This class inherits BaseModelView’s __init__ method, which accepts a model class as first argument. The model class is stored as the attribute self.model so that other methods may access it.

Now, implement the following scaffolding methods for the new class:

1. get_pk_value()

   This method returns a primary key value from the model instance. In the SQLAlchemy backend, it gets the primary key from the model using scaffold_pk(), caches it and then returns the value from the model whenever requested.

   For example:

   class MyDbModel(BaseModelView):
       def get_pk_value(self, model):
           return self.model.id
   

2. scaffold_list_columns()

   Returns a list of columns to be displayed in a list view. For example:

   class MyDbModel(BaseModelView):
       def scaffold_list_columns(self):
           columns = []
   
           for p in dir(self.model):
               attr = getattr(self.model)
               if isinstance(attr, MyDbColumn):
                   columns.append(p)
   
           return columns
   

3. scaffold_sortable_columns()

   Returns a dictionary of sortable columns. The keys in the dictionary should correspond to the model’s field names. The values should be those variables that will be used for sorting.

   For example, in the SQLAlchemy backend it is possible to sort by a foreign key field. So, if there is a field named user, which is a foreign key for the Users table, and the Users table also has a name field, then the key will be user and value will be Users.name.

   If your backend does not support sorting, return None or an empty dictionary.

4. init_search()

   Initialize search functionality. If your backend supports full-text search, do initializations and return True. If your backend does not support full-text search, return False.

   For example, SQLAlchemy backend reads value of the self.searchable_columns and verifies if all fields are of text type, if they’re local to the current model (if not, it will add a join, etc) and caches this information for future use.

5. scaffold_form()

   Generate WTForms form class from the model.

   For example:

   class MyDbModel(BaseModelView):
       def scaffold_form(self):
           class MyForm(Form):
               pass
   
           # Do something
           return MyForm
   

6. get_list()

   This method should return list of model instances with paging, sorting, etc applied.

   For SQLAlchemy backend it looks like:

   1. If search was enabled and provided search value is not empty, generate LIKE statements for each field from self.searchable_columns

   2. If filter values were passed, call apply method with values:

      for flt, value in filters:
          query = self._filters[flt].apply(query, value)
      

   3. Execute query to get total number of rows in the database (count)

   4. If sort_column was passed, will do something like (with some extra FK logic which is omitted in this example):

      if sort_desc:
          query = query.order_by(desc(sort_field))
      else:
          query = query.order_by(sort_field)
      

   5. Apply paging

   6. Return count, list as a tuple

7. get_one()

   Return a model instance by its primary key.

8. create_model()

   Create a new instance of the model from the Form object.

9. update_model()

   Update the model instance with data from the form.

10. delete_model()

    Delete the specified model instance from the data store.

11. is_valid_filter()

    Verify whether the given object is a valid filter.

12. scaffold_filters()

    Return a list of filter objects for one model field.

    This method will be called once for each entry in the self.column_filters setting.

    If your backend does not know how to generate filters for the provided field, it should return None.

    For example:

    class MyDbModel(BaseModelView):
        def scaffold_filters(self, name):
            attr = getattr(self.model, name)
    
            if isinstance(attr, MyDbTextField):
                return [MyEqualFilter(name, name)]
    

Implementing filters

Each model backend should have its own set of filter implementations. It is not possible to use the filters from SQLAlchemy models in a non-SQLAlchemy backend. This also means that different backends might have different set of available filters.

The filter is a class derived from BaseFilter which implements at least two methods:

1. apply()
2. operation()

apply method accepts two parameters: query object and a value from the client. Here you can add filtering logic for the filter type.

Lets take SQLAlchemy model backend as an example:

All SQLAlchemy filters derive from BaseSQLAFilter class.

Each filter implements one simple filter SQL operation (like, not like, greater, etc) and accepts a column as input parameter.

Whenever model view wants to apply a filter to a query object, it will call apply method in a filter class with a query and value. Filter will then apply real filter operation.

For example:

class MyBaseFilter(BaseFilter):
    def __init__(self, column, name, options=None, data_type=None):
        super(MyBaseFilter, self).__init__(name, options, data_type)

        self.column = column

class MyEqualFilter(MyBaseFilter):
    def apply(self, query, value):
        return query.filter(self.column == value)

    def operation(self):
        return gettext('equals')

    # You can validate values. If value is not valid,
    # return `False`, so filter will be ignored.
    def validate(self, value):
        return True

    # You can "clean" values before they will be
    # passed to the your data access layer
    def clean(self, value):
        return value

Feel free ask questions if you have problems adding a new model backend. Also, if you get stuck, try taking a look at the SQLAlchemy model backend and use it as a reference.

Form rendering rules

Before version 1.0.7, all model backends were rendering the create and edit forms using a special Jinja2 macro, which was looping over the fields of a WTForms form object and displaying them one by one. This works well, but it is difficult to customize.

Starting from version 1.0.7, Flask-Admin supports form rendering rules, to give you fine grained control of how the forms for your modules should be displayed.

The basic idea is pretty simple: the customizable rendering rules replace a static macro, so that you can tell Flask-Admin how each form should be rendered. As an extension, however, the rendering rules also let you do a bit more: You can use them to output HTML, call Jinja2 macros, render fields and so on.

Essentially, form rendering rules abstract the rendering, so that it becomes separate from the form definition. So, for example, it no longer matters in which sequence yur form fields are defined.

Getting started

To start using the form rendering rules, put a list of form field names into the form_create_rules property one of your admin views:

class RuleView(sqla.ModelView):
    form_create_rules = ('email', 'first_name', 'last_name')

In this example, only three fields will be rendered and email field will be above other two fields.

Whenever Flask-Admin sees a string value in form_create_rules, it automatically assumes that it is a form field reference and creates a flask.ext.admin.form.rules.Field class instance for that field.

Lets say we want to display some text between the email and first_name fields. This can be accomplished by using the flask.ext.admin.form.rules.Text class:

from flask.ext.admin.form import rules

class RuleView(sqla.ModelView):
    form_create_rules = ('email', rules.Text('Foobar'), 'first_name', 'last_name')

Built-in rules

Flask-Admin comes with few built-in rules that can be found in the flask.ext.admin.form.rules module:

Form Rendering Rule	Description
flask.ext.admin.form.rules.BaseRule	All rules derive from this class
flask.ext.admin.form.rules.NestedRule	Allows rule nesting, useful for HTML containers
flask.ext.admin.form.rules.Text	Simple text rendering rule
flask.ext.admin.form.rules.HTML	Same as Text rule, but does not escape the text
flask.ext.admin.form.rules.Macro	Calls macro from current Jinja2 context
flask.ext.admin.form.rules.Container	Wraps child rules into container rendered by macro
flask.ext.admin.form.rules.Field	Renders single form field
flask.ext.admin.form.rules.Header	Renders form header
flask.ext.admin.form.rules.FieldSet	Renders form header and child rules

Further reading

For additional documentation, check flask.ext.admin.form.rules module source code (it is quite short) and look at the forms example on GitHub.

API

flask.ext.admin.base

Base View

expose(url='/', methods=('GET', ))

Use this decorator to expose views in your view classes.

Parameters:

• url – Relative URL for the view
• methods – Allowed HTTP methods. By default only GET is allowed.

expose_plugview(url='/')

Decorator to expose Flask’s pluggable view classes (flask.views.View or flask.views.MethodView).

Parameters:url – Relative URL for the view

New in version 1.0.4.

class BaseView(name=None, category=None, endpoint=None, url=None, static_folder=None, static_url_path=None)

Base administrative view.

Derive from this class to implement your administrative interface piece. For example:

class MyView(BaseView):
    @expose('/')
    def index(self):
        return 'Hello World!'

create_blueprint(admin)

Create Flask blueprint.

is_accessible()

Override this method to add permission checks.

Flask-Admin does not make any assumptions about the authentication system used in your application, so it is up to you to implement it.

By default, it will allow access for everyone.

is_visible()

Override this method if you want dynamically hide or show administrative views from Flask-Admin menu structure

By default, item is visible in menu.

Please note that item should be both visible and accessible to be displayed in menu.

render(template, **kwargs)

Render template

Parameters:

• template – Template path to render
• kwargs – Template arguments

Default view

class AdminIndexView(name=None, category=None, endpoint=None, url=None, template='admin/index.html')

Default administrative interface index page when visiting the /admin/ URL.

It can be overridden by passing your own view class to the Admin constructor:

class MyHomeView(AdminIndexView):
    @expose('/')
    def index(self):
        arg1 = 'Hello'
        return render_template('adminhome.html', arg1=arg1)

admin = Admin(index_view=MyHomeView())

Default values for the index page are:

• If a name is not provided, ‘Home’ will be used.
• If an endpoint is not provided, will default to admin
• Default URL route is /admin.
• Automatically associates with static folder.
• Default template is admin/index.html

Admin

class Admin(app=None, name=None, url=None, subdomain=None, index_view=None, translations_path=None, endpoint=None, static_url_path=None, base_template=None)

Collection of the admin views. Also manages menu structure.

add_link(link)

Add link to menu links collection.

Parameters:link – Link to add.

add_view(view)

Add a view to the collection.

Parameters:view – View to add.

init_app(app)

Register all views with the Flask application.

Parameters:app – Flask application instance

menu()

Return the menu hierarchy.

menu_links()

Return menu links.

flask.ext.admin.helpers

get_current_view()

Get current administrative view.

Forms

is_required_form_field(field)

Check if form field has DataRequired or InputRequired validators.

Parameters:field – WTForms field to check

is_form_submitted()

Check if current method is PUT or POST

validate_form_on_submit(form)

If current method is PUT or POST, validate form and return validation status.

get_form_data()

If current method is PUT or POST, return concatenated request.form with request.files or None otherwise.

is_field_error(errors)

Check if wtforms field has error without checking its children.

Parameters:errors – Errors list.

Jinja2 helpers

resolve_ctx(context)

Resolve current Jinja2 context and store it for general consumption.

get_render_ctx()

Get view template context.

flask.ext.admin.model

class BaseModelView(model, name=None, category=None, endpoint=None, url=None)

Base model view.

This view does not make any assumptions on how models are stored or managed, but expects the following:

1. The provided model is an object
2. The model contains properties
3. Each model contains an attribute which uniquely identifies it (i.e. a primary key for a database model)
4. It is possible to retrieve a list of sorted models with pagination applied from a data source
5. You can get one model by its identifier from the data source

Essentially, if you want to support a new data store, all you have to do is:

1. Derive from the BaseModelView class
2. Implement various data-related methods (get_list, get_one, create_model, etc)
3. Implement automatic form generation from the model representation (scaffold_form)

can_create = True

Is model creation allowed

can_edit = True

Is model editing allowed

can_delete = True

Is model deletion allowed

list_template = 'admin/model/list.html'

Default list view template

edit_template = 'admin/model/edit.html'

Default edit template

create_template = 'admin/model/create.html'

Default create template

column_list

Collection of the model field names for the list view. If set to None, will get them from the model.

For example:

class MyModelView(BaseModelView):
    column_list = ('name', 'last_name', 'email')

column_exclude_list

Collection of excluded list column names.

For example:

class MyModelView(BaseModelView):
    column_exclude_list = ('last_name', 'email')

column_labels

Dictionary where key is column name and value is string to display.

For example:

class MyModelView(BaseModelView):
    column_labels = dict(name='Name', last_name='Last Name')

column_descriptions = None

Dictionary where key is column name and value is description for list view column or add/edit form field.

For example:

class MyModelView(BaseModelView):
    column_descriptions = dict(
        full_name='First and Last name'
    )

column_formatters

Dictionary of list view column formatters.

For example, if you want to show price multiplied by two, you can do something like this:

class MyModelView(BaseModelView):
    column_formatters = dict(price=lambda v, c, m, p: m.price*2)

or using Jinja2 macro in template:

from flask.ext.admin.model.template import macro

class MyModelView(BaseModelView):
    column_formatters = dict(price=macro('render_price'))

# in template
{% macro render_price(model, column) %}
    {{ model.price * 2 }}
{% endmacro %}

The Callback function has the prototype:

def formatter(view, context, model, name):
    # `view` is current administrative view
    # `context` is instance of jinja2.runtime.Context
    # `model` is model instance
    # `name` is property name
    pass

column_type_formatters

Dictionary of value type formatters to be used in the list view.

By default, two types are formatted: 1. None will be displayed as an empty string 2. bool will be displayed as a checkmark if it is True

If you don’t like the default behavior and don’t want any type formatters applied, just override this property with an empty dictionary:

class MyModelView(BaseModelView):
    column_type_formatters = dict()

If you want to display NULL instead of an empty string, you can do something like this:

from flask.ext.admin.model import typefmt

MY_DEFAULT_FORMATTERS = dict(typefmt.BASE_FORMATTERS)
MY_DEFAULT_FORMATTERS.update({
        type(None): typefmt.null_formatter
    })

class MyModelView(BaseModelView):
    column_type_formatters = MY_DEFAULT_FORMATTERS

Type formatters have lower priority than list column formatters.

The callback function has following prototype:

def type_formatter(view, value):
    # `view` is current administrative view
    # `value` value to format
    pass

column_display_pk

Controls if the primary key should be displayed in the list view.

column_sortable_list

Collection of the sortable columns for the list view. If set to None, will get them from the model.

For example:

class MyModelView(BaseModelView):
    column_sortable_list = ('name', 'last_name')

If you want to explicitly specify field/column to be used while sorting, you can use a tuple:

class MyModelView(BaseModelView):
    column_sortable_list = ('name', ('user', 'user.username'))

When using SQLAlchemy models, model attributes can be used instead of strings:

class MyModelView(BaseModelView):
    column_sortable_list = ('name', ('user', User.username))

column_searchable_list

A collection of the searchable columns. It is assumed that only text-only fields are searchable, but it is up to the model implementation to decide.

Example:

class MyModelView(BaseModelView):
    column_searchable_list = ('name', 'email')

column_default_sort = None

Default sort column if no sorting is applied.

Example:

class MyModelView(BaseModelView):
    column_default_sort = 'user'

You can use tuple to control ascending descending order. In following example, items will be sorted in descending order:

class MyModelView(BaseModelView):
    column_default_sort = ('user', True)

column_choices = None

Map choices to columns in list view

Example:

class MyModelView(BaseModelView):
    column_choices = {
        'my_column': [
            ('db_value', 'display_value'),
        ]
    }

column_filters = None

Collection of the column filters.

Can contain either field names or instances of BaseFilter classes.

Example:

class MyModelView(BaseModelView):
    column_filters = ('user', 'email')

form = None

Form class. Override if you want to use custom form for your model. Will completely disable form scaffolding functionality.

For example:

class MyForm(Form):
    name = TextField('Name')

class MyModelView(BaseModelView):
    form = MyForm

form_base_class = <class 'flask_admin.form.BaseForm'>

Base form class. Will be used by form scaffolding function when creating model form.

Useful if you want to have custom contructor or override some fields.

Example:

class MyBaseForm(Form):
    def do_something(self):
        pass

class MyModelView(BaseModelView):
    form_base_class = MyBaseForm

form_columns = None

Collection of the model field names for the form. If set to None will get them from the model.

Example:

class MyModelView(BaseModelView):
    form_columns = ('name', 'email')

form_excluded_columns

Collection of excluded form field names.

For example:

class MyModelView(BaseModelView):
    form_excluded_columns = ('last_name', 'email')

form_args = None

Dictionary of form field arguments. Refer to WTForms documentation for list of possible options.

Example:

class MyModelView(BaseModelView):
    form_args = dict(
        name=dict(label='First Name', validators=[required()])
    )

form_overrides = None

Dictionary of form column overrides.

Example:

class MyModelView(BaseModelView):
    form_overrides = dict(name=wtf.FileField)

form_widget_args = None

Dictionary of form widget rendering arguments. Use this to customize how widget is rendered without using custom template.

Example:

class MyModelView(BaseModelView):
    form_widget_args = {
        'description': {
            'rows': 10,
            'style': 'color: black'
        }
    }

form_extra_fields = None

Dictionary of additional fields.

Example:

class MyModelView(BaseModelView):
    form_extra_fields = {
        password: PasswordField('Password')
    }

You can control order of form fields using form_columns property. For example:

class MyModelView(BaseModelView):
    form_columns = ('name', 'email', 'password', 'secret')

    form_extra_fields = {
        password: PasswordField('Password')
    }

In this case, password field will be put between email and secret fields that are autogenerated.

form_ajax_refs = None

Use AJAX for foreign key model loading.

Should contain dictionary, where key is field name and value is either a dictionary which configures AJAX lookups or backend-specific AjaxModelLoader class instance.

For example, it can look like:

class MyModelView(BaseModelView):
    form_ajax_refs = {
        'user': {
            'fields': ('first_name', 'last_name', 'email')
            'page_size': 10
        }
    }

Or with SQLAlchemy backend like this:

class MyModelView(BaseModelView):
    form_ajax_refs = {
        'user': QueryAjaxModelLoader('user', db.session, User, fields=['email'], page_size=10)
    }

If you need custom loading functionality, you can implement your custom loading behavior in your AjaxModelLoader class.

form_create_rules = None

Customized rules for the create form. Override form_rules if present.

form_edit_rules = None

Customized rules for the edit form. Override form_rules if present.

action_disallowed_list

Set of disallowed action names. For example, if you want to disable mass model deletion, do something like this:

class MyModelView(BaseModelView):

action_disallowed_list = [‘delete’]

page_size = 20

Default page size for pagination.

action_view(*args, **kwargs)

Mass-model action view.

after_model_change(form, model, is_created)

Perform some actions after a model was created or updated and committed to the database.

Called from create_model after successful database commit.

By default does nothing.

Parameters:

• form – Form used to create/update model
• model – Model that was created/updated
• is_created – True if model was created, False if model was updated

create_form(obj=None)

Instantiate model creation form and return it.

Override to implement custom behavior.

create_model(form)

Create model from the form.

Returns True if operation succeeded.

Must be implemented in the child class.

Parameters:form – Form instance

create_view(*args, **kwargs)

Create model view

delete_model(model)

Delete model.

Returns True if operation succeeded.

Must be implemented in the child class.

Parameters:model – Model instance

delete_view(*args, **kwargs)

Delete model view. Only POST method is allowed.

edit_form(obj=None)

Instantiate model editing form and return it.

Override to implement custom behavior.

edit_view(*args, **kwargs)

Edit model view

form_rules = None

List of rendering rules for model creation form.

This property changed default form rendering behavior and makes possible to rearrange order of rendered fields, add some text between fields, group them, etc. If not set, will use default Flask-Admin form rendering logic.

Here’s simple example which illustrates how to use:

from flask.ext.admin.form import rules

class MyModelView(ModelView):
    form_rules = [
        # Define field set with header text and four fields
        rules.FieldSet(('first_name', 'last_name', 'email', 'phone'), 'User'),
        # ... and it is just shortcut for:
        rules.Header('User'),
        rules.Field('first_name'),
        rules.Field('last_name'),
        # ...
        # It is possible to create custom rule blocks:
        MyBlock('Hello World'),
        # It is possible to call macros from current context
        rules.Macro('my_macro', foobar='baz')
    ]

get_column_name(field)

Return a human-readable column name.

Parameters:field – Model field name.

get_create_form()

Create form class for model creation view.

Override to implement customized behavior.

get_edit_form()

Create form class for model editing view.

Override to implement customized behavior.

get_filter_arg(index, flt)

Given a filter flt, return a unique name for that filter in this view.

Does not include the flt[n]_ portion of the filter name.

Parameters:

• index – Filter index in _filters array
• flt – Filter instance

get_filters()

Return a list of filter objects.

If your model backend implementation does not support filters, override this method and return None.

get_form()

Get form class.

If self.form is set, will return it and will call self.scaffold_form otherwise.

Override to implement customized behavior.

get_list(page, sort_field, sort_desc, search, filters)

Return a paginated and sorted list of models from the data source.

Must be implemented in the child class.

Parameters:

• page – Page number, 0 based. Can be set to None if it is first page.
• sort_field – Sort column name or None.
• sort_desc – If set to True, sorting is in descending order.
• search – Search query
• filters – List of filter tuples. First value in a tuple is a search index, second value is a search value.

get_list_columns()

Returns a list of the model field names. If column_list was set, returns it. Otherwise calls scaffold_list_columns to generate the list from the model.

get_list_value(context, model, name)

Returns the value to be displayed in the list view

Parameters:

• context – jinja2.runtime.Context
• model – Model instance
• name – Field name

get_one(id)

Return one model by its id.

Must be implemented in the child class.

Parameters:id – Model id

get_pk_value(model)

Return PK value from a model object.

get_sortable_columns()

Returns a dictionary of the sortable columns. Key is a model field name and value is sort column (for example - attribute).

If column_sortable_list is set, will use it. Otherwise, will call scaffold_sortable_columns to get them from the model.

index_view(*args, **kwargs)

List view

init_search()

Initialize search. If data provider does not support search, init_search will return False.

is_action_allowed(name)

Override this method to allow or disallow actions based on some condition.

The default implementation only checks if the particular action is not in action_disallowed_list.

is_sortable(name)

Verify if column is sortable.

Parameters:name – Column name.

is_valid_filter(filter)

Verify that the provided filter object is valid.

Override in model backend implementation to verify if the provided filter type is allowed.

Parameters:filter – Filter object to verify.

named_filter_urls = False

Set to True to use human-readable names for filters in URL parameters.

False by default so as to be robust across translations.

Changing this parameter will break any existing URLs that have filters.

on_model_change(form, model, is_created)

Perform some actions after a model is created or updated.

Called from create_model and update_model in the same transaction (if it has any meaning for a store backend).

By default does nothing.

Parameters:

• form – Form used to create/update model
• model – Model that will be created/updated
• is_created – Will be set to True if model was created and to False if edited

on_model_delete(model)

Perform some actions before a model is deleted.

Called from delete_model in the same transaction (if it has any meaning for a store backend).

By default do nothing.

scaffold_filters(name)

Generate filter object for the given name

Parameters:name – Name of the field

scaffold_form()

Create form.BaseForm inherited class from the model. Must be implemented in the child class.

scaffold_list_columns()

Return list of the model field names. Must be implemented in the child class.

Expected return format is list of tuples with field name and display text. For example:

['name', 'first_name', 'last_name']

scaffold_sortable_columns()

Returns dictionary of sortable columns. Must be implemented in the child class.

Expected return format is a dictionary, where keys are field names and values are property names.

update_model(form, model)

Update model from the form.

Returns True if operation succeeded.

Must be implemented in the child class.

Parameters:

• form – Form instance
• model – Model instance

flask.ext.admin.form

class BaseForm(formdata=None, obj=None, prefix=u'', **kwargs)

flask.ext.admin.form.rules

class BaseRule

Base form rule. All form formatting rules should derive from BaseRule.

class NestedRule(rules=, []separator='')

Nested rule. Can contain child rules and render them.

__init__(rules=, []separator='')

Constructor.

Parameters:

• rules – Child rule list
• separator – Default separator between rules when rendering them.

class Text(text, escape=True)

Render text (or HTML snippet) from string.

__init__(text, escape=True)

Constructor.

Parameters:

• text – Text to render
• escape – Should text be escaped or not. Default is True.

class HTML(html)

Shortcut for Text rule with escape set to `False.

class Macro(macro_name, **kwargs)

Render macro by its name from current Jinja2 context.

__init__(macro_name, **kwargs)

Constructor.

Parameters:

• macro_name – Macro name
• kwargs – Default macro parameters

class Container(macro_name, child_rule, **kwargs)

Render container around child rule.

__init__(macro_name, child_rule, **kwargs)

Constructor.

Parameters:

• macro_name – Macro name that will be used as a container
• child_rule – Child rule to be rendered inside of container
• kwargs – Container macro arguments

class Field(field_name, render_field='lib.render_field')

Form field rule.

__init__(field_name, render_field='lib.render_field')

Constructor.

Parameters:

• field_name – Field name to render
• render_field – Macro that will be used to render the field.

class Header(text, header_macro='lib.render_header')

Render header text.

__init__(text, header_macro='lib.render_header')

Constructor.

Parameters:

• text – Text to render
• header_macro – Header rendering macro

class FieldSet(rules, header=None, separator='')

Field set with header.

__init__(rules, header=None, separator='')

Constructor.

Parameters:

• rules – Child rules
• header – Header text
• separator – Child rule separator

flask.ext.admin.form.fields

class TimeField(label=None, validators=None, formats=None, default_format=None, widget_format=None, **kwargs)

A text field which stores a datetime.time object. Accepts time string in multiple formats: 20:10, 20:10:00, 10:00 am, 9:30pm, etc.

class Select2Field(label=None, validators=None, coerce=<type 'unicode'>, choices=None, allow_blank=False, blank_text=None, **kwargs)

Select2 styled select widget.

You must include select2.js, form.js and select2 stylesheet for it to work.

class Select2TagsField(label=None, validators=None, save_as_list=False, coerce=<type 'unicode'>, **kwargs)

Select2 styled text field. You must include select2.js, form.js and select2 stylesheet for it to work.

flask.ext.admin.form.upload

class FileUploadField(label=None, validators=None, base_path=None, relative_path=None, namegen=None, allowed_extensions=None, permission=438, **kwargs)

Customizable file-upload field.

Saves file to configured path, handles updates and deletions. Inherits from TextField, resulting filename will be stored as string.

__init__(label=None, validators=None, base_path=None, relative_path=None, namegen=None, allowed_extensions=None, permission=438, **kwargs)

Constructor.

Parameters:

• label – Display label
• validators – Validators
• base_path – Absolute path to the directory which will store files
• relative_path – Relative path from the directory. Will be prepended to the file name for uploaded files. Flask-Admin uses urlparse.urljoin to generate resulting filename, so make sure you have trailing slash.
• namegen –

  Function that will generate filename from the model and uploaded file object. Please note, that model is “dirty” model object, before it was committed to database.

  For example:

  import os.path as op
  
  def prefix_name(obj, file_data):
      parts = op.splitext(file_data.filename)
      return secure_filename('file-%s%s' % parts)
  
  class MyForm(BaseForm):
      upload = FileUploadField('File', namegen=prefix_name)
  

• allowed_extensions – List of allowed extensions. If not provided, will allow any file.

class ImageUploadField(label=None, validators=None, base_path=None, relative_path=None, namegen=None, allowed_extensions=None, max_size=None, thumbgen=None, thumbnail_size=None, permission=438, url_relative_path=None, endpoint='static', **kwargs)

Image upload field.

Does image validation, thumbnail generation, updating and deleting images.

Requires PIL (or Pillow) to be installed.

__init__(label=None, validators=None, base_path=None, relative_path=None, namegen=None, allowed_extensions=None, max_size=None, thumbgen=None, thumbnail_size=None, permission=438, url_relative_path=None, endpoint='static', **kwargs)

Constructor.

Parameters:

• label – Display label
• validators – Validators
• base_path – Absolute path to the directory which will store files
• relative_path – Relative path from the directory. Will be prepended to the file name for uploaded files. Flask-Admin uses urlparse.urljoin to generate resulting filename, so make sure you have trailing slash.
• namegen –

  Function that will generate filename from the model and uploaded file object. Please note, that model is “dirty” model object, before it was committed to database.

  For example:

  import os.path as op
  
  def prefix_name(obj, file_data):
      parts = op.splitext(file_data.filename)
      return secure_filename('file-%s%s' % parts)
  
  class MyForm(BaseForm):
      upload = FileUploadField('File', namegen=prefix_name)
  

• allowed_extensions – List of allowed extensions. If not provided, will allow any file.
• max_size – Tuple of (width, height, force) or None. If provided, Flask-Admin will resize image to the desired size.
• thumbgen –

  Thumbnail filename generation function. All thumbnails will be saved as JPEG files, so there’s no need to keep original file extension.

  For example:

  import os.path as op
  
  def thumb_name(filename):
      name, _ = op.splitext(filename)
      return secure_filename('%s-thumb.jpg' % name)
  
  class MyForm(BaseForm):
      upload = ImageUploadField('File', thumbgen=prefix_name)
  

• thumbnail_size –

  Tuple or (width, height, force) values. If not provided, thumbnail won’t be created.

  Width and height is in pixels. If force is set to True, will try to fit image into dimensions and keep aspect ratio, otherwise will just resize to target size.

• url_relative_path –

  Relative path from the root of the static directory URL. Only gets used when generating preview image URLs.

  For example, your model might store just file names (relative_path set to None), but base_path is pointing to subdirectory.

• endpoint – Static endpoint for images. Used by widget to display previews. Defaults to ‘static’.

class FileUploadInput

Renders a file input chooser field.

You can customize empty_template and data_template members to customize look and feel.

__init__

x.__init__(...) initializes x; see help(type(x)) for signature

class ImageUploadInput

Renders a image input chooser field.

You can customize empty_template and data_template members to customize look and feel.

__init__

x.__init__(...) initializes x; see help(type(x)) for signature

flask.ext.admin.tools

import_module(name, required=True)

Import module by name

Parameters:

• name – Module name
• required – If set to True and module was not found - will throw exception. If set to False and module was not found - will return None. Default is True.

import_attribute(name)

Import attribute using string reference.

Parameters:name – String reference.

Raises ImportError or AttributeError if module or attribute do not exist.

Example:

import_attribute('a.b.c.foo')

module_not_found(additional_depth=0)

Checks if ImportError was raised because module does not exist or something inside it raised ImportError

Parameters:additional_depth – supply int of depth of your call if you’re not doing import on the same level of code - f.e., if you call function, which is doing import, you should pass 1 for single additional level of depth

rec_getattr(obj, attr, default=None)

Recursive getattr.

Parameters:

• attr – Dot delimited attribute name
• default – Default value

Example:

rec_getattr(obj, 'a.b.c')

flask.ext.admin.actions

action(name, text, confirmation=None)

Use this decorator to expose actions that span more than one entity (model, file, etc)

Parameters:

• name – Action name
• text – Action text.
• confirmation – Confirmation text. If not provided, action will be executed unconditionally.

class ActionsMixin

Actions mixin.

In some cases, you might work with more than one “entity” (model, file, etc) in your admin view and will want to perform actions on a group of entities simultaneously.

In this case, you can add this functionality by doing this: 1. Add this mixin to your administrative view class 2. Call init_actions in your class constructor 3. Expose actions view 4. Import actions.html library and add call library macros in your template

get_actions_list()

Return a list and a dictionary of allowed actions.

handle_action(return_view=None)

Handle action request.

Parameters:return_view – Name of the view to return to after the request. If not provided, will return user to the index view.

init_actions()

Initialize list of actions for the current administrative view.

is_action_allowed(name)

Verify if action with name is allowed.

Parameters:name – Action name

flask.ext.admin.contrib.sqla

SQLAlchemy model backend implementation.

class ModelView(model, session, name=None, category=None, endpoint=None, url=None)

SQLAlchemy model view

Usage sample:

admin = Admin()
admin.add_view(ModelView(User, db.session))

Class inherits configuration options from BaseModelView and they’re not displayed here.

column_auto_select_related

Enable automatic detection of displayed foreign keys in this view and perform automatic joined loading for related models to improve query performance.

Please note that detection is not recursive: if __unicode__ method of related model uses another model to generate string representation, it will still make separate database call.

column_select_related_list

List of parameters for SQLAlchemy subqueryload. Overrides column_auto_select_related property.

For example:

class PostAdmin(ModelView):
    column_select_related_list = ('user', 'city')

You can also use properties:

class PostAdmin(ModelView):
    column_select_related_list = (Post.user, Post.city)

Please refer to the subqueryload on list of possible values.

column_searchable_list

Collection of the searchable columns. Only text-based columns are searchable (String, Unicode, Text, UnicodeText).

Example:

class MyModelView(ModelView):
    column_searchable_list = ('name', 'email')

You can also pass columns:

class MyModelView(ModelView):
    column_searchable_list = (User.name, User.email)

The following search rules apply:

• If you enter ZZZ in the UI search field, it will generate ILIKE ‘%ZZZ%’ statement against searchable columns.
• If you enter multiple words, each word will be searched separately, but only rows that contain all words will be displayed. For example, searching for ‘abc def’ will find all rows that contain ‘abc’ and ‘def’ in one or more columns.
• If you prefix your search term with ^, it will find all rows that start with ^. So, if you entered ^ZZZ, ILIKE ‘ZZZ%’ will be used.
• If you prefix your search term with =, it will perform an exact match. For example, if you entered =ZZZ, the statement ILIKE ‘ZZZ’ will be used.

column_filters = None

Collection of the column filters.

Can contain either field names or instances of flask.ext.admin.contrib.sqla.filters.BaseFilter classes.

For example:

class MyModelView(BaseModelView):
    column_filters = ('user', 'email')

or:

class MyModelView(BaseModelView):
    column_filters = (BooleanEqualFilter(User.name, 'Name'))

filter_converter = <flask_admin.contrib.sqla.filters.FilterConverter object at 0x7f6a33f3f410>

Field to filter converter.

Override this attribute to use non-default converter.

model_form_converter = <class 'flask_admin.contrib.sqla.form.AdminModelConverter'>

Model form conversion class. Use this to implement custom field conversion logic.

For example:

class MyModelConverter(AdminModelConverter):
    pass


class MyAdminView(ModelView):
    model_form_converter = MyModelConverter

inline_model_form_converter = <class 'flask_admin.contrib.sqla.form.InlineModelConverter'>

Inline model conversion class. If you need some kind of post-processing for inline forms, you can customize behavior by doing something like this:

class MyInlineModelConverter(AdminModelConverter):
    def post_process(self, form_class, info):
        form_class.value = wtf.TextField('value')
        return form_class

class MyAdminView(ModelView):
    inline_model_form_converter = MyInlineModelConverter

fast_mass_delete = False

If set to False and user deletes more than one model using built in action, all models will be read from the database and then deleted one by one giving SQLAlchemy a chance to manually cleanup any dependencies (many-to-many relationships, etc).

If set to True, will run a DELETE statement which is somewhat faster, but may leave corrupted data if you forget to configure DELETE CASCADE for your model.

inline_models = None

Inline related-model editing for models with parent-child relations.

Accepts enumerable with one of the following possible values:

1. Child model class:

   class MyModelView(ModelView):
       inline_models = (Post,)
   

2. Child model class and additional options:

   class MyModelView(ModelView):
       inline_models = [(Post, dict(form_columns=['title']))]
   

3. Django-like InlineFormAdmin class instance:

   class MyInlineModelForm(InlineFormAdmin):
       form_columns = ('title', 'date')
   
   class MyModelView(ModelView):
       inline_models = (MyInlineModelForm(MyInlineModel),)
   

You can customize the generated field name by:

1. Using the form_name property as a key to the options dictionary:

   class MyModelView(ModelView):

   inline_models = ((Post, dict(form_label=’Hello’)))

2. Using forward relation name and column_labels property:

   class Model1(Base):

   pass

   class Model2(Base):

   # ... model1 = relation(Model1, backref=’models’)

   class MyModel1View(Base):

   inline_models = (Model2,) column_labels = {‘models’: ‘Hello’}

form_choices = None

Map choices to form fields

Example:

class MyModelView(BaseModelView):
    form_choices = {'my_form_field': [
        ('db_value', 'display_value'),
    ]

form_optional_types = (<class 'sqlalchemy.sql.sqltypes.Boolean'>,)

List of field types that should be optional if column is not nullable.

Example:

class MyModelView(BaseModelView):
    form_optional_types = (Boolean, Unicode)

action_view(*args, **kwargs)

Mass-model action view.

after_model_change(form, model, is_created)

Perform some actions after a model was created or updated and committed to the database.

Called from create_model after successful database commit.

By default does nothing.

Parameters:

• form – Form used to create/update model
• model – Model that was created/updated
• is_created – True if model was created, False if model was updated

column_display_all_relations

Controls if list view should display all relations, not only many-to-one.

create_blueprint(admin)

Create Flask blueprint.

create_form(obj=None)

Instantiate model creation form and return it.

Override to implement custom behavior.

create_model(form)

Create model from form.

Parameters:form – Form instance

create_view(*args, **kwargs)

Create model view

delete_model(model)

Delete model.

Parameters:model – Model to delete

delete_view(*args, **kwargs)

Delete model view. Only POST method is allowed.

edit_form(obj=None)

Instantiate model editing form and return it.

Override to implement custom behavior.

edit_view(*args, **kwargs)

Edit model view

get_actions_list()

Return a list and a dictionary of allowed actions.

get_column_name(field)

Return a human-readable column name.

Parameters:field – Model field name.

get_count_query()

Return a the count query for the model type

get_create_form()

Create form class for model creation view.

Override to implement customized behavior.

get_edit_form()

Create form class for model editing view.

Override to implement customized behavior.

get_filter_arg(index, flt)

Given a filter flt, return a unique name for that filter in this view.

Does not include the flt[n]_ portion of the filter name.

Parameters:

• index – Filter index in _filters array
• flt – Filter instance

get_filters()

Return a list of filter objects.

If your model backend implementation does not support filters, override this method and return None.

get_form()

Get form class.

If self.form is set, will return it and will call self.scaffold_form otherwise.

Override to implement customized behavior.

get_list(page, sort_column, sort_desc, search, filters, execute=True)

Return models from the database.

Parameters:

• page – Page number
• sort_column – Sort column name
• sort_desc – Descending or ascending sort
• search – Search query
• execute – Execute query immediately? Default is True
• filters – List of filter tuples

get_list_columns()

Returns a list of the model field names. If column_list was set, returns it. Otherwise calls scaffold_list_columns to generate the list from the model.

get_list_value(context, model, name)

Returns the value to be displayed in the list view

Parameters:

• context – jinja2.runtime.Context
• model – Model instance
• name – Field name

get_one(id)

Return a single model by its id.

Parameters:id – Model id

get_pk_value(model)

Return the PK value from a model object. PK can be a single value or a tuple if multiple PKs exist

get_query()

Return a query for the model type.

If you override this method, don’t forget to override get_count_query as well.

get_sortable_columns()

Returns a dictionary of the sortable columns. Key is a model field name and value is sort column (for example - attribute).

If column_sortable_list is set, will use it. Otherwise, will call scaffold_sortable_columns to get them from the model.

handle_action(return_view=None)

Handle action request.

Parameters:return_view – Name of the view to return to after the request. If not provided, will return user to the index view.

index_view(*args, **kwargs)

List view

init_actions()

Initialize list of actions for the current administrative view.

init_search()

Initialize search. Returns True if search is supported for this view.

For SQLAlchemy, this will initialize internal fields: list of column objects used for filtering, etc.

is_accessible()

Override this method to add permission checks.

Flask-Admin does not make any assumptions about the authentication system used in your application, so it is up to you to implement it.

By default, it will allow access for everyone.

is_sortable(name)

Verify if column is sortable.

Parameters:name – Column name.

is_text_column_type(name)

Verify if the provided column type is text-based.

Returns:True for String, Unicode, Text, UnicodeText

is_valid_filter(filter)

Verify that the provided filter object is derived from the SQLAlchemy-compatible filter class.

Parameters:filter – Filter object to verify.

is_visible()

Override this method if you want dynamically hide or show administrative views from Flask-Admin menu structure

By default, item is visible in menu.

Please note that item should be both visible and accessible to be displayed in menu.

on_model_change(form, model, is_created)

Perform some actions after a model is created or updated.

Called from create_model and update_model in the same transaction (if it has any meaning for a store backend).

By default does nothing.

Parameters:

• form – Form used to create/update model
• model – Model that will be created/updated
• is_created – Will be set to True if model was created and to False if edited

on_model_delete(model)

Perform some actions before a model is deleted.

Called from delete_model in the same transaction (if it has any meaning for a store backend).

By default do nothing.

render(template, **kwargs)

Render template

Parameters:

• template – Template path to render
• kwargs – Template arguments

scaffold_auto_joins()

Return a list of joined tables by going through the displayed columns.

scaffold_filters(name)

Return list of enabled filters

scaffold_form()

Create form from the model.

scaffold_inline_form_models(form_class)

Contribute inline models to the form

Parameters:form_class – Form class

scaffold_list_columns()

Return a list of columns from the model.

scaffold_pk()

Return the primary key name from a model PK can be a single value or a tuple if multiple PKs exist

scaffold_sortable_columns()

Return a dictionary of sortable columns. Key is column name, value is sort column/field.

update_model(form, model)

Update model from form.

Parameters:

• form – Form instance
• model – Model instance

flask.ext.admin.contrib.mongoengine

MongoEngine model backend implementation.

flask.ext.admin.contrib.mongoengine.fields

flask.ext.admin.contrib.peewee

Peewee model backend implementation.

class ModelView(model, name=None, category=None, endpoint=None, url=None)

Class inherits configuration options from BaseModelView and they’re not displayed here.

column_filters = None

Collection of the column filters.

Can contain either field names or instances of flask.ext.admin.contrib.peewee.filters.BaseFilter classes.

For example:

class MyModelView(BaseModelView):
    column_filters = ('user', 'email')

or:

class MyModelView(BaseModelView):
    column_filters = (BooleanEqualFilter(User.name, 'Name'))

filter_converter = <flask_admin.contrib.peewee.filters.FilterConverter object at 0x7f6a34835ed0>

Field to filter converter.

Override this attribute to use non-default converter.

model_form_converter = <class 'flask_admin.contrib.peewee.form.CustomModelConverter'>

Model form conversion class. Use this to implement custom field conversion logic.

For example:

class MyModelConverter(AdminModelConverter):
    pass


class MyAdminView(ModelView):
    model_form_converter = MyModelConverter

inline_model_form_converter = <class 'flask_admin.contrib.peewee.form.InlineModelConverter'>

Inline model conversion class. If you need some kind of post-processing for inline forms, you can customize behavior by doing something like this:

class MyInlineModelConverter(AdminModelConverter):
    def post_process(self, form_class, info):
        form_class.value = TextField('value')
        return form_class

class MyAdminView(ModelView):
    inline_model_form_converter = MyInlineModelConverter

fast_mass_delete = False

If set to False and user deletes more than one model using actions, all models will be read from the database and then deleted one by one giving Peewee chance to manually cleanup any dependencies (many-to-many relationships, etc).

If set to True, will run DELETE statement which is somewhat faster, but might leave corrupted data if you forget to configure DELETE CASCADE for your model.

inline_models = None

Inline related-model editing for models with parent to child relation.

Accept enumerable with one of the values:

1. Child model class:

   class MyModelView(ModelView):
       inline_models = (Post,)
   

2. Child model class and additional options:

   class MyModelView(ModelView):
       inline_models = [(Post, dict(form_columns=['title']))]
   

3. Django-like InlineFormAdmin class instance:

   class MyInlineModelForm(InlineFormAdmin):
       form_columns = ('title', 'date')
   
   class MyModelView(ModelView):
       inline_models = (MyInlineModelForm(MyInlineModel),)
   

You can customize generated field name by:

1. Using form_name property as option:

   class MyModelView(ModelView):

   inline_models = ((Post, dict(form_label=’Hello’)))

2. Using field’s related_name:

   class Model1(Base):

   # ... pass

   class Model2(Base):

   # ... model1 = ForeignKeyField(related_name=”model_twos”)

   class MyModel1View(Base):

   inline_models = (Model2,) column_labels = {‘model_ones’: ‘Hello’}

action_view(*args, **kwargs)

Mass-model action view.

after_model_change(form, model, is_created)

Perform some actions after a model was created or updated and committed to the database.

Called from create_model after successful database commit.

By default does nothing.

Parameters:

• form – Form used to create/update model
• model – Model that was created/updated
• is_created – True if model was created, False if model was updated

create_blueprint(admin)

Create Flask blueprint.

create_form(obj=None)

Instantiate model creation form and return it.

Override to implement custom behavior.

create_view(*args, **kwargs)

Create model view

delete_view(*args, **kwargs)

Delete model view. Only POST method is allowed.

edit_form(obj=None)

Instantiate model editing form and return it.

Override to implement custom behavior.

edit_view(*args, **kwargs)

Edit model view

get_actions_list()

Return a list and a dictionary of allowed actions.

get_column_name(field)

Return a human-readable column name.

Parameters:field – Model field name.

get_create_form()

Create form class for model creation view.

Override to implement customized behavior.

get_edit_form()

Create form class for model editing view.

Override to implement customized behavior.

get_filter_arg(index, flt)

Given a filter flt, return a unique name for that filter in this view.

Does not include the flt[n]_ portion of the filter name.

Parameters:

• index – Filter index in _filters array
• flt – Filter instance

get_filters()

Return a list of filter objects.

If your model backend implementation does not support filters, override this method and return None.

get_form()

Get form class.

If self.form is set, will return it and will call self.scaffold_form otherwise.

Override to implement customized behavior.

get_list_columns()

Returns a list of the model field names. If column_list was set, returns it. Otherwise calls scaffold_list_columns to generate the list from the model.

get_list_value(context, model, name)

Returns the value to be displayed in the list view

Parameters:

• context – jinja2.runtime.Context
• model – Model instance
• name – Field name

get_sortable_columns()

Returns a dictionary of the sortable columns. Key is a model field name and value is sort column (for example - attribute).

If column_sortable_list is set, will use it. Otherwise, will call scaffold_sortable_columns to get them from the model.

handle_action(return_view=None)

Handle action request.

Parameters:return_view – Name of the view to return to after the request. If not provided, will return user to the index view.

index_view(*args, **kwargs)

List view

init_actions()

Initialize list of actions for the current administrative view.

is_accessible()

Override this method to add permission checks.

Flask-Admin does not make any assumptions about the authentication system used in your application, so it is up to you to implement it.

By default, it will allow access for everyone.

is_sortable(name)

Verify if column is sortable.

Parameters:name – Column name.

is_visible()

Override this method if you want dynamically hide or show administrative views from Flask-Admin menu structure

By default, item is visible in menu.

Please note that item should be both visible and accessible to be displayed in menu.

on_model_change(form, model, is_created)

Perform some actions after a model is created or updated.

Called from create_model and update_model in the same transaction (if it has any meaning for a store backend).

By default does nothing.

Parameters:

• form – Form used to create/update model
• model – Model that will be created/updated
• is_created – Will be set to True if model was created and to False if edited

on_model_delete(model)

Perform some actions before a model is deleted.

Called from delete_model in the same transaction (if it has any meaning for a store backend).

By default do nothing.

render(template, **kwargs)

Render template

Parameters:

• template – Template path to render
• kwargs – Template arguments

flask.ext.admin.contrib.pymongo

PyMongo model backend implementation.

class ModelView(coll, name=None, category=None, endpoint=None, url=None)

MongoEngine model scaffolding.

Class inherits configuration options from BaseModelView and they’re not displayed here.

column_filters = None

Collection of the column filters.

Should contain instances of flask.ext.admin.contrib.pymongo.filters.BasePyMongoFilter classes.

For example:

class MyModelView(BaseModelView):
    column_filters = (BooleanEqualFilter(User.name, 'Name'),)

action_view(*args, **kwargs)

Mass-model action view.

after_model_change(form, model, is_created)

Perform some actions after a model was created or updated and committed to the database.

Called from create_model after successful database commit.

By default does nothing.

Parameters:

• form – Form used to create/update model
• model – Model that was created/updated
• is_created – True if model was created, False if model was updated

create_blueprint(admin)

Create Flask blueprint.

create_form(obj=None)

Instantiate model creation form and return it.

Override to implement custom behavior.

create_model(form)

Create model helper

Parameters:form – Form instance

create_view(*args, **kwargs)

Create model view

delete_model(model)

Delete model helper

Parameters:model – Model instance

delete_view(*args, **kwargs)

Delete model view. Only POST method is allowed.

edit_form(obj)

Create edit form from the MongoDB document

edit_view(*args, **kwargs)

Edit model view

get_actions_list()

Return a list and a dictionary of allowed actions.

get_column_name(field)

Return a human-readable column name.

Parameters:field – Model field name.

get_create_form()

Create form class for model creation view.

Override to implement customized behavior.

get_edit_form()

Create form class for model editing view.

Override to implement customized behavior.

get_filter_arg(index, flt)

Given a filter flt, return a unique name for that filter in this view.

Does not include the flt[n]_ portion of the filter name.

Parameters:

• index – Filter index in _filters array
• flt – Filter instance

get_filters()

Return a list of filter objects.

If your model backend implementation does not support filters, override this method and return None.

get_form()

Get form class.

If self.form is set, will return it and will call self.scaffold_form otherwise.

Override to implement customized behavior.

get_list(page, sort_column, sort_desc, search, filters, execute=True)

Get list of objects from MongoEngine

Parameters:

• page – Page number
• sort_column – Sort column
• sort_desc – Sort descending
• search – Search criteria
• filters – List of applied fiters
• execute – Run query immediately or not

get_list_columns()

Returns a list of the model field names. If column_list was set, returns it. Otherwise calls scaffold_list_columns to generate the list from the model.

get_list_value(context, model, name)

Returns the value to be displayed in the list view

Parameters:

• context – jinja2.runtime.Context
• model – Model instance
• name – Field name

get_one(id)

Return single model instance by ID

Parameters:id – Model ID

get_pk_value(model)

Return primary key value from the model instance

Parameters:model – Model instance

get_sortable_columns()

Returns a dictionary of the sortable columns. Key is a model field name and value is sort column (for example - attribute).

If column_sortable_list is set, will use it. Otherwise, will call scaffold_sortable_columns to get them from the model.

handle_action(return_view=None)

Handle action request.

Parameters:return_view – Name of the view to return to after the request. If not provided, will return user to the index view.

index_view(*args, **kwargs)

List view

init_actions()

Initialize list of actions for the current administrative view.

init_search()

Init search

is_accessible()

Override this method to add permission checks.

Flask-Admin does not make any assumptions about the authentication system used in your application, so it is up to you to implement it.

By default, it will allow access for everyone.

is_sortable(name)

Verify if column is sortable.

Parameters:name – Column name.

is_valid_filter(filter)

Validate if it is valid MongoEngine filter

Parameters:filter – Filter object

is_visible()

Override this method if you want dynamically hide or show administrative views from Flask-Admin menu structure

By default, item is visible in menu.

Please note that item should be both visible and accessible to be displayed in menu.

on_model_change(form, model, is_created)

Perform some actions after a model is created or updated.

Called from create_model and update_model in the same transaction (if it has any meaning for a store backend).

By default does nothing.

Parameters:

• form – Form used to create/update model
• model – Model that will be created/updated
• is_created – Will be set to True if model was created and to False if edited

on_model_delete(model)

Perform some actions before a model is deleted.

Called from delete_model in the same transaction (if it has any meaning for a store backend).

By default do nothing.

render(template, **kwargs)

Render template

Parameters:

• template – Template path to render
• kwargs – Template arguments

scaffold_filters(attr)

Return filter object(s) for the field

Parameters:name – Either field name or field instance

scaffold_list_columns()

Scaffold list columns

scaffold_sortable_columns()

Return sortable columns dictionary (name, field)

update_model(form, model)

Update model helper

Parameters:

• form – Form instance
• model – Model instance to update

flask.ext.admin.contrib.fileadmin

class FileAdmin(base_path, base_url=None, name=None, category=None, endpoint=None, url=None, verify_path=True)

Simple file-management interface.

Parameters:

• path – Path to the directory which will be managed
• base_url – Optional base URL for the directory. Will be used to generate static links to the files. If not defined, a route will be created to serve uploaded files.

Sample usage:

admin = Admin()

path = op.join(op.dirname(__file__), 'static')
admin.add_view(FileAdmin(path, '/static/', name='Static Files'))
admin.setup_app(app)

can_upload = True

Is file upload allowed.

can_delete = True

Is file deletion allowed.

can_delete_dirs = True

Is recursive directory deletion is allowed.

can_mkdir = True

Is directory creation allowed.

can_rename = True

Is file and directory renaming allowed.

allowed_extensions = None

List of allowed extensions for uploads, in lower case.

Example:

class MyAdmin(FileAdmin):
    allowed_extensions = ('swf', 'jpg', 'gif', 'png')

editable_extensions = ()

List of editable extensions, in lower case.

Example:

class MyAdmin(FileAdmin):
    editable_extensions = ('md', 'html', 'txt')

list_template = 'admin/file/list.html'

File list template

upload_template = 'admin/file/form.html'

File upload template

mkdir_template = 'admin/file/form.html'

Directory creation (mkdir) template

rename_template = 'admin/file/rename.html'

Rename template

edit_template = 'admin/file/edit.html'

Edit template

can_download = True

Is file download allowed.

delete(*args, **kwargs)

Delete view method

download(*args, **kwargs)

Download view method.

Parameters:path – File path.

edit(*args, **kwargs)

Edit view method

edit_template = 'admin/file/edit.html'

Edit template

get_base_path()

Return base path. Override to customize behavior (per-user directories, etc)

get_base_url()

Return base URL. Override to customize behavior (per-user directories, etc)

index(*args, **kwargs)

Index view method

Parameters:path – Optional directory path. If not provided, will use the base directory

is_accessible_path(path)

Verify if the provided path is accessible for the current user.

Override to customize behavior.

Parameters:path – Relative path to the root

is_file_allowed(filename)

Verify if file can be uploaded.

Override to customize behavior.

Parameters:filename – Source file name

is_file_editable(filename)

Determine if the file can be edited.

Override to customize behavior.

Parameters:filename – Source file name

is_in_folder(base_path, directory)

Verify that directory is in base_path folder

Parameters:

• base_path – Base directory path
• directory – Directory path to check

mkdir(*args, **kwargs)

Directory creation view method

Parameters:path – Optional directory path. If not provided, will use the base directory

on_directory_delete(full_path, dir_name)

Perform some actions after a directory has successfully been deleted.

Called from delete method

By default do nothing.

on_edit_file(full_path, path)

Perform some actions after a file has been successfully changed.

Called from edit method

By default do nothing.

on_file_delete(full_path, filename)

Perform some actions after a file has successfully been deleted.

Called from delete method

By default do nothing.

on_file_upload(directory, path, filename)

Perform some actions after a file has been successfully uploaded.

Called from upload method

By default do nothing.

on_mkdir(parent_dir, dir_name)

Perform some actions after a directory has successfully been created.

Called from mkdir method

By default do nothing.

on_rename(full_path, dir_base, filename)

Perform some actions after a file or directory has been renamed.

Called from rename method

By default do nothing.

rename(*args, **kwargs)

Rename view method

save_file(path, file_data)

Save uploaded file to the disk

Parameters:

• path – Path to save to
• file_data – Werkzeug FileStorage object

upload(*args, **kwargs)

Upload view method

Parameters:path – Optional directory path. If not provided, will use the base directory

upload_form

Upload form class

alias of UploadForm

flask.ext.admin.model.template

macro(name)

Jinja2 macro list column formatter.

Parameters:name – Macro name in the current template

Changelog

1.0.8

Highlights:

• Cleaned up documentation, many thanks to Petrus Janse van Rensburg.
• More flexible menu system, ability to add links to menus
• Human-readable filter URLs
• Callable filter options
• EmailField filter
• Simple accessibility fixes
• InlineFormField now accepts widget_args and form_rules arguments
• Support for newer wtforms versions
• form_rules property that affects both create and edit forms
• Lots of bugfixes

1.0.7

Full change log and feature walkthrough can be found here.

Highlights:

• Python 3 support
• AJAX-based foreign-key data loading for all backends
• New, optional, rule-based form rendering engine
• MongoEngine fixes and features: GridFS support, nested subdocument configuration and much more
• Greatly improved and more configurable inline models
• New WTForms fields and widgets
• form_extra_columns allows adding custom columns to the form declaratively
• Redis cli
• SQLAlchemy backend can handle inherited models with multiple PKs
• Lots of bug fixes

1.0.6

• Model views now support default sorting order
• Model type/column formatters now accept additional view parameter
• is_visible for administrative views
• Model views have after_model_change method that can be overridden
• In model views, get_query was split into get_count_query and get_query
• Bootstrap 2.3.1
• Bulk deletes go through delete_model
• Flask-Admin no longer uses floating navigation bar
• Translations: French, Persian (Farsi), Chinese (Simplified/Traditional), Czech
• Bug fixes

Renamed Columns

Starting from version 1.0.4, Flask-Admin uses different configuration property names.

Please update your sources as support for old property names will be removed in future Flask-Admin versions.

Old Name	New name
list_columns	column_list
excluded_list_columns	column_exclude_list
list_formatters	column_formatters
list_type_formatters	column_type_formatters
rename_columns	column_labels
sortable_columns	column_sortable_list
searchable_columns	column_searchable_list
list_display_pk	column_display_pk
auto_select_related	column_auto_select_related
list_select_related	column_select_related_list
list_display_all_relations	column_display_all_relations
excluded_form_columns	form_excluded_columns
disallowed_actions	action_disallowed_list

Indices and tables

• Index
• Module Index
• Search Page