[jira] [Assigned] (SYNCOPE-294) User data not refreshed before edit
[ https://issues.apache.org/jira/browse/SYNCOPE-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò reassigned SYNCOPE-294: -- Assignee: Francesco Chicchiriccò User data not refreshed before edit --- Key: SYNCOPE-294 URL: https://issues.apache.org/jira/browse/SYNCOPE-294 Project: Syncope Issue Type: Bug Components: console Affects Versions: 1.0.5 Reporter: Francesco Chicchiriccò Assignee: Francesco Chicchiriccò Priority: Minor Fix For: 1.0.6, 1.1.0 As reported in ML [1] the user data are not refreshed before loading into edit modal page. Does the same apply to other entities, mainly roles? [1] http://syncope-dev.1063484.n5.nabble.com/Console-update-issue-tt5712329.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-294) User data not refreshed before edit
[ https://issues.apache.org/jira/browse/SYNCOPE-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13568599#comment-13568599 ] Francesco Chicchiriccò commented on SYNCOPE-294: For trunk: http://svn.apache.org/viewvc?rev=1441361view=rev User data not refreshed before edit --- Key: SYNCOPE-294 URL: https://issues.apache.org/jira/browse/SYNCOPE-294 Project: Syncope Issue Type: Bug Components: console Affects Versions: 1.0.5 Reporter: Francesco Chicchiriccò Assignee: Francesco Chicchiriccò Priority: Minor Fix For: 1.0.6, 1.1.0 As reported in ML [1] the user data are not refreshed before loading into edit modal page. Does the same apply to other entities, mainly roles? [1] http://syncope-dev.1063484.n5.nabble.com/Console-update-issue-tt5712329.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] [Resolved] (SYNCOPE-294) User data not refreshed before edit
[ https://issues.apache.org/jira/browse/SYNCOPE-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò resolved SYNCOPE-294. Resolution: Fixed For branch 1_0_X: http://svn.apache.org/viewvc?rev=1441364view=rev User data not refreshed before edit --- Key: SYNCOPE-294 URL: https://issues.apache.org/jira/browse/SYNCOPE-294 Project: Syncope Issue Type: Bug Components: console Affects Versions: 1.0.5 Reporter: Francesco Chicchiriccò Assignee: Francesco Chicchiriccò Priority: Minor Fix For: 1.0.6, 1.1.0 As reported in ML [1] the user data are not refreshed before loading into edit modal page. Does the same apply to other entities, mainly roles? [1] http://syncope-dev.1063484.n5.nabble.com/Console-update-issue-tt5712329.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-136) Password required for resource subscription
[ https://issues.apache.org/jira/browse/SYNCOPE-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13568641#comment-13568641 ] Francesco Chicchiriccò commented on SYNCOPE-136: What I am going to implement: If password is not provided during resource subscription (e.g. when create() is performed on the underlying connector): * if AES is configured for user passwords, decrypt and use * if the propagating resource is configured for random password generation, generate using PasswordGenerator from SYNCOPE-121 and use * if none of the above, raise exception (as currently doing) Additionally, for SyncTask, behind the current possibility to specify a JEXL expression for user template's password (to be used when creating users upon synchronization), random password generation will be also available as configuration option. Password required for resource subscription --- Key: SYNCOPE-136 URL: https://issues.apache.org/jira/browse/SYNCOPE-136 Project: Syncope Issue Type: Improvement Reporter: Francesco Chicchiriccò Assignee: Francesco Chicchiriccò Fix For: 1.1.0 Currently, cleartext password is always required when subscribing to a new external resource. However, in some cases (for example when passwords are stored with some symmetric algorithm) this can be avoided. For example, it could be: Case 1: 2-way (a.k.a. symmetric) password cipher algorithm is configured in Syncope Use decrypted password from SyncopeUser to subscribe new resource. Case 2: 1-way (a.k.a. hash or asymmetric) password cipher algorithm is configured in Syncope and no clear-text password is available (for example, passed via UserMod or provided by a synchronizing resource) Provide, on a resource-basis, a mean to configure how new password should be generated: * constant * random password generation (compliant with resource password policy, if present - see SYNCOPE-121) * provide custom Java class Discussion thread: http://syncope-dev.1063484.n5.nabble.com/new-password-issue-td5589622.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
Syncope-1_0_X - Build # 127 - Unstable
The Apache Jenkins build system has built Syncope-1_0_X (build #127) Status: Unstable Check console output at https://builds.apache.org/job/Syncope-1_0_X/127/ to view the results.
[jira] [Commented] (SYNCOPE-294) User data not refreshed before edit
[ https://issues.apache.org/jira/browse/SYNCOPE-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13568642#comment-13568642 ] Hudson commented on SYNCOPE-294: Integrated in Syncope-1_0_X #127 (See [https://builds.apache.org/job/Syncope-1_0_X/127/]) [SYNCOPE-294] UserTO re-read from REST before opening the edit modal page (Revision 1441364) Result = UNSTABLE ilgrosso : Files : * /syncope/branches/1_0_X/console/src/main/java/org/apache/syncope/console/pages/EditUserModalPage.java * /syncope/branches/1_0_X/console/src/main/java/org/apache/syncope/console/pages/ResourceModalPage.java * /syncope/branches/1_0_X/console/src/main/java/org/apache/syncope/console/pages/panels/ResultSetPanel.java * /syncope/branches/1_0_X/console/src/main/resources/org/apache/syncope/console/pages/ResourceModalPage.html * /syncope/branches/1_0_X/console/src/main/resources/org/apache/syncope/console/pages/ResourceModalPage.properties * /syncope/branches/1_0_X/console/src/main/resources/org/apache/syncope/console/pages/ResourceModalPage_it.properties User data not refreshed before edit --- Key: SYNCOPE-294 URL: https://issues.apache.org/jira/browse/SYNCOPE-294 Project: Syncope Issue Type: Bug Components: console Affects Versions: 1.0.5 Reporter: Francesco Chicchiriccò Assignee: Francesco Chicchiriccò Priority: Minor Fix For: 1.0.6, 1.1.0 As reported in ML [1] the user data are not refreshed before loading into edit modal page. Does the same apply to other entities, mainly roles? [1] http://syncope-dev.1063484.n5.nabble.com/Console-update-issue-tt5712329.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
Syncope-trunk - Build # 52 - Unstable
The Apache Jenkins build system has built Syncope-trunk (build #52) Status: Unstable Check console output at https://builds.apache.org/job/Syncope-trunk/52/ to view the results.
[jira] [Commented] (SYNCOPE-294) User data not refreshed before edit
[ https://issues.apache.org/jira/browse/SYNCOPE-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13568643#comment-13568643 ] Hudson commented on SYNCOPE-294: Integrated in Syncope-trunk #52 (See [https://builds.apache.org/job/Syncope-trunk/52/]) [SYNCOPE-294] UserTO re-read from REST before opening the edit modal page (Revision 1441361) Result = UNSTABLE ilgrosso : Files : * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/ResourceModalPage.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/panels/UserSearchResultPanel.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/rest/AbstractAttributableRestClient.java * /syncope/trunk/console/src/main/resources/org/apache/syncope/console/pages/ResourceModalPage.html * /syncope/trunk/console/src/main/resources/org/apache/syncope/console/pages/ResourceModalPage.properties * /syncope/trunk/console/src/main/resources/org/apache/syncope/console/pages/ResourceModalPage_it.properties User data not refreshed before edit --- Key: SYNCOPE-294 URL: https://issues.apache.org/jira/browse/SYNCOPE-294 Project: Syncope Issue Type: Bug Components: console Affects Versions: 1.0.5 Reporter: Francesco Chicchiriccò Assignee: Francesco Chicchiriccò Priority: Minor Fix For: 1.0.6, 1.1.0 As reported in ML [1] the user data are not refreshed before loading into edit modal page. Does the same apply to other entities, mainly roles? [1] http://syncope-dev.1063484.n5.nabble.com/Console-update-issue-tt5712329.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
Syncope-trunk - Build # 53 - Fixed
The Apache Jenkins build system has built Syncope-trunk (build #53) Status: Fixed Check console output at https://builds.apache.org/job/Syncope-trunk/53/ to view the results.
[jira] [Commented] (SYNCOPE-294) User data not refreshed before edit
[ https://issues.apache.org/jira/browse/SYNCOPE-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13568652#comment-13568652 ] Francesco Chicchiriccò commented on SYNCOPE-294: Build fixed without code modifications: * 1_0_X https://builds.apache.org/job/Syncope-1_0_X/128/ * trunk https://builds.apache.org/job/Syncope-trunk/53/ User data not refreshed before edit --- Key: SYNCOPE-294 URL: https://issues.apache.org/jira/browse/SYNCOPE-294 Project: Syncope Issue Type: Bug Components: console Affects Versions: 1.0.5 Reporter: Francesco Chicchiriccò Assignee: Francesco Chicchiriccò Priority: Minor Fix For: 1.0.6, 1.1.0 As reported in ML [1] the user data are not refreshed before loading into edit modal page. Does the same apply to other entities, mainly roles? [1] http://syncope-dev.1063484.n5.nabble.com/Console-update-issue-tt5712329.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] [Created] (SYNCOPE-306) 'Mandatory' error in Console when propagating Virtual Attributes
Colm O hEigeartaigh created SYNCOPE-306: --- Summary: 'Mandatory' error in Console when propagating Virtual Attributes Key: SYNCOPE-306 URL: https://issues.apache.org/jira/browse/SYNCOPE-306 Project: Syncope Issue Type: Bug Reporter: Colm O hEigeartaigh Fix For: 1.1.0 I've run into an Error with a Mandatory User Mapping in the Console. Steps to reproduce: a) Create a new Resource (to a H2 backend) with Enforce Mandatory Conditions checked. b) Create User Mappings for Username/Password + a virtual attribute which is true for Mandatory c) Try to create a new user with a Virtual Attribute Value. You get an error saying that the Virtual Attribute is required. If I go back to the Resource + make the Virtual Attribute mapping non-Mandatory, and then create a User, it propagates correctly (including the Virtual Attribute value). -- 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-306) 'Mandatory' error in Console when propagating Virtual Attributes
[ https://issues.apache.org/jira/browse/SYNCOPE-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13568663#comment-13568663 ] Francesco Chicchiriccò commented on SYNCOPE-306: I don't think this is a bug on the console. 'Mandatory' error in Console when propagating Virtual Attributes Key: SYNCOPE-306 URL: https://issues.apache.org/jira/browse/SYNCOPE-306 Project: Syncope Issue Type: Bug Reporter: Colm O hEigeartaigh Fix For: 1.1.0 I've run into an Error with a Mandatory User Mapping in the Console. Steps to reproduce: a) Create a new Resource (to a H2 backend) with Enforce Mandatory Conditions checked. b) Create User Mappings for Username/Password + a virtual attribute which is true for Mandatory c) Try to create a new user with a Virtual Attribute Value. You get an error saying that the Virtual Attribute is required. If I go back to the Resource + make the Virtual Attribute mapping non-Mandatory, and then create a User, it propagates correctly (including the Virtual Attribute value). -- 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-306) 'Mandatory' error in Console when propagating Virtual Attributes
[ https://issues.apache.org/jira/browse/SYNCOPE-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13568663#comment-13568663 ] Francesco Chicchiriccò edited comment on SYNCOPE-306 at 2/1/13 10:59 AM: - I don't think this is a bug on the console but rather on the core. was (Author: ilgrosso): I don't think this is a bug on the console. 'Mandatory' error in Console when propagating Virtual Attributes Key: SYNCOPE-306 URL: https://issues.apache.org/jira/browse/SYNCOPE-306 Project: Syncope Issue Type: Bug Reporter: Colm O hEigeartaigh Fix For: 1.1.0 I've run into an Error with a Mandatory User Mapping in the Console. Steps to reproduce: a) Create a new Resource (to a H2 backend) with Enforce Mandatory Conditions checked. b) Create User Mappings for Username/Password + a virtual attribute which is true for Mandatory c) Try to create a new user with a Virtual Attribute Value. You get an error saying that the Virtual Attribute is required. If I go back to the Resource + make the Virtual Attribute mapping non-Mandatory, and then create a User, it propagates correctly (including the Virtual Attribute value). -- 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
Re: Discuss: Move InvalidSearchConditionException to common
On 30/01/2013 13:25, Christian Schneider wrote: Hi Francesco, I am currently working on the patch to move the InvalidSearchConditionException and make it checked again. I am not sure if making it checked is a good idea. As the exception will now be part of the service interface I will have to add it to lots of methods. None of these methods really handles this exception. The reason for this is that before we used the RestTemplate to access the services. So it did not matter if the service throws a checked exception. We would not be forced to catch it. Now with the interfaces for the services we have to add the checked exception to the service interface if we want the impl to be able to throw it. So the client is also affected by that. Clear. In the end the exception now also appears in AttributableDataProvider which can not rethrow the exception as it would violate the IDataProvider interface. So I would have to catch it there but I have no idea what to do if it happens. As said before, this should never happen on the admin console since the wrapper is architected to generate only valid conditions and to check for correctness; anyway, the catch() block should only be able to log and report this error to the user. I created a gist of the patch so you can have a look: https://gist.github.com/4672932 So I see two possible solutions to improve this: 1) Make the exception unchecked again so it can be thrown by the services but has no effect on the client side 2) Catch the exception in the server impls and rethrow it as a RuntimeException so it does not affect the clients If the admin console is the only problem, we can easily find a fix there. If you still think having this checked is too much problematic for you, just leave it unchecked. Regards. On 30.01.2013 08:29, Francesco Chicchiriccò wrote: On 28/01/2013 15:38, Francesco Chicchiriccò wrote: On 28/01/2013 15:36, Christian Schneider wrote: Currently InvalidSearchConditionException is in core.persistence.dao and is a checked exception. If we want to make this exception part of the UserService interface to have it available on the client we will have to move it to common. Currently the console does not seem to use the exception on the client side. So my preliminary solution to get it running is to make the exception unchecked so I can pass it to the exception mapper without having it in the interface. So basically the two things to discuss are if we want to move the exception to common and if we want to make it unchecked. I personally would do both. This exception is not used by the admin console because the code is done so that no invalid search conditions are sent to the core; however, other clients are likely to need this exception to be returned. Hence: +1 for moving it to common, but don't see enough reason to make it unchecked. I've noticed that this issue was moved to common as unchecked: any additional reason behind not leaving it checked than the need to change some interface method's signature? Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[jira] [Commented] (SYNCOPE-305) Can't create Sync or Sched Task in Console
[ https://issues.apache.org/jira/browse/SYNCOPE-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13568672#comment-13568672 ] Massimiliano Perrone commented on SYNCOPE-305: -- This is due to the following statement, used in TaskRestClient.createSyncTask and TaskRestClient.createSchedTask. Long id = Long.valueOf(response.getHeaderString(SyncopeConstants.REST_HEADER_ID)); Moreover, it seems that this REST_HEADER_ID is only used in the two methods mentioned above: why? Can't create Sync or Sched Task in Console -- Key: SYNCOPE-305 URL: https://issues.apache.org/jira/browse/SYNCOPE-305 Project: Syncope Issue Type: Bug Reporter: Colm O hEigeartaigh Fix For: 1.1.0 I can't create either a Sync or Sched Task in the Console at the moment. Steps to reproduce: 1) Create a new project + just launch Syncope in embedded mode using the test configuration 2) Create a new Sync Task with one of the predefined Resources. You'll see a Wicket Error. In Console.log I see: Caused by: java.lang.NumberFormatException: null at java.lang.Long.parseLong(Long.java:375) ~[na:1.6.0_35] at java.lang.Long.valueOf(Long.java:525) ~[na:1.6.0_35] at org.apache.syncope.console.rest.TaskRestClient.createSyncTask(TaskRestClient.java:175) ~[TaskRestClient.class:na] -- 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
RE: [jira] [Commented] (SYNCOPE-305) Can't create Sync or Sched Task in Console
I'm out for lunch. After I'm back, I will take car for this issue! Best regards. Jan -Original Message- From: Massimiliano Perrone (JIRA) [mailto:j...@apache.org] Sent: Freitag, 1. Februar 2013 12:21 To: dev@syncope.apache.org Subject: [jira] [Commented] (SYNCOPE-305) Can't create Sync or Sched Task in Console [ https://issues.apache.org/jira/browse/SYNCOPE- 305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment- tabpanelfocusedCommentId=13568672#comment-13568672 ] Massimiliano Perrone commented on SYNCOPE-305: -- This is due to the following statement, used in TaskRestClient.createSyncTask and TaskRestClient.createSchedTask. Long id = Long.valueOf(response.getHeaderString(SyncopeConstants.REST_HEADER_I D)); Moreover, it seems that this REST_HEADER_ID is only used in the two methods mentioned above: why? Can't create Sync or Sched Task in Console -- Key: SYNCOPE-305 URL: https://issues.apache.org/jira/browse/SYNCOPE-305 Project: Syncope Issue Type: Bug Reporter: Colm O hEigeartaigh Fix For: 1.1.0 I can't create either a Sync or Sched Task in the Console at the moment. Steps to reproduce: 1) Create a new project + just launch Syncope in embedded mode using the test configuration 2) Create a new Sync Task with one of the predefined Resources. You'll see a Wicket Error. In Console.log I see: Caused by: java.lang.NumberFormatException: null at java.lang.Long.parseLong(Long.java:375) ~[na:1.6.0_35] at java.lang.Long.valueOf(Long.java:525) ~[na:1.6.0_35] at org.apache.syncope.console.rest.TaskRestClient.createSyncTask(TaskRest Client.java:175) ~[TaskRestClient.class:na] -- 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-305) Can't create Sync or Sched Task in Console
[ https://issues.apache.org/jira/browse/SYNCOPE-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13568675#comment-13568675 ] Jan Bernhardt commented on SYNCOPE-305: --- I'm out for lunch. After I'm back, I will take car for this issue! Best regards. Jan Can't create Sync or Sched Task in Console -- Key: SYNCOPE-305 URL: https://issues.apache.org/jira/browse/SYNCOPE-305 Project: Syncope Issue Type: Bug Reporter: Colm O hEigeartaigh Fix For: 1.1.0 I can't create either a Sync or Sched Task in the Console at the moment. Steps to reproduce: 1) Create a new project + just launch Syncope in embedded mode using the test configuration 2) Create a new Sync Task with one of the predefined Resources. You'll see a Wicket Error. In Console.log I see: Caused by: java.lang.NumberFormatException: null at java.lang.Long.parseLong(Long.java:375) ~[na:1.6.0_35] at java.lang.Long.valueOf(Long.java:525) ~[na:1.6.0_35] at org.apache.syncope.console.rest.TaskRestClient.createSyncTask(TaskRestClient.java:175) ~[TaskRestClient.class:na] -- 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
Re: Another Console error
I took a quick look but I didn't see anything obvious...will I just create
a JIRA for this?
Colm.
On Fri, Feb 1, 2013 at 7:30 AM, Francesco Chicchiriccò
ilgro...@apache.orgwrote:
On 31/01/2013 19:01, Colm O hEigeartaigh wrote:
Hi Francesco,
So, this must be the issue: with Chrome, Enter submits the whole form,
with Firefox instead the Add button in the derived attributes tab is
triggered. Odd...
Cool, that's the error alright (on Firefox). Hitting 'enter' in either a
attribute or virtual attribute textbox causes an extra derived attribute
entry to be added! I'll take a look and see what's going on.
Hi Colm,
wouldn't be enough, then, to bind the Enter key to the form submit on all
browsers?
On Thu, Jan 31, 2013 at 4:59 PM, Francesco Chicchiriccò
ilgro...@apache.org wrote:
On 31/01/2013 17:44, Colm O hEigeartaigh wrote:
Hi Francesco,
However, I am not sure to understand exactly how to replicate this:
are
you creating an user and hitting enter when populating attribute
values? If
so, I guess this happens with roles as well, isn’t it?
Yep exactly. Fill in username + password, enter some random string
for an
attribute + hit enter in the textbox when done. Then continue + select
resource, and finally hit submit. It works when I don't hit enter on
the
attribute, and fails when I do. I haven't tried with roles.
Another possibility might simply be that enter is key-bound to form
submit...
Possibly, although it doesn't try to submit straight away. The error
crops
up when I click on submit.
Colm,
I was trying to replicate this misbehavior with Chrome without any luck
because hitting Enter just caused the whole form to submit (as said),
then
I moved to Firefox and replicated the same problem.
By doing so I have noticed that the number of warnings ('Schema' is
required) was the same as empty derived attributes that resulted added
under the respective tab.
So, this must be the issue: with Chrome, Enter submits the whole form,
with Firefox instead the Add button in the derived attributes tab is
triggered. Odd...
Do you have an idea about how to fix this?
Regards.
On Thu, Jan 31, 2013 at 4:40 PM, Francesco Chicchiriccò
ilgro...@apache.org
wrote:
On 31/01/2013 17:28, Colm O hEigeartaigh wrote:
Hi guys,
I'm seeing a console error on trunk somewhat similar to SYNCOPE-297.
The
scenario here is the propagation of a user with a simple User
attribute
to
a backend. If I enter the attribute without hitting 'enter' it
propagates
fine. If I create another user, enter the value for the attribute +
hit
enter, then go on to select the resource etc., I get an error message
saying that 'Schema' is required.
Any ideas on what might be causing this?
Hi Colm,
it sounds like the same problem we fixed in SYNCOPE-297, i.e.
basically a
partial Ajax submit that should be avoided (as the patch for
SYNCOPE-297
did).
However, I am not sure to understand exactly how to replicate this: are
you creating an user and hitting enter when populating attribute
values?
If
so, I guess this happens with roles as well, isn’t it?
Another possibility might simply be that enter is key-bound to form
submit...
Regards.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~**ilgrosso/http://people.apache.org/~ilgrosso/
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Another Console error
On 01/02/2013 12:30, Colm O hEigeartaigh wrote:
I took a quick look but I didn't see anything obvious...will I just create
a JIRA for this?
Hum.. guess so.
Regards.
On Fri, Feb 1, 2013 at 7:30 AM, Francesco Chicchiriccò
ilgro...@apache.orgwrote:
On 31/01/2013 19:01, Colm O hEigeartaigh wrote:
Hi Francesco,
So, this must be the issue: with Chrome, Enter submits the whole form,
with Firefox instead the Add button in the derived attributes tab is
triggered. Odd...
Cool, that's the error alright (on Firefox). Hitting 'enter' in either a
attribute or virtual attribute textbox causes an extra derived attribute
entry to be added! I'll take a look and see what's going on.
Hi Colm,
wouldn't be enough, then, to bind the Enter key to the form submit on all
browsers?
On Thu, Jan 31, 2013 at 4:59 PM, Francesco Chicchiriccò
ilgro...@apache.org wrote:
On 31/01/2013 17:44, Colm O hEigeartaigh wrote:
Hi Francesco,
However, I am not sure to understand exactly how to replicate this:
are
you creating an user and hitting enter when populating attribute
values? If
so, I guess this happens with roles as well, isn’t it?
Yep exactly. Fill in username + password, enter some random string
for an
attribute + hit enter in the textbox when done. Then continue + select
resource, and finally hit submit. It works when I don't hit enter on
the
attribute, and fails when I do. I haven't tried with roles.
Another possibility might simply be that enter is key-bound to form
submit...
Possibly, although it doesn't try to submit straight away. The error
crops
up when I click on submit.
Colm,
I was trying to replicate this misbehavior with Chrome without any luck
because hitting Enter just caused the whole form to submit (as said),
then
I moved to Firefox and replicated the same problem.
By doing so I have noticed that the number of warnings ('Schema' is
required) was the same as empty derived attributes that resulted added
under the respective tab.
So, this must be the issue: with Chrome, Enter submits the whole form,
with Firefox instead the Add button in the derived attributes tab is
triggered. Odd...
Do you have an idea about how to fix this?
Regards.
On Thu, Jan 31, 2013 at 4:40 PM, Francesco Chicchiriccò
ilgro...@apache.org
wrote:
On 31/01/2013 17:28, Colm O hEigeartaigh wrote:
Hi guys,
I'm seeing a console error on trunk somewhat similar to SYNCOPE-297.
The
scenario here is the propagation of a user with a simple User
attribute
to
a backend. If I enter the attribute without hitting 'enter' it
propagates
fine. If I create another user, enter the value for the attribute +
hit
enter, then go on to select the resource etc., I get an error message
saying that 'Schema' is required.
Any ideas on what might be causing this?
Hi Colm,
it sounds like the same problem we fixed in SYNCOPE-297, i.e.
basically a
partial Ajax submit that should be avoided (as the patch for
SYNCOPE-297
did).
However, I am not sure to understand exactly how to replicate this: are
you creating an user and hitting enter when populating attribute
values?
If
so, I guess this happens with roles as well, isn’t it?
Another possibility might simply be that enter is key-bound to form
submit...
Regards.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
[jira] [Commented] (SYNCOPE-231) Using Standard JAX-RS API in Syncope (Introducing Apache CXF WS Stack)
[ https://issues.apache.org/jira/browse/SYNCOPE-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13568700#comment-13568700 ] Hudson commented on SYNCOPE-231: Integrated in Syncope-trunk #55 (See [https://builds.apache.org/job/Syncope-trunk/55/]) SYNCOPE-231 Removing unused imports (Revision 1441415) Result = SUCCESS cschneider : Files : * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services/TaskServiceImpl.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/TaskTestITCase.java Using Standard JAX-RS API in Syncope (Introducing Apache CXF WS Stack) -- Key: SYNCOPE-231 URL: https://issues.apache.org/jira/browse/SYNCOPE-231 Project: Syncope Issue Type: Improvement Components: console, core Reporter: Jan Bernhardt Assignee: Jan Bernhardt Fix For: 1.1.0 Attachments: TaskService.patch Current REST Interfaces are based on Spring Webservice framework. Goal of this task is to replace Spring with CXF and to relay on JAX-B and JAX-RS annotations rather then Spring annotations. -- 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
RE: [jira] [Commented] (SYNCOPE-305) Can't create Sync or Sched Task in Console
OK, should be fixed now. Best regards. Jan -Original Message- From: Jan Bernhardt (JIRA) [mailto:j...@apache.org] Sent: Freitag, 1. Februar 2013 12:26 To: dev@syncope.apache.org Subject: [jira] [Commented] (SYNCOPE-305) Can't create Sync or Sched Task in Console [ https://issues.apache.org/jira/browse/SYNCOPE- 305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment- tabpanelfocusedCommentId=13568675#comment-13568675 ] Jan Bernhardt commented on SYNCOPE-305: --- I'm out for lunch. After I'm back, I will take car for this issue! Best regards. Jan Can't create Sync or Sched Task in Console -- Key: SYNCOPE-305 URL: https://issues.apache.org/jira/browse/SYNCOPE-305 Project: Syncope Issue Type: Bug Reporter: Colm O hEigeartaigh Fix For: 1.1.0 I can't create either a Sync or Sched Task in the Console at the moment. Steps to reproduce: 1) Create a new project + just launch Syncope in embedded mode using the test configuration 2) Create a new Sync Task with one of the predefined Resources. You'll see a Wicket Error. In Console.log I see: Caused by: java.lang.NumberFormatException: null at java.lang.Long.parseLong(Long.java:375) ~[na:1.6.0_35] at java.lang.Long.valueOf(Long.java:525) ~[na:1.6.0_35] at org.apache.syncope.console.rest.TaskRestClient.createSyncTask(TaskRest Client.java:175) ~[TaskRestClient.class:na] -- 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
IncompatiblePolicyException was made unchecked
Hi all, I've just noticed that IncompatiblePolicyException, created checked [1] is now unchecked: any reason for this? [1] http://svn.apache.org/viewvc/incubator/syncope/trunk/core/src/main/java/org/apache/syncope/core/util/IncompatiblePolicyException.java?view=markuppathrev=1401200 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[jira] [Updated] (SYNCOPE-258) Java class as sync policy correlation rule
[ https://issues.apache.org/jira/browse/SYNCOPE-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] fabio martelli updated SYNCOPE-258: --- Issue Type: Improvement (was: Bug) Java class as sync policy correlation rule -- Key: SYNCOPE-258 URL: https://issues.apache.org/jira/browse/SYNCOPE-258 Project: Syncope Issue Type: Improvement Components: console, core Affects Versions: 1.1.0 Reporter: fabio martelli Fix For: 1.1.0 Give the possibility to specify a java class for the sync policy to implement a custom correlation rule. If specified, this custom rule should be evaluated in place of correlation attributes rule. -- 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] [Assigned] (SYNCOPE-306) 'Mandatory' error in Console when propagating Virtual Attributes
[ https://issues.apache.org/jira/browse/SYNCOPE-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Massimiliano Perrone reassigned SYNCOPE-306: Assignee: Massimiliano Perrone 'Mandatory' error in Console when propagating Virtual Attributes Key: SYNCOPE-306 URL: https://issues.apache.org/jira/browse/SYNCOPE-306 Project: Syncope Issue Type: Bug Reporter: Colm O hEigeartaigh Assignee: Massimiliano Perrone Fix For: 1.1.0 I've run into an Error with a Mandatory User Mapping in the Console. Steps to reproduce: a) Create a new Resource (to a H2 backend) with Enforce Mandatory Conditions checked. b) Create User Mappings for Username/Password + a virtual attribute which is true for Mandatory c) Try to create a new user with a Virtual Attribute Value. You get an error saying that the Virtual Attribute is required. If I go back to the Resource + make the Virtual Attribute mapping non-Mandatory, and then create a User, it propagates correctly (including the Virtual Attribute value). -- 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
Re: IncompatiblePolicyException was made unchecked
On 01/02/2013 14:33, Andrei Shakirin wrote: Hi Francesco, I thought it was agreed in [1]. Have seen no objections in [2]. You're right about [1] and [2] - only, I have just realized now, working on SYNCOPE-136, that ignoring this exception can be very dangerous during the propagation process. And having it checked helps definitely in this sense. Do you have reasons to keep this exception checked? Let's put it the other way round: why have it unchecked? Regards. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Remote+Exceptions [2] http://syncope-dev.1063484.n5.nabble.com/Exception-propagation-in-Rest-interface-HTTP-header-vs-body-for-details-td5711482.html -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Freitag, 1. Februar 2013 14:12 To: dev@syncope.apache.org Subject: IncompatiblePolicyException was made unchecked Hi all, I've just noticed that IncompatiblePolicyException, created checked [1] is now unchecked: any reason for this? [1] http://svn.apache.org/viewvc/incubator/syncope/trunk/core/src/main/java /org/apache/syncope/core/util/IncompatiblePolicyException.java?view=mar kuppathrev=1401200 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[jira] [Commented] (SYNCOPE-231) Using Standard JAX-RS API in Syncope (Introducing Apache CXF WS Stack)
[ https://issues.apache.org/jira/browse/SYNCOPE-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13568743#comment-13568743 ] Hudson commented on SYNCOPE-231: Integrated in Syncope-trunk #56 (See [https://builds.apache.org/job/Syncope-trunk/56/]) SYNCOPE-231 Move InvalidSearchConditionException to common and make checked again (Revision 1441434) [SYNCOPE-231] * fixing Task creation bug * updating task report method (Revision 1441431) Result = SUCCESS cschneider : Files : * /syncope/trunk/common/src/main/java/org/apache/syncope/common/services/InvalidSearchConditionException.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/services/RoleService.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/services/UserService.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/commons/AttributableDataProvider.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/rest/AbstractAttributableRestClient.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/rest/RoleRestClient.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/rest/UserRestClient.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/dao/AttributableDAO.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/dao/InvalidSearchConditionException.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/dao/RoleDAO.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/dao/UserDAO.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/dao/impl/AbstractAttributableDAOImpl.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/dao/impl/RoleDAOImpl.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/dao/impl/UserDAOImpl.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/controller/RoleController.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/controller/UserController.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/utils/RestServiceExceptionMapper.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services/RoleServiceImpl.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services/UserServiceImpl.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/sync/impl/SyncopeSyncResultHandler.java * /syncope/trunk/core/src/main/webapp/syncopeClientError.jsp * /syncope/trunk/core/src/test/java/org/apache/syncope/core/persistence/dao/UserTest.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/AuthenticationTestITCase.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/SearchTestITCase.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/TaskTestITCase.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/UserRequestTestITCase.java jbernhardt : Files : * /syncope/trunk/client/src/main/java/org/apache/syncope/client/services/proxy/TaskServiceProxy.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/services/TaskService.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/to/ReportExecTO.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/types/PropagationTaskExecStatus.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/types/ReportExecStatus.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/rest/TaskRestClient.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/controller/ReportController.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services/TaskServiceImpl.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/TaskTestITCase.java Using Standard JAX-RS API in Syncope (Introducing Apache CXF WS Stack) -- Key: SYNCOPE-231 URL: https://issues.apache.org/jira/browse/SYNCOPE-231 Project: Syncope Issue Type: Improvement Components: console, core Reporter: Jan Bernhardt Assignee: Jan Bernhardt Fix For: 1.1.0 Attachments: TaskService.patch Current REST Interfaces are based on Spring Webservice framework. Goal of this task is to replace Spring with CXF and to relay on JAX-B and JAX-RS annotations rather then Spring annotations. -- 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-298) Persistence beans: change AUTO Id generation strategy to TABLE
[ https://issues.apache.org/jira/browse/SYNCOPE-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13568742#comment-13568742 ] Hudson commented on SYNCOPE-298: Integrated in Syncope-trunk #56 (See [https://builds.apache.org/job/Syncope-trunk/56/]) [SYNCOPE-298] Workaround for Id conflicts in integration tests (Revision 1441426) Result = SUCCESS ashakirin : Files : * /syncope/trunk/core/src/test/java/org/apache/syncope/core/persistence/dao/VirAttrTest.java * /syncope/trunk/core/src/test/resources/content.xml Persistence beans: change AUTO Id generation strategy to TABLE -- Key: SYNCOPE-298 URL: https://issues.apache.org/jira/browse/SYNCOPE-298 Project: Syncope Issue Type: Improvement Components: core Reporter: Andrei Shakirin Fix For: 1.2.0 Currently AUTO Id generation strategy works unstable under high load/concurrency conditions at least for H2 DB. [1], [2] Possible solution of this problem is migration AUTO to TABLE Id generation strategy for all persistence domain objects. [1] http://syncope-dev.1063484.n5.nabble.com/Question-Problem-with-test-UsertTestITCase-issueSYNCOPE279-tt5712389.html [2] http://syncope-dev.1063484.n5.nabble.com/Persistence-id-generation-strategy-TABLE-vs-AUTO-td5711813.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
RE: IncompatiblePolicyException was made unchecked
Hi Francesco, You're right about [1] and [2] - only, I have just realized now, working on SYNCOPE-136, that ignoring this exception can be very dangerous during the propagation process. And having it checked helps definitely in this sense. Let's put it the other way round: why have it unchecked? Accordingly Java Best Practices checked exceptions should be used only for conditions from which the caller can reasonably be expected to recover. Runtime exceptions should be used for preconditions violation and for programming errors. If user have real possibility to improve the situation, exception should be checked. Not sure about IncompatiblePolicyException: is it related to passwords format only? In this case I tend to change exception back to checked, because user can react on exception and try again with improved password. Cheers, Andrei. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Freitag, 1. Februar 2013 14:37 To: dev@syncope.apache.org Subject: Re: IncompatiblePolicyException was made unchecked On 01/02/2013 14:33, Andrei Shakirin wrote: Hi Francesco, I thought it was agreed in [1]. Have seen no objections in [2]. You're right about [1] and [2] - only, I have just realized now, working on SYNCOPE-136, that ignoring this exception can be very dangerous during the propagation process. And having it checked helps definitely in this sense. Do you have reasons to keep this exception checked? Let's put it the other way round: why have it unchecked? Regards. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Remote+Exceptions [2] http://syncope-dev.1063484.n5.nabble.com/Exception-propagation-in- Rest -interface-HTTP-header-vs-body-for-details-td5711482.html -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Freitag, 1. Februar 2013 14:12 To: dev@syncope.apache.org Subject: IncompatiblePolicyException was made unchecked Hi all, I've just noticed that IncompatiblePolicyException, created checked [1] is now unchecked: any reason for this? [1] http://svn.apache.org/viewvc/incubator/syncope/trunk/core/src/main/ja va /org/apache/syncope/core/util/IncompatiblePolicyException.java?view=m ar kuppathrev=1401200 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[jira] [Commented] (SYNCOPE-306) 'Mandatory' error in Console when propagating Virtual Attributes
[ https://issues.apache.org/jira/browse/SYNCOPE-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13568764#comment-13568764 ] Hudson commented on SYNCOPE-306: Integrated in Syncope-trunk #57 (See [https://builds.apache.org/job/Syncope-trunk/57/]) SYNCOPE-306 added right check on virtual attribute (Revision 1441452) Result = SUCCESS massi : Files : * /syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/data/AbstractAttributableDataBinder.java 'Mandatory' error in Console when propagating Virtual Attributes Key: SYNCOPE-306 URL: https://issues.apache.org/jira/browse/SYNCOPE-306 Project: Syncope Issue Type: Bug Reporter: Colm O hEigeartaigh Assignee: Massimiliano Perrone Fix For: 1.1.0 I've run into an Error with a Mandatory User Mapping in the Console. Steps to reproduce: a) Create a new Resource (to a H2 backend) with Enforce Mandatory Conditions checked. b) Create User Mappings for Username/Password + a virtual attribute which is true for Mandatory c) Try to create a new user with a Virtual Attribute Value. You get an error saying that the Virtual Attribute is required. If I go back to the Resource + make the Virtual Attribute mapping non-Mandatory, and then create a User, it propagates correctly (including the Virtual Attribute value). -- 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-136) Password required for resource subscription
[ https://issues.apache.org/jira/browse/SYNCOPE-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò resolved SYNCOPE-136. Resolution: Fixed http://svn.apache.org/viewvc?rev=1441482view=rev Password required for resource subscription --- Key: SYNCOPE-136 URL: https://issues.apache.org/jira/browse/SYNCOPE-136 Project: Syncope Issue Type: Improvement Reporter: Francesco Chicchiriccò Assignee: Francesco Chicchiriccò Fix For: 1.1.0 Currently, cleartext password is always required when subscribing to a new external resource. However, in some cases (for example when passwords are stored with some symmetric algorithm) this can be avoided. For example, it could be: Case 1: 2-way (a.k.a. symmetric) password cipher algorithm is configured in Syncope Use decrypted password from SyncopeUser to subscribe new resource. Case 2: 1-way (a.k.a. hash or asymmetric) password cipher algorithm is configured in Syncope and no clear-text password is available (for example, passed via UserMod or provided by a synchronizing resource) Provide, on a resource-basis, a mean to configure how new password should be generated: * constant * random password generation (compliant with resource password policy, if present - see SYNCOPE-121) * provide custom Java class Discussion thread: http://syncope-dev.1063484.n5.nabble.com/new-password-issue-td5589622.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-136) Password required for resource subscription
[ https://issues.apache.org/jira/browse/SYNCOPE-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13568825#comment-13568825 ] Hudson commented on SYNCOPE-136: Integrated in Syncope-trunk #58 (See [https://builds.apache.org/job/Syncope-trunk/58/]) [SYNCOPE-136] Feature implemented, test cases added (Revision 1441482) Result = SUCCESS ilgrosso : Files : * /syncope/trunk * /syncope/trunk/common/src/main/java/org/apache/syncope/common/to/ResourceTO.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/types/CipherAlgorithm.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/panels/ResourceDetailsPanel.java * /syncope/trunk/console/src/main/resources/org/apache/syncope/console/pages/ResourceModalPage.properties * /syncope/trunk/console/src/main/resources/org/apache/syncope/console/pages/ResourceModalPage_it.properties * /syncope/trunk/console/src/main/resources/org/apache/syncope/console/pages/panels/ResourceDetailsPanel.html * /syncope/trunk/core/src/main/java/org/apache/syncope/core/connid/PasswordGenerator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/beans/ExternalResource.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/beans/SyncTask.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/beans/user/SyncopeUser.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/propagation/impl/PropagationManager.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/data/ResourceDataBinder.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/data/UserDataBinder.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/security/EncodePasswordCLI.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/security/SyncopeAuthenticationProvider.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/util/MappingUtil.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/util/PasswordEncoder.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/UserTestITCase.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/security/PasswordEncoderTest.java * /syncope/trunk/core/src/test/resources/content.xml Password required for resource subscription --- Key: SYNCOPE-136 URL: https://issues.apache.org/jira/browse/SYNCOPE-136 Project: Syncope Issue Type: Improvement Reporter: Francesco Chicchiriccò Assignee: Francesco Chicchiriccò Fix For: 1.1.0 Currently, cleartext password is always required when subscribing to a new external resource. However, in some cases (for example when passwords are stored with some symmetric algorithm) this can be avoided. For example, it could be: Case 1: 2-way (a.k.a. symmetric) password cipher algorithm is configured in Syncope Use decrypted password from SyncopeUser to subscribe new resource. Case 2: 1-way (a.k.a. hash or asymmetric) password cipher algorithm is configured in Syncope and no clear-text password is available (for example, passed via UserMod or provided by a synchronizing resource) Provide, on a resource-basis, a mean to configure how new password should be generated: * constant * random password generation (compliant with resource password policy, if present - see SYNCOPE-121) * provide custom Java class Discussion thread: http://syncope-dev.1063484.n5.nabble.com/new-password-issue-td5589622.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-231) Using Standard JAX-RS API in Syncope (Introducing Apache CXF WS Stack)
[ https://issues.apache.org/jira/browse/SYNCOPE-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13568824#comment-13568824 ] Hudson commented on SYNCOPE-231: Integrated in Syncope-trunk #58 (See [https://builds.apache.org/job/Syncope-trunk/58/]) [SYNCOPE-231] * Adding Java Doc for TaskService * changing return type from report(..) to void, since console does not care about it and read operation can be used to get updated status (Revision 1441462) Result = SUCCESS jbernhardt : Files : * /syncope/trunk/client/src/main/java/org/apache/syncope/client/services/proxy/TaskServiceProxy.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/services/TaskService.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services/TaskServiceImpl.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/TaskTestITCase.java Using Standard JAX-RS API in Syncope (Introducing Apache CXF WS Stack) -- Key: SYNCOPE-231 URL: https://issues.apache.org/jira/browse/SYNCOPE-231 Project: Syncope Issue Type: Improvement Components: console, core Reporter: Jan Bernhardt Assignee: Jan Bernhardt Fix For: 1.1.0 Attachments: TaskService.patch Current REST Interfaces are based on Spring Webservice framework. Goal of this task is to replace Spring with CXF and to relay on JAX-B and JAX-RS annotations rather then Spring annotations. -- 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
[DISCUSS] User Service
Hi Syncoper, I'm almost done with new REST API Service Interface documentation [1]. Last peace missing is only User Service. Please take time to review changes to new Service Interfaces and let's have a discussion on this mailing-list. I think we already discussed all general changes, but if you find something missing, just continue this discussion. I have a couple of proposals for changes in User Service Interface, which I would like to get your feedback for. After we all agree with User Interface I will update Interface and Documentation accordingly. 1. User Controller contains 5 methods focusing on workflow activities. My proposal would be to move these methods to Workflow Service interface. We could leave business code in UserController class for 1.1.0 release and only change User and Workflow Service Interfaces for now, so that this change will only be visible to new CXF REST API. 2. There are quite some many methods capable of handling username and userId likewise (suspendByUsername, deleteByUsername). As far as I can see console does not use any of them (*byUsername). From my point of view, these methods are redundant (except one), since you can always get user id by readUser(String username) operation. My proposal would be to not support these methods in new interface any longer. 3. There are two methods (and status types) to activate an user account. ACTIVATE and REACTIVATE. From my point of view REACTIVATE is redundant, since it shouldn't matter if user was active previously or not. All that matters is that user should be active afterwards. Therefore my proposal would be to remove REACTIVATE status type and also reactivate operation method. WDYT? Best regards. Jan [1] https://cwiki.apache.org/confluence/display/SYNCOPE/REST+API+upgrade
[jira] [Commented] (SYNCOPE-231) Using Standard JAX-RS API in Syncope (Introducing Apache CXF WS Stack)
[ https://issues.apache.org/jira/browse/SYNCOPE-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13568861#comment-13568861 ] Hudson commented on SYNCOPE-231: Integrated in Syncope-trunk #59 (See [https://builds.apache.org/job/Syncope-trunk/59/]) [SYNCOPE-231] Jackson annotation for 1.2.0 (Revision 1441513) SYNCOPE-231 Switched contenttype of UserTest to xml and fixed error in TaskService create location (Revision 1441509) [SYNCOPE-231] Improved TaskTO with @XmlSeeAlso (Revision 1441495) Result = SUCCESS ashakirin : Files : * /syncope/trunk/common/src/main/java/org/apache/syncope/common/to/SchemaTO.java cschneider : Files : * /syncope/trunk/common/src/main/java/org/apache/syncope/common/to/TaskTO.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services/TaskServiceImpl.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/jaxrs/UserTestITCaseJAXRS.java ashakirin : Files : * /syncope/trunk/common/src/main/java/org/apache/syncope/common/to/TaskTO.java Using Standard JAX-RS API in Syncope (Introducing Apache CXF WS Stack) -- Key: SYNCOPE-231 URL: https://issues.apache.org/jira/browse/SYNCOPE-231 Project: Syncope Issue Type: Improvement Components: console, core Reporter: Jan Bernhardt Assignee: Jan Bernhardt Fix For: 1.1.0 Attachments: TaskService.patch Current REST Interfaces are based on Spring Webservice framework. Goal of this task is to replace Spring with CXF and to relay on JAX-B and JAX-RS annotations rather then Spring annotations. -- 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
RE: IncompatiblePolicyException was made unchecked
Can we agree on something here? My +1 for checked -Original Message- From: Christian Schneider [mailto:cschneider...@gmail.com] On Behalf Of Christian Schneider Sent: Freitag, 1. Februar 2013 15:14 To: dev@syncope.apache.org Subject: Re: IncompatiblePolicyException was made unchecked Sorry about the long explanation that is completely unrelated to this special case but I think the discussion checked vs unchecked exceptions is a general thing so I write a general reasoning... In general checked Exceptions force the user of an API to handle an exception at exactly the point where it happens. Often thoughit is much easier to let an exception bubble up the stack to a general place where exceptions are handled. Checked exceptions also force to Map an exception at every layer of an application. The reason is that simply throwing exceptions over layer boundaries violates encapsulation. So my way of handling checked exceptions is: where they are forced upon me by an API I map them to an unchecked Exception as soon as possible to limit their effect / damage. I have found a nice explanation on this article http://www.javacodegeeks.com/2012/03/why-should-you-use-unchecked- exceptions.html In his famous book, *Clean code: a handbook of agile software craftsmanship*[3 http://books.google.co.in/books/about/Clean_code.html?id=dwSfGQAAC AAJ redir_esc=y], Robert C. Martin writes the below lines supporting Unchecked Exceptions. /The debate is over. For years Java programmers have debated over the benefits and liabilities //of checked exceptions. When checked exceptions were introduced in the first version //of Java, they seemed like a great idea. The signature of every method would list all of the //exceptions that it could pass to its caller. Moreover, these exceptions were part of the type/ /of the method. Your code literally wouldn't compile if the signature didn't match what your //code could do./ / / /At the time, we thought that checked exceptions were a great idea; and yes, they can //yield some benefit. However, it is clear now that they aren't necessary for the production of //robust software. C# doesn't have checked exceptions, and despite valiant attempts, C++ //doesn't either. Neither do Python or Ruby. Yet it is possible to write robust software in all //of these languages. Because that is the case, we have to decide---really---whether checked //exceptions are worth their price./ / / Here some more similar articles: http://tapestryjava.blogspot.in/2011/05/tragedy-of-checked- exceptions.html http://blogs.atlassian.com/2011/05/exceptions_are_bad/ http://misko.hevery.com/2009/09/16/checked-exceptions-i-love-you-but- you-have-to-go/ Christian Am 01.02.2013 14:36, schrieb Francesco Chicchiriccò: On 01/02/2013 14:33, Andrei Shakirin wrote: Hi Francesco, I thought it was agreed in [1]. Have seen no objections in [2]. You're right about [1] and [2] - only, I have just realized now, working on SYNCOPE-136, that ignoring this exception can be very dangerous during the propagation process. And having it checked helps definitely in this sense. Do you have reasons to keep this exception checked? Let's put it the other way round: why have it unchecked? Regards. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Remote+Exceptions [2] http://syncope-dev.1063484.n5.nabble.com/Exception-propagation-in- Res t-interface-HTTP-header-vs-body-for-details-td5711482.html -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Freitag, 1. Februar 2013 14:12 To: dev@syncope.apache.org Subject: IncompatiblePolicyException was made unchecked Hi all, I've just noticed that IncompatiblePolicyException, created checked [1] is now unchecked: any reason for this? [1] http://svn.apache.org/viewvc/incubator/syncope/trunk/core/src/main/j ava /org/apache/syncope/core/util/IncompatiblePolicyException.java?view= mar kuppathrev=1401200 -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com
Re: [DISCUSS] User Service
On 01/02/2013 17:32, Jan Bernhardt wrote: Hi Syncoper, I'm almost done with new REST API Service Interface documentation [1]. Last peace missing is only User Service. Please take time to review changes to new Service Interfaces and let's have a discussion on this mailing-list. I think we already discussed all general changes, but if you find something missing, just continue this discussion. I have a couple of proposals for changes in User Service Interface, which I would like to get your feedback for. After we all agree with User Interface I will update Interface and Documentation accordingly. 1. User Controller contains 5 methods focusing on workflow activities. My proposal would be to move these methods to Workflow Service interface. We could leave business code in UserController class for 1.1.0 release and only change User and Workflow Service Interfaces for now, so that this change will only be visible to new CXF REST API. The WorkflowController is a general interface for managing and querying the workflow definitions (that can vary depending on the standard or custom workflow adapters you have on your own project). The workflow-related methods in UserController (and RoleController BTW) are there because they are involved in user (and role) lifecycle management. Given these things, I wouldn't make any movement. 2. There are quite some many methods capable of handling username and userId likewise (suspendByUsername, deleteByUsername). As far as I can see console does not use any of them (*byUsername). From my point of view, these methods are redundant (except one), since you can always get user id by readUser(String username) operation. My proposal would be to not support these methods in new interface any longer. The username-based methods were introduced for making more user-friendly the invocation of user methods, even from command line using tools like curl; the admin console was built before that, and hence it's using the former id-based methods. I agree that username-based are redundant, but they were introduced to increase the ease of use, not the efficiency. 3. There are two methods (and status types) to activate an user account. ACTIVATE and REACTIVATE. From my point of view REACTIVATE is redundant, since it shouldn't matter if user was active previously or not. All that matters is that user should be active afterwards. Therefore my proposal would be to remove REACTIVATE status type and also reactivate operation method. Activate and reactivate are differentiated at UserWorkflowAdapter level because they are in fact two distinct operations. This difference is then naturally reflected into the REST interface. Regards. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/REST+API+upgrade -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[jira] [Commented] (SYNCOPE-231) Using Standard JAX-RS API in Syncope (Introducing Apache CXF WS Stack)
[ https://issues.apache.org/jira/browse/SYNCOPE-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13568903#comment-13568903 ] Hudson commented on SYNCOPE-231: Integrated in Syncope-trunk #60 (See [https://builds.apache.org/job/Syncope-trunk/60/]) SYNCOPE-231 Fix for issue in UserService read by name (Revision 1441540) SYNCOPE-231 Added test for issue in userService read by name (Revision 1441528) Result = SUCCESS cschneider : Files : * /syncope/trunk/common/src/main/java/org/apache/syncope/common/services/UserService.java cschneider : Files : * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/UserTestITCase.java Using Standard JAX-RS API in Syncope (Introducing Apache CXF WS Stack) -- Key: SYNCOPE-231 URL: https://issues.apache.org/jira/browse/SYNCOPE-231 Project: Syncope Issue Type: Improvement Components: console, core Reporter: Jan Bernhardt Assignee: Jan Bernhardt Fix For: 1.1.0 Attachments: TaskService.patch Current REST Interfaces are based on Spring Webservice framework. Goal of this task is to replace Spring with CXF and to relay on JAX-B and JAX-RS annotations rather then Spring annotations. -- 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-231) Using Standard JAX-RS API in Syncope (Introducing Apache CXF WS Stack)
[ https://issues.apache.org/jira/browse/SYNCOPE-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13569118#comment-13569118 ] Hudson commented on SYNCOPE-231: Integrated in Syncope-trunk #62 (See [https://builds.apache.org/job/Syncope-trunk/62/]) SYNCOPE-231 Fix marshalling issue in getReportletConfClasses (Revision 1441629) Result = SUCCESS cschneider : Files : * /syncope/trunk/client/src/main/java/org/apache/syncope/client/services/proxy/ReportServiceProxy.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/services/ReportService.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/services/ReportletConfClasses.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/rest/ReportRestClient.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services/ReportServiceImpl.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/ReportTestITCase.java Using Standard JAX-RS API in Syncope (Introducing Apache CXF WS Stack) -- Key: SYNCOPE-231 URL: https://issues.apache.org/jira/browse/SYNCOPE-231 Project: Syncope Issue Type: Improvement Components: console, core Reporter: Jan Bernhardt Assignee: Jan Bernhardt Fix For: 1.1.0 Attachments: TaskService.patch Current REST Interfaces are based on Spring Webservice framework. Goal of this task is to replace Spring with CXF and to relay on JAX-B and JAX-RS annotations rather then Spring annotations. -- 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
