Add `processStatus` and `processingLog` fields to `Document` schema

[paulo-rossy]

Hello team!

I would like to request adding two extra fields to the Document schema.
In my project, documents are processed for an AI assistant, and the operation can take some time. To display the current status and any errors to users, please add:

1. processStatus — a string field with the values

   • "processing" — document is being processed;
   • "error" — an error occurred;
   • "processed" — processing finished successfully.

2. processingLog — a string (or text) field to store error details (e.g., “invalid file type”).

These fields will help show progress and diagnose processing failures.

Note: The field names and the list of possible values are provided as examples—they can be changed if needed.

Thank you!

[toplenboren]

Hi there,

Thanks for creating this issue! 🦖

We’ve recently created a domain for all things AI-related. (apps/condo/domains/ai)

It has model ExecutionAIFlowTask which already includes status tracking and error details for AI task execution.

Check it out here:
🔗 ExecutionAIFlowTask.js

Currently, it integrates with Flowise AI, but it’s designed to be flexible—you can adapt it for Langchain, n8n, or custom solutions.

Let me know if this fits your use case!

[paulo-rossy]

Hi @toplenboren,

Thanks for the pointer to ExecutionAIFlowTask! Unfortunately it doesn’t quite fit our workflow:

• We run a custom, in-house pipeline—no Flowise (or LangChain / n8n)—so the task model isn’t created automatically.
• The status we need is per document, and we want to show it directly in the Documents table.

For those reasons, having processStatus (enum) and processingLog (text) right on the Document schema would keep things simple and let us display progress and errors immediately.

[paulo-rossy]

@toplenboren Hello!
Are there any updates with this request? This is very important to us. The team and I also thought about it and decided that it is also very desirable to have a meta field in the Document schema

[toplenboren]

@toplenboren Hello! Are there any updates with this request? This is very important to us. The team and I also thought about it and decided that it is also very desirable to have a meta field in the Document schema

Hey, @paulo-rossy – sorry for the delayed response

About meta field – i looked it up and it seems that it is already in the codebase:

From Document.js

const Document = new GQLListSchema('Document', {
    schemaDoc: 'Document with file attached to organization or property. It could be some kind of property documentation, inspection reports or other documents',
    fields: {
        organization: ORGANIZATION_OWNED_FIELD,
        property: {
            schemaDoc: 'Property to which the document is attached',
            type: 'Relationship',
            ref: 'Property',
            kmigratorOptions: { null: true, on_delete: 'models.CASCADE' },
            access: createAndReadOnlyFieldAccess,
        },
        category: {
            schemaDoc: 'Document type',
            type: 'Relationship',
            ref: 'DocumentCategory',
            kmigratorOptions: { null: true, on_delete: 'models.SET_NULL' },
        },
        name: {
            schemaDoc: 'Name of the document. By default it\'s file name',
            type: 'Text',
            isRequired: true,
        },
        file: {
            schemaDoc: 'File attached to document',
            type: 'File',
            adapter: Adapter,
            isRequired: true,
            access: createAndReadOnlyFieldAccess,
        },
        canReadByResident: {
            schemaDoc: 'If set to true, this means document will be accessible by residents',
            type: 'Checkbox',
            isRequired: true,
            defaultValue: false,
        },
        meta: META_FIELD,
    },
    hooks: {
        validateInput: async ({ resolvedData, existingItem, context }) => {
            const newItem = { ...existingItem, ...resolvedData }

            const resolvedPropertyId = resolvedData['property']
            if (resolvedPropertyId) {
                const property = await getById('Property', resolvedPropertyId)

                if (get(property, 'organization') !== newItem.organization) {
                    throw new GQLError(ERRORS.WRONG_PROPERTY_ORGANIZATION, context)
                }
            }
        },
        resolveInput: ({ resolvedData, operation }) => {
            if (operation === 'create' && !resolvedData['name']) {
                resolvedData['name'] = get(resolvedData, 'file.originalFilename')
            }

            return resolvedData
        },
        afterChange: fileMetaAfterChange,
        afterDelete: async ({ existingItem }) => {
            if (existingItem.file) {
                await Adapter.delete(existingItem.file)
            }
        },
    },
    plugins: [uuided(), versioned(), tracked(), softDeleted(), dvAndSender(), historical()],
    access: {
        read: access.canReadDocuments,
        create: access.canManageDocuments,
        update: access.canManageDocuments,
        delete: false,
        auth: true,
    },
})

Hey,

About the elephant in the room — I’m actually a bit hesitant to add processStatus and processingLog. These fields would introduce additional complexity (status enums, status transition logic, possibly i18n for logs), but there’s currently no feature in the product that would actually use them. So we'd end up maintaining logic that doesn't bring any real value to the project at this point.

Would the meta field work for your use case? It’s flexible (JSON), though less strict.

If not, here are a couple of alternatives:

- We can maybe add field objectId to ExecutionAIFlowTask, so that you will be able to fetch the related task from the Document page and show status/error. We can also add a generic provider (?) so that you would not have to write any flowise specific logic

- Maybe use #5742 — this PR will allow you to define a field in your DB and use it similarly: track changes in these added fields and fetch the result in another query

Please Let me know if either option would work. If not, we can consider adding something to the Document schema — not ideal on our side, but open to it if needed.