Property constraint violation error

Problem:

While customizing the "name" field , have you come across a error "Property constraint violation" on the empty name field?

You have written your own error messages in the "typesystem" aspect, but still this error message takes precedence and takes all attention? 

What is a Name Property?

Name Property is the most used variable while developing with MPS. MPS provides a Interface called INamedConcept or IValidNamedConcept and some more similar interfaces which implements the "name" property with well defined behaviour.

These comes very handy and all we have to do is to define a concept, allow the concept, implementing any of the interface which implemented name property and thats it. Its a plug and play to use the name and its associated validations.

But there are times where we want to customize name behavior keeping some of the existing features intact. So we implement the inbuilt interface and also we would override some validations which we want to customize.

While this error is being faced, you could also face some inconsistencies in the empty validations and also some annoying behavior while trying to delete the name value.

Troubleshooting:

Check if any of the concept used in the concept-in-focus causing error, or one of its superconcepts has already implemented some interface which implemented 'name'

If you have recently migrated from 2019.1 to further MPS versions and if you have your concept extending "Chunk" concept, then you could see here that Chunk implemented IIdentifierNamedConcept and which in turn implemented INamedConcept, which will have set of constraint rule for the name property. 

These rules are inherited and that is why you see "Property constraint violation error" despite having your own custom error message. But you can override them in your concept.

In any of the above case, all you have to do is, create a "constraint" aspect for your concept and create a "Property constraint rule" like below

Sometimes even this may not resolve the issue for you. Because <always> might actually mean <inherited from superconcept>. So MPS will look for a explicit "return true" in this case. 

Thus setting the rule like above, will allow you to do the customization of existing properties the way you require and not inhering from the superconcept's implementation, thus eliminating the error.