ORM features: history; dynamic translation; acl; change requests

[mikew@…]

Hi @all,

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.

THX,
Mike

[Luke Plant]

This is much too broad to be a single ticket. Some of the things you want are already possible with Django, but are in the class of things that you must implement yourself, using the hooks provided. Please ask on django-users for help, or file individual specific tickets for the features you need. Better still, since many of these are significant feature requests, after 1.2 is out get involved in the 1.3 process (on django-developers) with specific suggestions. I will warn you that some of the things you mention will almost certainly be considered out-of-scope for Django, being too application specific.