It was reported that Piccolo Admin doesn't work with the Starlite framework.

It should be possible to mount Piccolo Admin:

https://starlite-api.github.io/starlite/usage/2-route-handlers/3-asgi-route-handlers/

Tasks required:

• [x] Try getting Piccolo admin working with Starlite
• [x] If it doesn't work, try and work out why

Currently, create_admin accepts a list of Table subclasses. This can be modified to accept either Table subclasses, or instances of a new class called TableConfig.

TableConfig will be a dataclass which accepts a table argument, as well as a bunch of configuration options. For example:

@dataclasses.dataclass
class TableConfig:
    """
    :param list_columns:
        Used to specify which columns are shown on the list page. If None,
        all are shown.
    :param list_filters:
        Used to specify which filters are shown on the list page. If None,
        all are shown.

    """
    table: Type[Table]
    list_columns: Optional[List[Union[str, Column]] = None
    list_filters: Optional[List[Union[str, Column]] = None
    # Plus some additional options, which haven't been finalised.
    ...

app = create_admin(
    tables=[
        SomeTable,
        TableConfig(
            table=MyTable,
            list_columns=[MyTable.name],
            list_filters=[MyTable.name]
        )
    ]
)

It will allow more fine grained control of the how the admin looks.

Now we have some basic Cypress tests, it is worth investigating how we can run these as part of GitHub actions.

Cypress tests can be notoriously slow, so we might not want to run them on every commit - we will have to see what the performance is like.

Based on #87. Work in progress

• [x] fixing login process
• [x] replacing deprecated features form Vue2 (Vue.set(), Vue.delete(), filters in template) with Vue3 features
• [x] upgraded major library dependencies for working with Vue 3
• [x] removing vue-json-excel and making our own implementation of CSV export
• [x] fixing RowListing and CRUD
• [x] fixing sorting and filtering
• [x] fixing reference table search results
• [x] added basic types
• [x] custom forms
• [x] fixing nullable fields
• [x] TableConfig

Related to #173.

Result is:

https://user-images.githubusercontent.com/30960668/177712285-56767f52-468d-434e-a6b4-39e95edf6329.mp4

To add a new translation, we just need to add a new json (eg. german.json) to assets/locales and update main.ts to register the new translation.

When using custom primary key columns, for example:

class MyTable(Table):
    pk = UUID(primary_key=True)

There are likely to be some edge cases not currently supported by Piccolo admin.

@dantownsend this is my try on exporting to csv. Probably it be slow for large and complex tables due to passing total number of rows to PiccoloCRUD __page_size param , but it's just idea.

Based on https://github.com/piccolo-orm/piccolo_admin/pull/182

@sinisaos I've done a bunch of work on this.

The main changes are:

• Added extra security based on this OWASP doc
• It now supports all kinds of files - e.g. video as well
• Added a media preview window, so the user can see the full sized image or video within Piccolo Admin
• Array, Varchar, and Text columns can all be used as media columns

You can see the changes here:

https://user-images.githubusercontent.com/350976/181996743-17dae1d0-8b13-42de-89c0-b16c5643997b.mp4

The biggest change from the original PR is it saves a unique identifier for the file in the database, rather than the URL. There are two reasons for this:

• If the user decides to host their media files somewhere else, they don't have to update anything in the database.
• It's the only way to get it working with S3. Each time someone accesses a file in S3 we need to generate a signed URL, which is only valid for a short period of time, so we can't store the URL in the database.

I think it's about 80% done. It's a massive feature, but a really cool one.

Things that need doing still:

• [x] Update the docs
• [ ] I need to add your file upload button back - it looks nicer than what's there now
• [x] Add links on the row detail page for viewing images
• [x] Maybe add S3 support, so we know the API works properly with it before releasing it
• [x] The media is always served from /api/media-files/ at the moment. It's ignoring the media_url setting in LocalStorage. That needs some thinking about.
• [x] We used to have media_columns and media_storage arguments in TableConfig. I changed it slightly (now there's just media_columns, which maps a column to a MediaStorage) because I can imagine use cases where you want some columns to store files in one place, and other columns to store files in another place. Also, you might only allow images in some columns, and videos in other columns. It still needs a bit of thinking about.
• [x] I might move a bunch of the logic to Piccolo API, so it can also be used with PiccoloCRUD standalone.

I removed your image previews from RowListing.vue for now. I liked the way they looked, but because we're not creating thumbnails for the images, if the page is showing 100 rows, it will pull down 100 full sizes images, which would slow things down too much. Once we work out thumbnails I would like to add it back.

@dantownsend are you perhaps interested in adding wysiwyg editor to textarea fields?

https://user-images.githubusercontent.com/30960668/158114813-3fa9b405-e87e-438e-84a1-5a2395cc145e.mov

This is a big task, but unlocks a lot of great functionality in the admin.

Piccolo doesn't have a particular column type for storing media (images, video etc). It's possible to store them in binary columns, but this is generally frowned upon as it quickly leads to database bloat (and database storage is typically much more expensive than object storage).

The usual approach for storing media is to put the file in object storage (like S3), or in a local directory, and store a reference to it in the database (for example a URL or path).

Initially we can just store the media files in a local directory, but supporting the S3 protocol would be great in the future.

The steps required to implement this:

MediaHandler class

# This is just an abstract base class for all other media handlers:
class MediaHandler:
    pass

@dataclass
class LocalMediaHandler(MediaHandler):
    root_path: str

    def store_file(self, file):
        ...

    def retrieve_file(self, path: str):
        ...

TableConfig changes

media_handler = LocalMediaHandler(root_path='/var/www/files/')

app = create_admin(
    TableConfig(
        Movie,
        media_handler=media_handler,
        media_columns=[Movie.poster]
    )
)

PiccoloCRUD changes

There will be a new endpoint, something like:

/tables/director/1/media?column=poster

Which can be used to retrieve the actual media file.

UI improvements

The UI will know if a column is used for media storage by inspecting the JSON schema:

/api/tables/director/schema

PiccoloCRUD would've added an extra field to it called 'media_columns', using create_pydantic_model's schema_extra_kwargs feature.

The UI would then render a file upload box for that field. In the future we could support simple editing functionality like cropping images (there are several JS libraries for this), but that's down the road.

Any Interval fields are shown as text boxes, where you input a number of seconds. It works fine, but could be more user friendly.

The schema for a table with an Interval column looks like this (accessible via /api/tables/my_table/schema).

{
    "title": "MyTableIn",
    "type": "object",
    "properties": {
        "interval": {
            "title": "Interval",
            "extra": {},
            "nullable": false,
            "type": "number",
            "format": "time-delta"
        }
    }
}

We can tell if it's an Interval from the format field in the schema, which is "time-delta".

Hi,

I have a model where a PK is defined on an explicit Varchar field, like this

class MyModel(Table):
    identifier = columns.Varchar(length=64, primary_key=True)
   .....  other fields .....

It's entirely on purpose. I don't want the PK to be an auto-incremented integer. I want a random string as PK. ORM allows for that, which is good.

The problem is trying to add those objects via admin. Admin UI does not show any textbox to enter the PK value and it is not possible to add those objects.

Apparently admin assumes that primary key column is always an auto-incremented integer. But ORM allows to have PK on non-int non-incrementable column.

Any advice how to work around this problem?

I've created a table entry like this: expiry = Timestamptz(null=True)

A few things I'm noticing in piccolo-admin

• it's not possible for the datetime to be None, piccolo-admin always suggests the current time/date
• the datetime picker uses a 12-hour (pm/am) type clock. It would be nice if that was configurable for "non-US" users

I'd really like it to be possible to disable the datetime picker altogether and have users type in a datetime string instead, with the option of having the field empty (indicating None) too.

Allows replacing the built-in auth backend with a custom one.

This allowed me to do:

class HackyAuthUser(BaseUser):
    def __init__(self, user_id: str = 'unknown', display_name: str = 'unknown'):
        self._user_id = user_id
        self._display_name = display_name

    @property
    def is_authenticated(self) -> bool:
        return True

    @property
    def display_name(self) -> str:
        return self._display_name

    @property
    def user_id(self) -> str:
        return self._user_id


class HackyAuthBackend(AuthenticationBackend):
    def __init__(self, header_name):
        self.header_name = header_name

    async def authenticate(self, conn):
        if self.header_name not in conn.headers:
            raise AuthenticationError('Invalid credentials')
        user_name = conn.headers[self.header_name]
        return AuthCredentials(scopes=[]), HackyAuthUser(user_name, user_name)


app = FastAPI(
    routes=[
        Mount('/admin/', create_admin(
            tables=APP_CONFIG.table_classes,
            auth_backend=HackyAuthBackend(header_name='Authorization'))
              ),
    ],
)

It would be cool if it was somehow possible to override the default "non-authenticated" behavior, and for example have admin-api redirect the user to another login url instead of the built-in one, but I didn't find a clean way to do that.

Hi, We're looking to use piccolo-admin in a project, but we want to plug in our internal auth mechanisms, which we typically use together with oauth-proxy to wrap 3rd party apps in our auth layer.

Because of this, I'd like to use piccolo-admin but without any of the built-in authz/authn functionality. I'd like piccolo-admin to simply assume that every request comes from an admin users (we'll ofc handle authz/authn outside piccolo-admin).

I haven't yet looked at the code, but it would be interesting to hear of something like this is already supported or planned. From what I can see from the create_admin 's parameters there doesn't seem to be any obvious way of achieving what I want today.

So we have an UUID primary keys and want to hide them in admin, but that's happens:

It would be cool if the record link field was parameterized in TableConfig