Hi Michael,
The HierarchyModel base class already defines a name field, and uses it as the primary key.
You define a second name field here, and a different primary key.
There is some logic in the export-as-a-workbook feature that is ordering the output to put the roots at the top, followed by the level 2 records, etc. That logic may be confused by the double name field.
Solution would be a) rename or remove your “name” field and b) don’t use “code” as primary key (but you can define a unique index on it if you want – see https://docs.djangoproject.com/en/2.2/ref/models/options/#unique-together)
Disclaimer: I haven’t tested whether this solution fixes your problem...
Stay safe!
Johan De Taeye
Mob: +32 477.385.362
Skype: jdetaeye
Visit us at https://frepple.com
--
You received this message because you are subscribed to the Google Groups "frePPLe users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to frepple-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/frepple-users/2a3c320d-e95c-4dc0-bb41-4538ab3721a4n%40googlegroups.com.
>>When should you call the HierarchyModel base class?
This class is a help when your model can have an arbitrary number of levels in its hierarchy.
>>in what cases it is possible to make a hierarchy as in the example of the "Operation" model?
HierarchyModel is just an auxiliary class that we find useful and reusable. Your choice whether you reuse it or not.
Operation is a special case, because we only need to support a single level of parents. The lft&rght&lvl fields are overkill for what we need.
To view this discussion on the web visit https://groups.google.com/d/msgid/frepple-users/06947660-70ab-4f15-bbf0-e1a46b915789n%40googlegroups.com.