[Feature Request] Flexible File Extension Handling for Consumer

[lingfish]

Description

Summary

Allow users to configure whether the paperless-ngx consumer should accept files without extensions or enforce strict extension checking, to maintain backward compatibility while enabling more flexible file consumption.

Problem Description

Currently, when a file without an extension is placed in the consumer directory (e.g., a PDF named "2020-Drivers license"), the system fails to process these files completely.

The warning message shows:

[WARNING] [paperless.management.consumer] Not consuming file /usr/src/paperless/consume/2020-Drivers license: Unknown file extension.

This behavior differs from the web interface upload method, which successfully processes files without extensions.

There is #11974 with more chat/info.

Use Case

Some users might have files without extensions that are still valid documents (e.g., PDFs created by certain applications or scanned documents) and want to be able to process them automatically via the consumer directory.

Other

Proposed Solution

Add a new setting in the configuration that allows users to:

1. Maintain the current strict behavior (default) - only files with recognized extensions are consumed
2. Enable flexible behavior - files without extensions are processed if they can be identified as valid document types through content inspection
3. Perhaps also a warning popup in the UI or somewhere other than in logs, telling the user files were skipped

Configuration Options

# Allow processing of files without extensions
CONSUMER_ALLOW_NO_EXTENSION = True  # Default: False

This setting would enable the system to:

• Check if a file without extension is actually a valid document (e.g., PDF, DOCX, etc.)
• Inspect file content to determine document type
• If valid, proceed with consumption similar to the web interface

Impact

• Default behavior unchanged - existing installations will continue to work as expected
• Enhanced flexibility - users can enable more permissive mode if needed
• Backward compatibility - no breaking changes to existing configurations

Acceptance Criteria

1. New configuration option is added with clear documentation
2. Default behavior remains strict (no extension files are not consumed)
3. When enabled, files without extensions are parsed for content type
4. Valid document files without extensions are consumed properly
5. Invalid files without extensions are still rejected

[shamoon]

Thanks for opening this. I actually spent a bit of time removing the extension stuff and it seems relatively safe to do, stumpylog and I talked a bit about it and didnt really reach a conclusion yet (it may also be made unnecessary by other larger changes), so we'll see

[lingfish]

Ok, thanks. I still believe this should be consistent behaviour, ie. any ingestion method should not just rely on extension, but use inspection for content type.

[HiranChaudhuri]

I'd love to see that users can configure extensions/mime ty;es they want to store. This may require custom PDF renderers, which could be provided as sidecar containers if users so wish. This way paperless would move away from a hardcoded set of extensions or the (limited set of) filetypes identified by file and become a more versatile document management platform.

[lingfish]

Although an interesting idea, I'd like to not muddy up this FR with something a fair bit more complex to implement.

[github-actions[bot]]

This discussion has been automatically closed due to lack of community support. Please see our contributing guidelines for more details.

[github-actions[bot]]

This discussion has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion for related concerns. See our contributing guidelines for more details.