vedawebproject / tekst Goto Github PK

!! Important: We'll have to wait for this to be fixed (potentially via this PR)!

See here:

• https://fastapi.tiangolo.com/tutorial/query-params-str-validations/#additional-validation
• https://fastapi.tiangolo.com/tutorial/path-params-numeric-validations/#better-with-annotated
• https://fastapi.tiangolo.com/tutorial/dependencies/#first-steps

Like so:

class Text(TextRigBaseModel):
    # fields ...
    # validators ...
    class Config:
        schema_extra = {
            "example": {
                "title": "Rigveda",
                "slug": "rigveda",
                "subtitle": "An ancient Indian collection of Vedic Sanskrit hymns",
                "levels": ["Book", "Hymn", "Stanza"],
                "locDelim": ".",
            }
        }

There should always be one left

How to implement snake/camel-case endpoint parameters (right now there are snakes everywhere!)?

See this, too!!

See tusen-ai/naive-ui#3549

Add a collapse component with each kind of layer (official/user) and have "official" open by default

Implement some way of mixing in creation/modification timestamps into certain data models.

https://github.com/casey/just

...using MkDocs with Material for MkDocs via GH Actions flow, deploying to GH pages.

• my user data
• my layers
• ...

Add server/client repos as modules to main repo?
See: https://git-scm.com/docs/gitmodules

Use index hints where applicable!

Create platform data for /platform endpoint during startup once and hold it in memory.
This should include:

• data on existing texts (via get_all_texts())
• layer types and all info on them
• platform settings
• ...

All operations that persist data should be removed from the startup sequence (at least when not in DEV MODE) and instead be done by a script before the ASGI workers spawn.

See: tiangolo/fastapi#6209

Per DB request only one index can be used (I GUESS!)

... for not only deleting single documents, but also cleaning up everything that depends on them (e.g. delete all units if a layer is deleted).

http://127.0.0.1/browse/foo -> invalid text doesn't get changed to valid one!

Right now, the layer coverage data endpoint returns superfluous data. The current client implementation would only need total/covered numbers. So either...

1. go all in and extend the coverage functionality to visualize coverage better and even automatically list covered/uncovered locations (depending on what there's fewer of), or
2. Change the coverage data endpoint to only return the necessary data.

Should be .2s instead of .3s
...can we change this in naive-ui somehow?

See: https://beanie-odm.dev/tutorial/event-based-actions/

Index via Elasticsearch. Mongo only allows 1 text index per collection (🤮) and probably wouldn't get the job done anyway.

Refactor location select logic - it's still quite a mess

See: https://docs.pydantic.dev/2.0/usage/pydantic_settings/#secrets

This doesn't seem to be possible - although more research is needed...

Implement emails, mock emails in dev, then generally override methods of UserManager: see

• password reset/change
• change email
• ...

For emails, see: https://sabuhish.github.io/fastapi-mail
....although definitely seems to bring too much overhead. What are simpler solutions?

... as soon as they are out of their current beta versions:

• FastAPI (currently 0.100.0-beta1)
• Pydantic (currently v2.0b3)

See notes on upgrading FastAPI and migrating Pydantic!

Always provide at least one sample text ... even in production: If there is no text in the DB, create one!

Add custom schema examples to data model definitions:

class SomeModel(BaseModel):

    # ...

    class Config:

        ...

        schema_extra = {
            "example": {
                "name": "Some Name",
                "email": "..."
            }
        }

There's a weird bug in the selection of a location via location controls: In some (apparently random) situations, it just stops working. The location (lvl and pos) in the URL are changed, but the app doesn't react to that.

should be done after #28 is completed

Currently preferred strategy: Implement configurable interface to Keycloak (and/or similar) to have a pluggable external management for all things auth*.