Las propiedades de un campo son las características que definen cómo se comporta en un formulario: si es obligatorio, si se muestra, si se puede editar. En Employee Central se fijan en el modelo de datos, como vimos en la U3, con atributos como required y visibility. Pero una regla de negocio también puede cambiarlas, y lo puede hacer según una condición. Esa es la diferencia: el modelo de datos fija la propiedad para todos; la regla la cambia según el caso.
Para que una regla pueda manejar las propiedades, necesita un objeto base de modelo. La academia lo explica en la lección de reglas: los objetos base de modelo son necesarios para establecer las propiedades de un campo, como obligatorio, con valores verdadero o falso, y visibilidad, con las opciones ninguna, editar o ver. Con un objeto base estándar, la regla solo ve el valor del campo, que es el problema A del ejercicio de la L1.
El caso de uso típico es un campo que depende de otro. La lección da dos ejemplos: que el fin del período de prueba sea obligatorio solo para AR01, o que un campo de convenio se muestre solo para los empleados dentro de convenio. En un cliente regional aparecen muchos más: campos que solo tienen sentido en un país, datos que solo carga RR. HH. para ciertos tipos de contrato, campos que se ocultan para los trabajadores contingentes.
La consigna 3 del ejercicio de la L2 arma el primer ejemplo. La regla usa el escenario de reglas al cambiar, con el modelo de información del puesto. Si la entidad legal es AR01, establece la propiedad Obligatorio del campo fin del período de prueba en verdadero; si no, en falso. Se asigna en jobInfo, en el campo entidad legal, al cambiar. La parte SINO es necesaria: sin ella, una vez que el campo se vuelve obligatorio, nada lo vuelve opcional para las demás entidades legales.
Ese diseño tiene un límite que el ejercicio también trata. La regla al cambiar corre cuando cambia la entidad legal. Si un empleado de AR01 se edita sin tocar ese campo, la regla no corre en ese formulario. Para cubrir esos casos, se suma una validación al guardar: si la entidad legal es AR01 y el fin del período de prueba está vacío, un mensaje con severidad error. La propiedad ayuda al usuario mientras carga; la validación garantiza el dato.
La lección agrega un criterio que evita reglas innecesarias. Si una propiedad no depende de nada, va en el modelo de datos, no en una regla. Una regla agrega lógica que hay que mantener, probar en cada actualización y documentar. Si un campo tiene que estar oculto para todos, lo correcto es el atributo de visibilidad del modelo de datos.
Hay que tener presente, además, que las propiedades por regla afectan la interfaz, no los permisos. Ocultar un campo con una regla no reemplaza un permiso de campo en un rol: el dato sigue existiendo y puede verse por otros caminos, como un informe o una exportación. Si la razón para ocultar un dato es la confidencialidad, la herramienta correcta son los permisos basados en roles.
