(OFBIZ-7113)
As mentioned by Mathieu on dev ML uses rather a boolean than a token for
"require-new-transaction" and "return-error-on-failure"
Also some formatting while at it.
git-svn-id: https://svn.apache.org/repos/asf/ofbiz/ofbiz-framework/trunk@1866589 13f79535-47bb-0310-9956-ffa450edef68
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If set to true and there is a transaction already in place the Service Engine will suspend that transaction, begin a new one just for this service, commit or rollback the local transaction when the service is complete, and will resume the original transaction.
If set to true and there is no transaction already in place it will just begin a transaction and manage it as would be done for a normal user-transaction=true.
If use-transaction=false this setting is ignored.
Beware: using require-new-transaction=true in a service called (maybe not directly) by a pre-invoke or earlier event (preprocessor, firstvisit and so on) is not yet supported.
Beware: using require-new-transaction=true in a service called (maybe not directly) by a pre-invoke or earlier event (preprocessor, firstvisit and so on) is not yet supported.
<xs:annotation><xs:documentation>This will be used in error messages, et cetera. If not specified will default to a service name.</xs:documentation></xs:annotation>
<xs:annotation>
<xs:documentation>
This will be used in error messages, et cetera. If not specified will default to a service name.
If set to true and there is a transaction already in place the Service Engine will suspend that transaction, begin a new one just for this service, commit or rollback the local transaction when the service is complete, and will resume the original transaction.
If set to true and there is no transaction already in place it will just begin a transaction and manage it as would be done for a normal user-transaction=true.
If use-transaction=false this setting is ignored.
Beware: using require-new-transaction=true in a service called (maybe not directly) by a pre-invoke or earlier event (preprocessor, firstvisit and so on) is not yet supported.
<xs:annotation><xs:documentation>If set to false, when the permissions failed return the failMessage as error, else continue the service and give the hand to origin service to resolve the problem.</xs:documentation></xs:annotation>
<xs:annotation><xs:documentation>If set to true all attributes inherited will have be optional whether or not they were in the implemented service definition.</xs:documentation></xs:annotation>
<xs:attributename="optional"type="xs:boolean"
default="false">
<xs:annotation>
<xs:documentation>
If set to true all attributes inherited will have be optional whether or not they were in the implemented service definition.
Only checked for incoming parameters/attributes (could change in the future, but this is meant for validating input from users, other systems, etc).
Defaults to "none" meaning no HTML is allowed (will result in an error message).
If some HTML is desired then use "safe" which will follow the rules in the default custom safe policy file (CustomSafePolicy.java, see also owasp.properties).
This should be safe for both internal and public users. You may want to provide your own custom safe policy file to adapt to you needs.
In rare cases when users are trusted or it is not a sensitive field the "any" option may be used to not check the HTML content at all.
</xs:documentation></xs:annotation>
<xs:annotation>
<xs:documentation>
Applies only to String fields.
Only checked for incoming parameters/attributes (could change in the future, but this is meant for validating input from users, other systems, etc).
Defaults to "none" meaning no HTML is allowed (will result in an error message).
If some HTML is desired then use "safe" which will follow the rules in the default custom safe policy file (CustomSafePolicy.java, see also owasp.properties).
This should be safe for both internal and public users. You may want to provide your own custom safe policy file to adapt to you needs.
In rare cases when users are trusted or it is not a sensitive field the "any" option may be used to not check the HTML content at all.