This is not only for products, its for any object. Product was just an example. Sent from Samsung Galaxy Note
-------- Original message -------- From: Leonardo Pistone <[email protected]> Date: 15/07/2014 08:09 (GMT+01:00) To: Alaney Kilson Dória <[email protected]> Cc: [email protected] Subject: Re: [Openerp-community] Draft Proposal for a new field type for OpenERP/Odoo Hi, let me expand a bit with what Guewen said (I agree with him). Configurable attributes and related issues got much attention, one reason being that they are important for e-commerce applications (see OCA project https://github.com/oca/product-attribute ) My advice is, before going any further with new work, give a thorough test starting with module product_custom_attributes on 7.0. In particular, you can decide to store attributes as normal columns or to serialize all of them as JSON. Furthermore, you can define different attribute sets for each product (i.e. the product shoe has attributes size and color, where the product computer has attributes disk and ram). On Tue, Jul 15, 2014 at 8:49 AM, Alaney Kilson Dória <[email protected]> wrote: Hi All, I'm sending an updated version with more info added, based on what we discussed here. Best regards Alaney Dória CEO [email protected] tm.+244 925 999 331 | +244 913 728 600 Rua Doutor Agostinho Neto, 156, Bairro Azul, Luanda - Angola, Tel: +244 913 728 600 | +244 913 728 650, Website: www.alien-group.com, Email: [email protected] Não imprima este email caso não seja estritamente necessário. A Terra agradece-lhe! On 07/14/2014 01:58 PM, Info SHS-AV wrote: +1 Hope some other guy will express its opinion. Antonio Maria Vigliotti Il 14/07/2014 14:52, Alaney Kilson Dória ha scritto: Alaney Dória CEO [email protected] tm.+244 925 999 331 | +244 913 728 600 Rua Doutor Agostinho Neto, 156, Bairro Azul, Luanda - Angola, Tel: +244 913 728 600 | +244 913 728 650, Website: www.alien-group.com, Email: [email protected] Não imprima este email caso não seja estritamente necessário. A Terra agradece-lhe! On 07/14/2014 12:50 PM, Info SHS-AV wrote: Il 14/07/2014 13:31, Alaney Kilson Dória ha scritto: Yes that's it. This field is stored by orm in xml schema the user doesn't have any control the way the data is store. This field is just added to the structure to allow the user put their own field. The user field are restricted, and this is the thing I want different opinions regarding what and how would be. For example, should we define a data as "integer", "float", "currency", or just "number". Because user might not know what is the difference. what we should try to see, is what May be intersting but we need to limit this feature in order to avoid end user mismatch. Totally agree. This is what I'm looking for, to improve the paper. I think may be dangerous use no text data type, expecially python code like eval tag of xml file; I think we do limit node nesting level and, yes, I agree data cannot be related field. Perhaps we could use only text type. For my point of view, whatever is there will be treated as text. From the point of view of the user he only see a table on which e can add a field name and it's value. Also the fields are not allow to be used for any kind of operation like add, subs. Did you think how these data can be used in report? Good point! that's something to add to the proposal. Since it's actually a pair (field name, value), assuming that for each tuple, one can have no metadata, one can have N. We would make this field be only available for loops (repeatIn). The it would be just for the sake of more control we could do the following where to put the field name and its value: object.xml_field_name.fieldName: would print all the existing field names, object.xml_field_name.fieldValue: would print all the existing field values, This would allow to control where and how I want to put this data. This would not allow indexing, since for each tuple we don't know it's max size. so if there is data it will print all, inside a loop. Imagine having spec for a car in database, which car is your product with its specs, and at the same time having also a car part with it's own spec. Also to remember that for form view, the client will not necessarily know field as a name "field name". It can be like " Property" or "Característic". I would be adding those ins a widget just as a table, so the user will never write the xml. only the Furthermore, this field should be searchable -- Antonio M. Vigliotti (Presidente & Chief Technical Officer) SHS-AV s.r.l. (impresa innovativa) zeroincombenze® Via Domodossola, 64 - 10145 TORINO - ITALY Tel. (+39) 011.0566929(2) www.shs-av.com PEC [email protected] _______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
