ORM features: history; dynamic translation; acl; change requests
|Reported by:||Owned by:||nobody|
|Has patch:||no||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
I already did some workarounds for getting Django towards my needs, but I feel for future changes this may be a bad way to adopt Django for my needs:
For my target application (a very powerful ERP/CRM/... system) I need:
- an audit trail/history like described in ProDjango book + ability to mark tables as deletable or not, thus the audit has additional fields like 'marked-deleted', 'marked-undeleted', 'restored', ...
(This is also useful in any web application I believe - due to local laws it may be initialized with a time limit ...)
- have an ordered ManyToManyRelation like Elixir/SQLAlchemy offers
- dynamic translation Fields as Subclasses/options from/for CharField and TextField: if marked as dynamic_translatable it causes a subtable referring to the initial field name with an own manager that handles acces to the wanted language. Also that manager offers a direct way to access/create special language entries for the field.
- extended ACL patterns: currently table wise is implemented, column wise plus object wise would be a real great benefit, if defining:
table: read, write, create new entry
column: read, write, default if no write access
object/row: read (columns), write (columns)
(of course we need to find out the best order of grant/deny permissions)
- as based on ACL and History Impl: change requests: instead of writing changes to the objects create a new request object in a separate table request_objects, managed like history per table and make it accessible to the admins that can grant/commit the requested changes or deny them thru a message to the user.
I'd really like to contribute to the project and spend some work to make this real.
I know these modifications could be implemented as 'user-space-addons' but it hooks to deep into the framework to be futureproofed.