Known bug? Special variables with mandatory 

Known bug? Special variables with mandatory 

  
Is this a common known bug? When you use a combo list with special variables and set mandatory to true.

No matter if the special variable contains a value or not the platform will always flag an error, indicating the field has no value and requires an input value.

If I remember correctly this issue also occurs when you use an input widget with special variables and set mandatory to true.


Current Workaround solution: set mandatory to false, check within code if the special value contains a value or not (this defeats the purpose of setting the mandatory input to true)
This is not as much a bug, as it is a feature :). Mandatory means mandatory on the Variable. If you have only a Special Variable, the behaviour is what you experience.
I would consider it as a bug since Mandatory would mean the input, selection is mandatory, mandatory meaning it requires an input, regardless if it's a variable or a special variable? It can be fixed by outsystems but the question is was it done on purpose? What's mandatory referring to, not the users input?

Then the setting should say MandatoryForVariable then.

The setting more than suggests that the Combo selection is manadatory. Why because you are in a WYSIWYG and you have selected a control to work with, and that control has proporties, and one of the properties asks is it manadatory or not.

I am with Robert on this one and as a newbie this does not get implmented as you would expect from the property description in the WYSIWYG.
How outsystems platform should be behave: when an input widget is set to mandatory the expected input value is expected from the user (either when the developer uses local variable or special variable, it does not matter), mandatory means mandatory! otherwise it would be considered a bug.

The "Mandatory" property, describes mandatory as follows: "Expression defining the condition for the value to be mandatory." If you ask a developer (junior or senior, or hacker) straight away his going to think this mandatory property applies to the input widget value. Which it does, but it only affects the local variable and not special variable. How is he suppose to know about this? mandatory should  mean mandatory for both local and special variable. 

EDIT: I know how the mandatory property behaves but still don't think the current behaviour is right ...it's just very strange :( it's behaving in an unexpected way!
BUT one of the characteristics of generated code paradigm is that previous behaviours my not be expected but will have been coded for so it is difficult to initiate change to a behaviour without affecting previous work.

In my past experience I would say Robert has done a valuable service in highlighting the behaviour and it should be documented clearly so new entrants are made aware of the behaviour and previous code bases are not affected by a change in code generation. 

Maybe re-word the property label if it does not affect the code generation.

"BUT one of the characteristics of generated code paradigm is that previous behaviours my not be expected but will have been coded for so it is difficult to initiate change to a behaviour without affecting previous work."

If you were to use special variables in your application you would have to set 
mandatory property "false", therefore if outsystems was to correct the behaviour all previous application written prior to this fix would still function as it previously did. BUT even if the new change in behavior was to affect the previous behaviour it would be documented by outsystems as a breaking change - this happens (sometimes too).  

I believe this odd behaviour should be fixed. PLUS the new change providesa extra advantage as well, you dont have to write logic to force mandatory input values in your logic flow when you use a special variable,  setting 
mandatory to true behaves just as you would expect it to behave! - enforces mandatory conditions for specified input widget.

Famous last words of a software vendor "all previous application written prior to this fix would still function as it previously did" Take it easy and battle things Outsystem can help you with that are showstoppers, keep the powder dry. Thanks for highlighting the behaviour and I won't fall for its behaviour now because of you.