Non-JPA DTOs, AutoForm, AutoGrid and the problem with `id` and `version`

Hi everyone :wave: ,
based on Hilla 2.5: DTO support for CRUD components I started to use Hilla鈥檚 AutoForm, AutoGrid and AutoCrud together with MongoDB. Implementing a custom ListService<T> for AutoGrid and a custom CrudService<T, ID> for AutoForm and AutoCrud is pretty straight forward.
Unfortunately, there seems to be a problem with the field id and version of my DTO when the AutoGrid and AutoForm component is rendered in the browser. Both fields are visible, and I think that is not intended ([autogrid] Hide @Id and @Version columns automatically 路 Issue #1266 路 vaadin/hilla 路 GitHub).
The field version is detected using the annotation jakarta.persistence.Version (hilla/packages/ts/react-crud/src/model-info.ts at 7160c269770de19d244096af390e61d8e2b88e54 路 vaadin/hilla 路 GitHub). As I鈥檓 using a non-JPA approach with MongoDB, I can鈥檛 use this annotation.
The field id is detected based on its name, the annotation jakarta.persistence.Id or from the prop itemIdProperty (hilla/packages/ts/react-crud/src/model-info.ts at 7160c269770de19d244096af390e61d8e2b88e54 路 vaadin/hilla 路 GitHub). This means, that for a non-JPA DTO it should work based on the field-name id or with itemIdProperty, but unfortunately that is not the case. I tried both approaches, but the field id is still shown in AutoGrid and AutoForm. The problem is maybe related to the current implementation of getDefaultProperties (hilla/packages/ts/react-crud/src/model-info.ts at 7160c269770de19d244096af390e61d8e2b88e54 路 vaadin/hilla 路 GitHub), because in this function the field id is only excluded based on the annotation jakarta.persistence.Id.
As a workaround, I can exclude id and version from AutoGrid and AutoForm using the props visibleColumns and visibleFields. This works well.

Could someone please give me some advice regarding the correct usage of id and version fields with non-JPA DTOs?

Yes, you are right, OOTB Id and Version control is only available to JPA. For other non-JPA DTO鈥檚 you are already probably correct with configuring visible columns in AutoForm/AutoForm and handling them in Backend.
(better way maybe would be, but this enhancment is still waiting for review)