Encoding in XML format is a great way of including information in a structured way in modules datafiles. It’s also a good way to avoid critical information to be overridden by a user.
The problem:
There is a Tryton limitation because currently modifying a record field coming from xml datafile is an all-or-nothing task (if the field is declared on the xml file, then becomes non-modifiable).
The model fields that are required must be entered in the data file in order to create the record
Proposal :
We include a new attribute (eg, “modifiable”) for the xml element that allows to modify the specific field. This will provide maximum flexibility, on which fields can be modified and which can not.
In the example of the product associated to the GNU Healh WHO meds, this is the situation:
The list and cost prices associated to the product are required fields, so we need to include them in the xml datafile.
If we have include the new attribute :
Then the system will set the declared value as an initial price, but would later allow the user to modify that price. It will also skip this entry in the xml in the future (to avoid overriding the current value on the system).
With this functionality, in the WHO medicines example, we have both non modifiable fields (medicament product name, category, … ) and modifiable fields (prices). All of this while keeping the benefits of having the datafile in XML format.
I don’t think it is a good idea. Tryton since the beginning has never encouraged the creation of modifiable data via XML. So introducing such attribute will be a move in the wrong direction.
Also the current API ModelStorage.check_xml_records is already very flexible.
Hi !
The method check_xml_records seems to work at record level, so we would still be in the all-or-nothing scenario. We need to be able to go down at field level.
I think that including the “modifiable” attribute for the field element will provide total flexibility:
Keep secured those fields which values can not be modified by the user (like the medicament name)
Allow specific fields to be updated by the user (like the price in the example)
So if check_xml_records allow to modify the record at field level, then we’re OK.
Still I think that the modifiable attribute offers a much general and dynamic scenario, without the need of coding.
But we don’t want to push this way of importing data since day 1. And indeed I think the ‘noupdate’ should be removed and instead the very few modules that uses it should use the configuration wizard as it was the plan since the inclusion of this wizard.
I agree with ceds proposal. In spanish we have two modules that import data (banks and zips) using the configuration wizard and its a perfect for customizable data.