2013/12/10 Jordi Esteve <jest...@zikzakmedia.com> > On 10/12/13 16:33, Guillem Barba Domingo wrote: > > > 2013/12/10 Josias Pérez <jep...@gmail.com> > >> Hi Guillem, >> >> I was talking with Zikzakmedia team about training module too. >> >> On Monday, December 2, 2013 11:43:46 AM UTC-6, Guillem Barba wrote: >>> >>> >>> I want to contribute too with the development, I was been migrating >> the OERP training module, I the work is in >> https://github.com/iehoshia/trytond-training, feel free to contribute. >> >> Zikzakmedia team give a recommendation, distribute the functionality in >> diferents modules, >> >> >> training: Training basics; course, offer, sessions. >> * training_catalog: To manage course catalog. >> * training_subscription: To manage subscriptions on courses. >> * training_participation: To manage session and participation. >> * training_subscription_invoice: To manage invoices on courses. >> * training_room: To manage rooms and buildings >> * training_exam: To manage exams >> > > It is a good idea. In my proposal I mantain the subscription and > participation in the core module. For me, it doesn't make sense to have > courses if there isn't subscriptions nor participations. > > > It is not an important issue, but I think is better to split courses and > subscriptions-participation in different modules, like is described in the > above list of modules for the training area. > > 1) In a free or open course/session maybe you don't need to manage any > subscription, neither participations. > > 2) It can be compared to some core modules of Tryton: product and sale. > You can not have sales without products, but their functionality is split > in two modules. You can apply the same approach in the training world: More > or less, the products are courses and sessions. And the sales are the > subscriptions. >
I don't agree. Products is something generic that is used by several modules. You can have products without sales but you will have shipments or purchases or something... I can't imagine someone with products and anything using that. Courses and sessions is not generic. If you look my proposal, Subscription is only the registration of party in a course (is the equivalent to subscription line in OERP) and anything else in the core module. I can't imagine a Use case where you have courses but you don't want to register who participate in these courses. Almost in a MOOC course you would to have a register of participants. IMHO, your proposal is more similar to have the 'sale' module splitted in 'sale' and 'sale_shipment'. Maybe, it could be someone who wants to manage Sale without managing warehouse/stock... but support this strange use case doesn't compensate the effort to have subscriptions/participations splitted from core module. -- Guillem Barba http://www.guillem.alcarrer.net
