[jira] [Commented] (SYNCOPE-417) Users are made active when updating in NoOpWorkflowAdapter
[ https://issues.apache.org/jira/browse/SYNCOPE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13772847#comment-13772847 ] Francesco Chicchiriccò commented on SYNCOPE-417: Hi Jesse, this looks definitely correct: would you mind to provide a proper patch (some [guidelines|https://commons.apache.org/patches.html] are available, if needed). Users are made active when updating in NoOpWorkflowAdapter -- Key: SYNCOPE-417 URL: https://issues.apache.org/jira/browse/SYNCOPE-417 Project: Syncope Issue Type: Bug Components: core Affects Versions: 1.1.3 Reporter: Jesse van Bekkum Priority: Minor Fix For: 1.1.4, 1.2.0 When using the NoOpWorkflow adapter a user is always set to active when an update is done, even if the user is suspended. This is undesirable, I think a user should stay in the state it is. This can be fixed by changing this line (117/118 of NoOpWorkflowAdapter.java): return new WorkflowResultMap.EntryLong, Boolean( new AbstractMap.SimpleEntryLong, Boolean(updated.getId(), true), propByRes, update); into this: return new WorkflowResultMap.EntryLong, Boolean( new AbstractMap.SimpleEntryLong, Boolean(updated.getId(), !user.isSuspended()), propByRes, update); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SYNCOPE-417) Users are made active when updating in NoOpWorkflowAdapter
[ https://issues.apache.org/jira/browse/SYNCOPE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated SYNCOPE-417: --- Fix Version/s: 1.2.0 1.1.4 Users are made active when updating in NoOpWorkflowAdapter -- Key: SYNCOPE-417 URL: https://issues.apache.org/jira/browse/SYNCOPE-417 Project: Syncope Issue Type: Bug Components: core Affects Versions: 1.1.2 Reporter: Jesse van Bekkum Priority: Minor Fix For: 1.1.4, 1.2.0 When using the NoOpWorkflow adapter a user is always set to active when an update is done, even if the user is suspended. This is undesirable, I think a user should stay in the state it is. This can be fixed by changing this line (117/118 of NoOpWorkflowAdapter.java): return new WorkflowResultMap.EntryLong, Boolean( new AbstractMap.SimpleEntryLong, Boolean(updated.getId(), true), propByRes, update); into this: return new WorkflowResultMap.EntryLong, Boolean( new AbstractMap.SimpleEntryLong, Boolean(updated.getId(), !user.isSuspended()), propByRes, update); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SYNCOPE-417) Users are made active when updating in NoOpWorkflowAdapter
[ https://issues.apache.org/jira/browse/SYNCOPE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated SYNCOPE-417: --- Affects Version/s: (was: 1.1.2) 1.1.3 Users are made active when updating in NoOpWorkflowAdapter -- Key: SYNCOPE-417 URL: https://issues.apache.org/jira/browse/SYNCOPE-417 Project: Syncope Issue Type: Bug Components: core Affects Versions: 1.1.3 Reporter: Jesse van Bekkum Priority: Minor Fix For: 1.1.4, 1.2.0 When using the NoOpWorkflow adapter a user is always set to active when an update is done, even if the user is suspended. This is undesirable, I think a user should stay in the state it is. This can be fixed by changing this line (117/118 of NoOpWorkflowAdapter.java): return new WorkflowResultMap.EntryLong, Boolean( new AbstractMap.SimpleEntryLong, Boolean(updated.getId(), true), propByRes, update); into this: return new WorkflowResultMap.EntryLong, Boolean( new AbstractMap.SimpleEntryLong, Boolean(updated.getId(), !user.isSuspended()), propByRes, update); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SYNCOPE-417) Users are made active when updating in NoOpWorkflowAdapter
[ https://issues.apache.org/jira/browse/SYNCOPE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse van Bekkum updated SYNCOPE-417: - Attachment: NoOpUserWorkflowAdapter.java.patch Patch for this issue Users are made active when updating in NoOpWorkflowAdapter -- Key: SYNCOPE-417 URL: https://issues.apache.org/jira/browse/SYNCOPE-417 Project: Syncope Issue Type: Bug Components: core Affects Versions: 1.1.3 Reporter: Jesse van Bekkum Priority: Minor Fix For: 1.1.4, 1.2.0 Attachments: NoOpUserWorkflowAdapter.java.patch When using the NoOpWorkflow adapter a user is always set to active when an update is done, even if the user is suspended. This is undesirable, I think a user should stay in the state it is. This can be fixed by changing this line (117/118 of NoOpWorkflowAdapter.java): return new WorkflowResultMap.EntryLong, Boolean( new AbstractMap.SimpleEntryLong, Boolean(updated.getId(), true), propByRes, update); into this: return new WorkflowResultMap.EntryLong, Boolean( new AbstractMap.SimpleEntryLong, Boolean(updated.getId(), !user.isSuspended()), propByRes, update); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SYNCOPE-417) Users are made active when updating in NoOpWorkflowAdapter
[ https://issues.apache.org/jira/browse/SYNCOPE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò resolved SYNCOPE-417. Resolution: Fixed 1_1_X: http://svn.apache.org/r1524937 trunk: http://svn.apache.org/r1524938 Patch applied (better from source root directory, next time), thanks! Users are made active when updating in NoOpWorkflowAdapter -- Key: SYNCOPE-417 URL: https://issues.apache.org/jira/browse/SYNCOPE-417 Project: Syncope Issue Type: Bug Components: core Affects Versions: 1.1.3 Reporter: Jesse van Bekkum Assignee: Francesco Chicchiriccò Priority: Minor Fix For: 1.1.4, 1.2.0 Attachments: NoOpUserWorkflowAdapter.java.patch When using the NoOpWorkflow adapter a user is always set to active when an update is done, even if the user is suspended. This is undesirable, I think a user should stay in the state it is. This can be fixed by changing this line (117/118 of NoOpWorkflowAdapter.java): return new WorkflowResultMap.EntryLong, Boolean( new AbstractMap.SimpleEntryLong, Boolean(updated.getId(), true), propByRes, update); into this: return new WorkflowResultMap.EntryLong, Boolean( new AbstractMap.SimpleEntryLong, Boolean(updated.getId(), !user.isSuspended()), propByRes, update); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-417) Users are made active when updating in NoOpWorkflowAdapter
[ https://issues.apache.org/jira/browse/SYNCOPE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13772881#comment-13772881 ] Hudson commented on SYNCOPE-417: SUCCESS: Integrated in Syncope-1_1_X #110 (See [https://builds.apache.org/job/Syncope-1_1_X/110/]) [SYNCOPE-417] Applying provided patch (ilgrosso: rev 1524937) * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/workflow/user/NoOpUserWorkflowAdapter.java Users are made active when updating in NoOpWorkflowAdapter -- Key: SYNCOPE-417 URL: https://issues.apache.org/jira/browse/SYNCOPE-417 Project: Syncope Issue Type: Bug Components: core Affects Versions: 1.1.3 Reporter: Jesse van Bekkum Assignee: Francesco Chicchiriccò Priority: Minor Fix For: 1.1.4, 1.2.0 Attachments: NoOpUserWorkflowAdapter.java.patch When using the NoOpWorkflow adapter a user is always set to active when an update is done, even if the user is suspended. This is undesirable, I think a user should stay in the state it is. This can be fixed by changing this line (117/118 of NoOpWorkflowAdapter.java): return new WorkflowResultMap.EntryLong, Boolean( new AbstractMap.SimpleEntryLong, Boolean(updated.getId(), true), propByRes, update); into this: return new WorkflowResultMap.EntryLong, Boolean( new AbstractMap.SimpleEntryLong, Boolean(updated.getId(), !user.isSuspended()), propByRes, update); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-417) Users are made active when updating in NoOpWorkflowAdapter
[ https://issues.apache.org/jira/browse/SYNCOPE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13772888#comment-13772888 ] Hudson commented on SYNCOPE-417: SUCCESS: Integrated in Syncope-trunk #451 (See [https://builds.apache.org/job/Syncope-trunk/451/]) [SYNCOPE-417] Merge from 1_1_X (ilgrosso: rev 1524938) * /syncope/trunk * /syncope/trunk/core/src/main/java/org/apache/syncope/core/workflow/user/NoOpUserWorkflowAdapter.java Users are made active when updating in NoOpWorkflowAdapter -- Key: SYNCOPE-417 URL: https://issues.apache.org/jira/browse/SYNCOPE-417 Project: Syncope Issue Type: Bug Components: core Affects Versions: 1.1.3 Reporter: Jesse van Bekkum Assignee: Francesco Chicchiriccò Priority: Minor Fix For: 1.1.4, 1.2.0 Attachments: NoOpUserWorkflowAdapter.java.patch When using the NoOpWorkflow adapter a user is always set to active when an update is done, even if the user is suspended. This is undesirable, I think a user should stay in the state it is. This can be fixed by changing this line (117/118 of NoOpWorkflowAdapter.java): return new WorkflowResultMap.EntryLong, Boolean( new AbstractMap.SimpleEntryLong, Boolean(updated.getId(), true), propByRes, update); into this: return new WorkflowResultMap.EntryLong, Boolean( new AbstractMap.SimpleEntryLong, Boolean(updated.getId(), !user.isSuspended()), propByRes, update); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SYNCOPE-418) Special chars break REST URLs
Francesco Chicchiriccò created SYNCOPE-418: -- Summary: Special chars break REST URLs Key: SYNCOPE-418 URL: https://issues.apache.org/jira/browse/SYNCOPE-418 Project: Syncope Issue Type: Bug Components: core Affects Versions: 1.1.3 Reporter: Francesco Chicchiriccò Assignee: Francesco Chicchiriccò Fix For: 1.1.4, 1.2.0 Some entities have String keys that are currently accepted without any specific bound (schema, resources, config parameters). When, for example, a value like as an URL is provided, nothing special happens during creation (because such value is embedded into a transfer object); however, any subsequent read or delete, which would require passing the entity key as part of the REST URL, will fail either with Spring MVC and CXF. For example, as [reported in mailing list|http://syncope-user.1051894.n5.nabble.com/Remove-attribute-in-user-schema-td5707312.html], a user schema with name 'http://schemas.examples.org/security/authorization/organizationUnit' can be created but will then be impossible to read or even delete since the REST URL would be something like as http://localhost:9080syncope/rest/schema/USER/read/http://schemas.examples.org/security/authorization/organizationUnit After some search, it seems that it is neither Spring MVC nor CXF problem, but instead the JEE container (like as Tomcat, for example) that needs some special configuration for handling such URLs (see CXF-4207 for more details). The most logical and straightforward solution seems to be just setting some limits for the characters admitted; at a first glance, alphanumeric plus some special characters (space, _, -, @, .) should be fine. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SYNCOPE-418) Special chars break REST URLs
[ https://issues.apache.org/jira/browse/SYNCOPE-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated SYNCOPE-418: --- Description: Some entities have String keys that are currently accepted without any specific bound (schema, resources, config parameters). When, for example, a value like as an URL is provided, nothing special happens during creation (because such value is embedded into a transfer object); however, any subsequent read or delete, which would require passing the entity key as part of the REST URL, will fail either with Spring MVC and CXF. For example, as reported in mailing list [1], a user schema with name 'http://schemas.examples.org/security/authorization/organizationUnit' can be created but will then be impossible to read or even delete since the REST URL would be something like as http://localhost:9080syncope/rest/schema/USER/read/http://schemas.examples.org/security/authorization/organizationUnit After some search, it seems that it is neither Spring MVC nor CXF problem, but instead the JEE container (like as Tomcat, for example) that needs some special configuration for handling such URLs (see CXF-4207 for more details). The most logical and straightforward solution seems to be just setting some limits for the characters admitted; at a first glance, alphanumeric plus some special characters (space, _, -, @, .) should be fine. [1] http://syncope-user.1051894.n5.nabble.com/Remove-attribute-in-user-schema-td5707312.html was: Some entities have String keys that are currently accepted without any specific bound (schema, resources, config parameters). When, for example, a value like as an URL is provided, nothing special happens during creation (because such value is embedded into a transfer object); however, any subsequent read or delete, which would require passing the entity key as part of the REST URL, will fail either with Spring MVC and CXF. For example, as [reported in mailing list|http://syncope-user.1051894.n5.nabble.com/Remove-attribute-in-user-schema-td5707312.html], a user schema with name 'http://schemas.examples.org/security/authorization/organizationUnit' can be created but will then be impossible to read or even delete since the REST URL would be something like as http://localhost:9080syncope/rest/schema/USER/read/http://schemas.examples.org/security/authorization/organizationUnit After some search, it seems that it is neither Spring MVC nor CXF problem, but instead the JEE container (like as Tomcat, for example) that needs some special configuration for handling such URLs (see CXF-4207 for more details). The most logical and straightforward solution seems to be just setting some limits for the characters admitted; at a first glance, alphanumeric plus some special characters (space, _, -, @, .) should be fine. Special chars break REST URLs - Key: SYNCOPE-418 URL: https://issues.apache.org/jira/browse/SYNCOPE-418 Project: Syncope Issue Type: Bug Components: core Affects Versions: 1.1.3 Reporter: Francesco Chicchiriccò Assignee: Francesco Chicchiriccò Fix For: 1.1.4, 1.2.0 Some entities have String keys that are currently accepted without any specific bound (schema, resources, config parameters). When, for example, a value like as an URL is provided, nothing special happens during creation (because such value is embedded into a transfer object); however, any subsequent read or delete, which would require passing the entity key as part of the REST URL, will fail either with Spring MVC and CXF. For example, as reported in mailing list [1], a user schema with name 'http://schemas.examples.org/security/authorization/organizationUnit' can be created but will then be impossible to read or even delete since the REST URL would be something like as http://localhost:9080syncope/rest/schema/USER/read/http://schemas.examples.org/security/authorization/organizationUnit After some search, it seems that it is neither Spring MVC nor CXF problem, but instead the JEE container (like as Tomcat, for example) that needs some special configuration for handling such URLs (see CXF-4207 for more details). The most logical and straightforward solution seems to be just setting some limits for the characters admitted; at a first glance, alphanumeric plus some special characters (space, _, -, @, .) should be fine. [1] http://syncope-user.1051894.n5.nabble.com/Remove-attribute-in-user-schema-td5707312.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[Errored] apache/syncope#245 (1_1_X - c6c700b)
Build Update for apache/syncope - Build: #245 Status: Errored Duration: 9 minutes and 53 seconds Commit: c6c700b (1_1_X) Author: Francesco Chicchiriccò Message: [SYNCOPE-418] Enforcing name constraints for any schema, resource and configuration git-svn-id: https://svn.apache.org/repos/asf/syncope/branches/1_1_X@1524988 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/syncope/compare/1c16ba8d9d7f...c6c700b8a60d View the full build log and details: https://travis-ci.org/apache/syncope/builds/11592683 -- You can configure recipients for build notifications in your .travis.yml file. See http://about.travis-ci.org/docs/user/build-configuration
[Passed] apache/syncope#246 (1_1_X - 3142aea)
Build Update for apache/syncope - Build: #246 Status: Passed Duration: 17 minutes and 39 seconds Commit: 3142aea (1_1_X) Author: Francesco Chicchiriccò Message: [SYNCOPE-418] Now working with JDK 6 as well... git-svn-id: https://svn.apache.org/repos/asf/syncope/branches/1_1_X@1524998 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/syncope/compare/c6c700b8a60d...3142aeac351c View the full build log and details: https://travis-ci.org/apache/syncope/builds/11593290 -- You can configure recipients for build notifications in your .travis.yml file. See http://about.travis-ci.org/docs/user/build-configuration
[jira] [Assigned] (SYNCOPE-131) Assign membership and role schemas to either all memberships / roles or only some memberships / roles
[ https://issues.apache.org/jira/browse/SYNCOPE-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò reassigned SYNCOPE-131: -- Assignee: Francesco Chicchiriccò Assign membership and role schemas to either all memberships / roles or only some memberships / roles - Key: SYNCOPE-131 URL: https://issues.apache.org/jira/browse/SYNCOPE-131 Project: Syncope Issue Type: Improvement Reporter: Francesco Chicchiriccò Assignee: Francesco Chicchiriccò Fix For: 1.2.0 Currently, membership and role schemas are defined for all memberships / roles. This means that when defining a mandatory role schema, all roles must provide a value for the corresponding attribute. Same applies for memberships. This mechanism should be extended so that you can choose which schemas are associated to each role / membership, in order to give more flexibility. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-418) Special chars break REST URLs
[
https://issues.apache.org/jira/browse/SYNCOPE-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13773025#comment-13773025
]
Sergey Beryozkin commented on SYNCOPE-418:
--
Hi
JAX-RS UriInfo UriBuilder may also help. It is as simple as
uriBuilder.path({var}).build(getValue(), true);
Cheers, Sergey
[1]
https://jax-rs-spec.java.net/nonav/2.0/apidocs/javax/ws/rs/core/UriBuilder.html
[2]
https://jax-rs-spec.java.net/nonav/2.0/apidocs/javax/ws/rs/core/UriBuilder.html#build(java.lang.Object[],%20boolean)
Special chars break REST URLs
-
Key: SYNCOPE-418
URL: https://issues.apache.org/jira/browse/SYNCOPE-418
Project: Syncope
Issue Type: Bug
Components: core
Affects Versions: 1.1.3
Reporter: Francesco Chicchiriccò
Assignee: Francesco Chicchiriccò
Fix For: 1.1.4, 1.2.0
Some entities have String keys that are currently accepted without any
specific bound (schema, resources, config parameters).
When, for example, a value like as an URL is provided, nothing special
happens during creation (because such value is embedded into a transfer
object); however, any subsequent read or delete, which would require passing
the entity key as part of the REST URL, will fail either with Spring MVC and
CXF.
For example, as reported in mailing list [1], a user schema with name
'http://schemas.examples.org/security/authorization/organizationUnit' can be
created but will then be impossible to read or even delete since the REST URL
would be something like as
http://localhost:9080syncope/rest/schema/USER/read/http://schemas.examples.org/security/authorization/organizationUnit
After some search, it seems that it is neither Spring MVC nor CXF problem,
but instead the JEE container (like as Tomcat, for example) that needs some
special configuration for handling such URLs (see CXF-4207 for more details).
The most logical and straightforward solution seems to be just setting some
limits for the characters admitted; at a first glance, alphanumeric plus some
special characters (space, _, -, @, .) should be fine.
[1]
http://syncope-user.1051894.n5.nabble.com/Remove-attribute-in-user-schema-td5707312.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (SYNCOPE-418) Special chars break REST URLs
[
https://issues.apache.org/jira/browse/SYNCOPE-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13773025#comment-13773025
]
Sergey Beryozkin edited comment on SYNCOPE-418 at 9/20/13 2:11 PM:
---
Hi
JAX-RS UriInfo UriBuilder may also help. It is as simple as
{code:java}
uriBuilder.path({var}).build(getValue(), true);
{code}
Cheers, Sergey
[1]
https://jax-rs-spec.java.net/nonav/2.0/apidocs/javax/ws/rs/core/UriBuilder.html
[2]
https://jax-rs-spec.java.net/nonav/2.0/apidocs/javax/ws/rs/core/UriBuilder.html#build(java.lang.Object[],%20boolean)
was (Author: sergey_beryozkin):
Hi
JAX-RS UriInfo UriBuilder may also help. It is as simple as
uriBuilder.path({var}).build(getValue(), true);
Cheers, Sergey
[1]
https://jax-rs-spec.java.net/nonav/2.0/apidocs/javax/ws/rs/core/UriBuilder.html
[2]
https://jax-rs-spec.java.net/nonav/2.0/apidocs/javax/ws/rs/core/UriBuilder.html#build(java.lang.Object[],%20boolean)
Special chars break REST URLs
-
Key: SYNCOPE-418
URL: https://issues.apache.org/jira/browse/SYNCOPE-418
Project: Syncope
Issue Type: Bug
Components: core
Affects Versions: 1.1.3
Reporter: Francesco Chicchiriccò
Assignee: Francesco Chicchiriccò
Fix For: 1.1.4, 1.2.0
Some entities have String keys that are currently accepted without any
specific bound (schema, resources, config parameters).
When, for example, a value like as an URL is provided, nothing special
happens during creation (because such value is embedded into a transfer
object); however, any subsequent read or delete, which would require passing
the entity key as part of the REST URL, will fail either with Spring MVC and
CXF.
For example, as reported in mailing list [1], a user schema with name
'http://schemas.examples.org/security/authorization/organizationUnit' can be
created but will then be impossible to read or even delete since the REST URL
would be something like as
http://localhost:9080syncope/rest/schema/USER/read/http://schemas.examples.org/security/authorization/organizationUnit
After some search, it seems that it is neither Spring MVC nor CXF problem,
but instead the JEE container (like as Tomcat, for example) that needs some
special configuration for handling such URLs (see CXF-4207 for more details).
The most logical and straightforward solution seems to be just setting some
limits for the characters admitted; at a first glance, alphanumeric plus some
special characters (space, _, -, @, .) should be fine.
[1]
http://syncope-user.1051894.n5.nabble.com/Remove-attribute-in-user-schema-td5707312.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-418) Special chars break REST URLs
[ https://issues.apache.org/jira/browse/SYNCOPE-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13773046#comment-13773046 ] Hudson commented on SYNCOPE-418: SUCCESS: Integrated in Syncope-trunk #452 (See [https://builds.apache.org/job/Syncope-trunk/452/]) [SYNCOPE-418] Merge from 1_1_X (ilgrosso: rev 1525004) * /syncope/trunk * /syncope/trunk/common/src/main/java/org/apache/syncope/common/types/EntityViolationType.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/types/SyncopeClientExceptionType.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/beans/AbstractDerSchema.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/beans/AbstractSchema.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/beans/AbstractVirSchema.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/beans/SyncopeConf.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/beans/user/UDerSchema.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/beans/user/USchema.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/beans/user/UVirSchema.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/attrvalue/EmailAddressValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/AbstractValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/AttrValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/AttrValueValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/ConnInstanceValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/ExternalResourceValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/NotificationValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/PolicyValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/PropagationTaskValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/ReportValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SchedTaskValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SchemaNameCheck.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SchemaNameValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SchemaValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SyncTaskValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SyncopeConfCheck.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SyncopeConfValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SyncopeRoleValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SyncopeUserValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/USchemaCheck.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/USchemaValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/data/SchemaDataBinder.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/persistence/dao/AttrTest.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/persistence/dao/ConfTest.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/persistence/dao/DerSchemaTest.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/persistence/dao/ResourceTest.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/persistence/dao/SchemaTest.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/persistence/dao/VirSchemaTest.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/ConfigurationTestITCase.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/DerivedSchemaTestITCase.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/ResourceTestITCase.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/SchemaTestITCase.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/VirtualSchemaTestITCase.java Special chars break REST URLs - Key: SYNCOPE-418 URL:
