Required properties

Metadata card configuration rules are run within the client (e.g. the Desktop client or Web client) and are not explicitly enforced by the server; i.e. you can still create an object via the API which is missing MDCC-"mandatory" properties.  Different clients have slightly different support for metadata card configuration rules.

If you are seeing mandatory properties on the metadata card (i.e. ones that have an asterisk) but you can save the metadata card, then this sounds like a bug.  If you are seeing objects that have been created in other ways (e.g. via the API) which are missing mandatory properties, then this is expected.  In this latter case, if you need to enforce these rules regardless of the client used, then you would need to enforce the logic using some server-side scripting (e.g. VAF).

Configuring the M-Files Metadata Card has a solution proposal for server-side check of required properties in workflows: "You must not use metadata card configurations for actual restrictions on metadata modifications because the configurations are effective at the user interface level only. For example, you can change the workflow state of an object with the Change State command without adding a required property value imposed by a configuration rule. Instead, use the workflow state preconditions or postconditions to make sure that certain property values are filled before state transitions occur."

But she didn't elaborate how the object is saved.. IMHO it reads like the user is on the Metadata Card, not filling out every mandatory field and still can save the Object.. This shouldn't be the case..

Hi, don't have a solution, but I would like to point out the possibility of overcoming metadata card configuration with multiple object selection. I described the issue here in this post:

 Safety warning for Group read-only setting in Metadata Card 

Haven't tried, but it might be possible to overcome the required rule with this too.