Form view for custom Income Tax module – One2Many tree does not expand vertically in notebook

Hello,

I’m working on a custom Georgian localization module and I have a problem with the layout of a form view.
Screenshots are attached.

Environment

  • trytond & sao from the official Docker image (7.6, Python 3.11)

  • Database(s): tr_fresh and TR1

  • Custom module: income_rs

Goal

In my custom Income Tax declaration module I have a master model:

Model name: ge.income.declaration

Model name: ge.income.declaration.line

ge.income.declaration.line tree income_declaration_line_tree <![CDATA[ ]]> ge.income.declaration form income_declaration_form <![CDATA[
        <notebook colspan="4" yexpand="1">
            <page id="lines_page" string="დეკლარაციის სტრიქონები">
                <field name="lines" mode="tree,form" colspan="4" yexpand="1"/>
            </page>

            <page id="rs_info_page" string="RS ინფორმაცია">
                <group id="rs_group" col="4">
                    <label name="rs_id"/>
                    <field name="rs_id"/>
                    <label name="rs_status"/>
                    <field name="rs_status"/>
                </group>
            </page>
        </notebook>

        <group id="totals" col="4">
            <label name="total_amount"/>
            <field name="total_amount"/>
            <label name="total_tax"/>
            <field name="total_tax"/>
        </group>

        <group id="buttons" col="4">
            <button name="compute" string="გადათვლა" icon="tryton-refresh"/>
            <button name="send_rs" string="RS-ზე გაგზავნა" icon="tryton-ok"/>
        </group>
    </form>
    ]]>
</field>

Observed behaviour (see screenshots)

  • In the Income Tax form the Lines notebook page shows the tree in a small fixed-height area at the top, and below it I have a very large empty white space.

  • The tree does not expand vertically even though both the <notebook> and the lines <field> have yexpand="1" and the notebook has colspan="4".

  • The bottom-right “resize handle” exists only for text areas, so I understand I can’t manually resize the tree with the mouse – but I was expecting the notebook + yexpand layout to automatically use the available height, like other standard forms do.In Administration → User Interface → Views:

    • I removed all existing form views and extensions for ge.income.declaration,

    • then re-ran -u income_rs so the views are recreated from the module XML.

  • Hard-refreshed SAO in the browser (Ctrl+F5), logged out/in.

  • Earlier I experimented with an extension view and got errors like
    Argument must be bytes or unicode, got 'NoneType'
    when the inherit xpath was wrong, but those extension records are now deleted and only the base form above is used.

Despite all this, the layout of the Lines tab is still the same: small list at the top and large unused area below.


Question

Is my XML/layout wrong, or is this a SAO layout limitation/bug?
What is the recommended way in Tryton to make the One2Many tree on a form (inside a notebook) use the remaining vertical space, similar to built-in modules?

Thanks in advance for any hints, and please see the attached screenshots for the visual behaviour I described.

This is a limitation of HTML/CSS. The xxx2Many has a minimal and maximal height defined. So it will expand depending on the content between both heights.

Right now the xxx2Many table stops growing at about half of the window height, leaving a lot of empty space below on large screens.
Would it be possible to increase the maximum height (for example to around 70–75% of the window), or make this value configurable in SAO?

No because the window height depend on the content.

No but you can set the height attribute but I do not recommend it.

In the Income Tax form I use a One2Many/Many2Many field embedded in the main form.
I tried to change the height attribute (number of rows), but in SAO the widget seems to be capped at a certain max height (around 7–8 rows). Increasing height further does not make the list taller, it just starts scrolling.
So the behavior is limited by SAO’s HTML/CSS max height, not by the height attribute itself.