janneman wrote: > Then the second one can be used if one inherit a other object from an other > module with its's new module, thus changing the current functionality. Then > those changes can be documented in the new module, where the new module will > take the lead in the documentation?
No, in this case you also use the first one. The second method is only used when you do not have write access to the repository where the module is being developed. For example, the base module. Let's see another example. There is the 'account_payment' module which adds the possibility of paying invoices. Right. If you want to write documentation for this module you won't be able to write it because you don't have write access to the 'addons' repository. Then we could have a module called "addons_doc" in extra-addons repository with this structure: addons_doc/doc/modules/account_payment/ Once you have that, you may want to document 'account_payment_extension' module which, of course, modifies 'account_payment' module. As 'account_payment_extension' is in extra-addons repository and you have write access to it. You would just have the following structure: account_payment_extension/doc/ Alternatively you could add the documentation to addons_doc, having: addons_doc/doc/modules/account_payment/ addons_doc/doc/modules/account_payment_extension/ Ideally, no module should have the 'doc/modules' structure because it would mean that each module has its own documentation, but the 'modules' trick lets us workarround this problem. Hope it's now clearer. Please let me know otherwise! ------------------------ Albert Cervera i Areny http://www.NaN-tic.com OpenERP Partners -------------------- m2f -------------------- -- http://www.openobject.com/forum/viewtopic.php?p=60607#60607 -------------------- m2f -------------------- _______________________________________________ Tinyerp-users mailing list http://tiny.be/mailman2/listinfo/tinyerp-users
