We are working in an IBM FileNet P8 (5.5.x) environment and need to enforce a maximum folder size limit within the Object Store.

Business requirement:

1. A folder should not exceed a defined size threshold (MB/GB).

2. If a document upload causes the folder to exceed the limit, the operation should be blocked and a meaningful exception or error should be returned to the user.

3. This behavior should be consistent across ICN, ACCE, and custom integrations.

IBM FileNet does not provide a native folder-quota feature, so we are evaluating custom approaches.

Approaches considered

1. Change Preprocessor
While Change Preprocessors run before the object is committed, we have identified a key limitation:

• The actual document content size (ContentElement size) is not reliably accessible at preprocessor time.

• This makes it difficult to accurately calculate the projected folder size before the document is saved.

Due to this limitation, Change Preprocessors do not appear to be a feasible option for enforcing folder size limits based on actual content size.

2. Event Action Handler (Java / JavaScript)
Event Actions provide access to:

• Persisted document properties

• Content size via ContentElements

• Folder relationships

Although Event Actions execute post-commit, the size calculation is reliable. The enforcement would therefore require:

• Calculating the folder's total size

• Comparing it against a configurable threshold

• Rolling back the operation (delete document / throw exception) if the limit is exceeded

This currently appears to be the most feasible technical approach, despite the post-commit nature.

Additional considerations

• Maintaining folder size as a custom metadata property to avoid repeated aggregation

• Performance impact on large folders

• Error propagation and user experience in ICN

• Best practices used in production deployments

Questions to the community

• Has anyone implemented a reliable folder size enforcement mechanism in FileNet?

• Are there supported or recommended alternatives beyond Event Actions?

• Any sample implementations, performance tips, or architectural guidance?

• Are there roadmap plans for native folder quota support in FileNet?

Any insights or real-world experience would be highly appreciated.

Whatever you do, do not forget the use cases:

• move document
• move folder

We are working in an IBM FileNet P8 (5.5.x) environment and need to enforce a maximum folder size limit within the Object Store.

Business requirement:

1. A folder should not exceed a defined size threshold (MB/GB).

2. If a document upload causes the folder to exceed the limit, the operation should be blocked and a meaningful exception or error should be returned to the user.

3. This behavior should be consistent across ICN, ACCE, and custom integrations.

IBM FileNet does not provide a native folder-quota feature, so we are evaluating custom approaches.

Approaches considered

1. Change Preprocessor
While Change Preprocessors run before the object is committed, we have identified a key limitation:

• The actual document content size (ContentElement size) is not reliably accessible at preprocessor time.

• This makes it difficult to accurately calculate the projected folder size before the document is saved.

Due to this limitation, Change Preprocessors do not appear to be a feasible option for enforcing folder size limits based on actual content size.

2. Event Action Handler (Java / JavaScript)
Event Actions provide access to:

• Persisted document properties

• Content size via ContentElements

• Folder relationships

Although Event Actions execute post-commit, the size calculation is reliable. The enforcement would therefore require:

• Calculating the folder's total size

• Comparing it against a configurable threshold

• Rolling back the operation (delete document / throw exception) if the limit is exceeded

This currently appears to be the most feasible technical approach, despite the post-commit nature.

Additional considerations

• Maintaining folder size as a custom metadata property to avoid repeated aggregation

• Performance impact on large folders

• Error propagation and user experience in ICN

• Best practices used in production deployments

Questions to the community

• Has anyone implemented a reliable folder size enforcement mechanism in FileNet?

• Are there supported or recommended alternatives beyond Event Actions?

• Any sample implementations, performance tips, or architectural guidance?

• Are there roadmap plans for native folder quota support in FileNet?

Any insights or real-world experience would be highly appreciated.

I can't find a feasible solution to achieve my use case. My requirement is simple: to restrict a folder to a limited size. However, I am unable to find any solution to implement this.

Whatever you do, do not forget the use cases:

• move document
• move folder

We are working in an IBM FileNet P8 (5.5.x) environment and need to enforce a maximum folder size limit within the Object Store.

Business requirement:

1. A folder should not exceed a defined size threshold (MB/GB).

2. If a document upload causes the folder to exceed the limit, the operation should be blocked and a meaningful exception or error should be returned to the user.

3. This behavior should be consistent across ICN, ACCE, and custom integrations.

IBM FileNet does not provide a native folder-quota feature, so we are evaluating custom approaches.

Approaches considered

1. Change Preprocessor
While Change Preprocessors run before the object is committed, we have identified a key limitation:

• The actual document content size (ContentElement size) is not reliably accessible at preprocessor time.

• This makes it difficult to accurately calculate the projected folder size before the document is saved.

Due to this limitation, Change Preprocessors do not appear to be a feasible option for enforcing folder size limits based on actual content size.

2. Event Action Handler (Java / JavaScript)
Event Actions provide access to:

• Persisted document properties

• Content size via ContentElements

• Folder relationships

Although Event Actions execute post-commit, the size calculation is reliable. The enforcement would therefore require:

• Calculating the folder's total size

• Comparing it against a configurable threshold

• Rolling back the operation (delete document / throw exception) if the limit is exceeded

This currently appears to be the most feasible technical approach, despite the post-commit nature.

Additional considerations

• Maintaining folder size as a custom metadata property to avoid repeated aggregation

• Performance impact on large folders

• Error propagation and user experience in ICN

• Best practices used in production deployments

Questions to the community

• Has anyone implemented a reliable folder size enforcement mechanism in FileNet?

• Are there supported or recommended alternatives beyond Event Actions?

• Any sample implementations, performance tips, or architectural guidance?

• Are there roadmap plans for native folder quota support in FileNet?

Any insights or real-world experience would be highly appreciated.