Make a field required on view level

Support Developer
1

I want to make a field required on view level.

I checked form.rng file, we cannot use required=“1” in form view file.
example: < field name=“abc” required=“1” >

Can anyone help me how I can do it ?

2

You should make the field always required:

name = fields.XXX('Name', required=True)
3

I want to do it in xml not in py file

4

Why? Could you explain your requirement?

5

See Views — trytond 5.3 documentation You have to use the states property.
You have to play a bit with the syntax to get it correct.

<edit>
I got it totally wrong :frowning_face: There is no required for fields available. Views — trytond 5.3 documentation
</edit>

6

I don’t want to make it required on model level, because record will create from wizard so If I make it required on model level then I have to mention these field on wizard also.

So I have to make them required on view level.

7

But this will not enforce it at all and create a bad UX. For example, if a user open the form of a record created without the value filled, he will not be able to make any modification nor browse to the next record without filling the value.
Are you sure you do not need to manage it using a workflow? Or fill with a default value when it is created from wizard?

8

You must implement a Model View for your wizard and your “main” model and both must inherit from a Mixin class where you must include shared fields. Then, In setup method of “main” model you can set as “required” the fields you need.

9

Another alternative is to use the states dictionary in the field definition (Fields — trytond 5.3 documentation). This allows you define the conditions in which the field is required or not.

example in http://hg.tryton.org/modules/sale/file/tip/sale.py#l973

10

I would not recommend to use contextual value to define the required state because it does not solve:

This is the main reason why in Tryton we force to have declarative schema to avoid such side effect.

11

But it depends of case: for example in particular state of workflow, different fields by type of record, among others.
And on the Eval() sentence can him indicate a default value, and the depends fields on the definition can help to manager that situation.

12

We agree that such case is good but depending on the context is bad because it generate side effect.

13

ok :smile: is wrong word: not “context” else “conditions”