custom object not exporting data to spreadsheet, how to fix?

Skip to first unread message

Michael N

Mar 10, 2021, 9:38:38 AM3/10/21
to frePPLe users
Hello friends! Good health to everyone !
I have created a custom object with a hierarchical structure, the name of which is "Groups / Subgroups". In addition to other fields, it also has an owner (parent) field. Filling, editing records in this object without any problems, everything is OK! But when exporting to an Excel spreadsheet, it is empty. This happens when there is a parent record in the owner field. If the owner column is empty, then all records are exported. This is only when exporting all tables to one common file - in the Admin menu. Exporting this table separately from the interface of this object succeeds.. 

What did I do wrong while creating the model?
(frepple 6.10.0 + Postgres 12 + Win10)


Johan De Taeye

Mar 10, 2021, 10:14:21 AM3/10/21


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

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

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
To view this discussion on the web visit

Michael N

Mar 11, 2021, 1:59:52 AM3/11/21
to frePPLe users
thanks dear Johan, for the detailed answer, that explains everything. Indeed, when creating an object, the primary key is redefined in the "Code" field.
as it turned out, the SQL, when creating an object, redefined the field with the primary key:
I noticed that some classes in a model with a parent hierarchy use the HierarchyModel base class, (for example, Locations, Resources ...) and some models have a hierarchy, but do not use the HierarchyModel base class (for example: Operations). 

When should you call the HierarchyModel base class? 
in what cases it is possible to make a hierarchy as in the example of the "Operation" model?

среда, 10 марта 2021 г. в 18:14:21 UTC+3, Johan De Taeye:

Johan De Taeye

Mar 11, 2021, 2:46:45 AM3/11/21


>>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.

Michael N

Mar 12, 2021, 5:36:00 AM3/12/21
to frePPLe users
Johan, thanks for the help!
I removed the base class with the hierarchy. Updates were successful, migration was successful.


Migrations for 'usrckk':
    - Remove field lft from crachtype
    - Remove field lvl from crachtype
    - Remove field rght from crachtype
    - Remove field lft from dept
    - Remove field lvl from dept
    - Remove field rght from dept
    - Remove field lft from equipclass
    - Remove field lvl from equipclass
    - Remove field rght from equipclass
    - Remove field lft from equipgroup
    - Remove field lvl from equipgroup
    - Remove field rght from equipgroup
    - Remove field lft from equiptype
    - Remove field lvl from equiptype
    - Remove field rght from equiptype
    - Remove field lft from material
    - Remove field lvl from material
    - Remove field rght from material
    - Remove field lft from room
    - Remove field lvl from room
    - Remove field rght from room
    - Remove field lft from section
    - Remove field lvl from section
    - Remove field rght from section
    - Remove field lft from typicalcrach
    - Remove field lvl from typicalcrach
    - Remove field rght from typicalcrach
    - Remove field lft from typicaloffense
    - Remove field lvl from typicaloffense
    - Remove field rght from typicaloffense
    - Remove field lft from typicalwork
    - Remove field lvl from typicalwork
    - Remove field rght from typicalwork
    - Alter field owner on crachtype
    - Alter field owner on dept
    - Alter field owner on equipclass
    - Alter field owner on equipgroup
    - Alter field owner on equiptype
    - Alter field owner on material
    - Alter field owner on room
    - Alter field owner on section
    - Alter field owner on typicalcrach
    - Alter field owner on typicaloffense
    - Alter field owner on typicalwork
    - Alter field owner on worktype

Operations to perform:
  Apply all migrations: admin, archive, auth, common, contenttypes, execute, input, metrics, output, reportmanager, usrckk, usrtor
Running migrations:
  Applying usrckk.0019_auto_20210311_1133... OK

четверг, 11 марта 2021 г. в 10:46:45 UTC+3, Johan De Taeye:
Reply all
Reply to author
0 new messages