[jira] [Created] (SYNCOPE-824) Push/Pull task "names" not marked as mandatory in the console

[Colm O hEigeartaigh (JIRA)]

Colm O hEigeartaigh created SYNCOPE-824:
---

 Summary: Push/Pull task "names" not marked as mandatory in the 
console
 Key: SYNCOPE-824
 URL: https://issues.apache.org/jira/browse/SYNCOPE-824
 Project: Syncope
  Issue Type: Improvement
  Components: console
Affects Versions: 2.0.0-M2
Reporter: Colm O hEigeartaigh
Priority: Minor
 Fix For: 2.0.0


When creating a push/pull task in the console, there is no "*" beside the 
"name" indicating it is mandatory. You can click "Next" to go to the next 
screen, but you only see an error on "Finish":

InvalidSchedTask [Standard: {javax.validation.constraints.NotNull.message}]

I think the Destination Realm + Pull Mode should also be marked mandatory for 
the pull task.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SYNCOPE-823) Workflow XML editor pops up after closing Activiti Modeler

[JIRA]

Francesco Chicchiriccò created SYNCOPE-823:
--

 Summary: Workflow XML editor pops up after closing Activiti Modeler
 Key: SYNCOPE-823
 URL: https://issues.apache.org/jira/browse/SYNCOPE-823
 Project: Syncope
  Issue Type: Bug
  Components: console
Affects Versions: 2.0.0-M2
Reporter: Francesco Chicchiriccò
 Fix For: 2.0.0


How to reproduce; under Configuration > Workflow

 # open XML editor
 # hit Cancel
 # open Activiti Modeler
 # close

You will see ahain the XML editor window popping up.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SYNCOPE-806) Validate "standalone" resource provisioning

[JIRA]

 [ 
https://issues.apache.org/jira/browse/SYNCOPE-806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Chicchiriccò resolved SYNCOPE-806.

Resolution: Fixed

> Validate "standalone" resource provisioning
> ---
>
> Key: SYNCOPE-806
> URL: https://issues.apache.org/jira/browse/SYNCOPE-806
> Project: Syncope
>  Issue Type: Improvement
>  Components: console
>Affects Versions: 2.0.0-M2
>Reporter: Colm O hEigeartaigh
>Assignee: Francesco Chicchiriccò
>Priority: Minor
> Fix For: 2.0.0
>
>
> A lot of the resources configured in the "standalone" distribution appear to 
> be missing internal attributes in the provisioning mappings. For example, in 
> "resource-ldap" no internal attribute is specified for the mapping to 
> "postal". So if you click "Next" on the mapping page you get an error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SYNCOPE-806) Validate "standalone" resource provisioning

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SYNCOPE-806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15226274#comment-15226274
 ] 

ASF subversion and git services commented on SYNCOPE-806:
-

Commit 692e1f91c67d8eeaa731392d42daa03b1df07248 in syncope's branch 
refs/heads/master from [~ilgrosso]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=692e1f9 ]

[SYNCOPE-806] Resource provisioning validated, and management of aux classes in 
Provision instances added


> Validate "standalone" resource provisioning
> ---
>
> Key: SYNCOPE-806
> URL: https://issues.apache.org/jira/browse/SYNCOPE-806
> Project: Syncope
>  Issue Type: Improvement
>  Components: console
>Affects Versions: 2.0.0-M2
>Reporter: Colm O hEigeartaigh
>Assignee: Francesco Chicchiriccò
>Priority: Minor
> Fix For: 2.0.0
>
>
> A lot of the resources configured in the "standalone" distribution appear to 
> be missing internal attributes in the provisioning mappings. For example, in 
> "resource-ldap" no internal attribute is specified for the mapping to 
> "postal". So if you click "Next" on the mapping page you get an error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [DISCUSS] Switching to UUID primary keys for users, groups and any objects

[Francesco Chicchiriccò]

Hi all,
it seems we are quite on the same page: UUIDs are good for Syncope, for 
various reasons; side note: I haven't thought before how this will also 
simplify the export / import of configuration as XML, not having to deal 
any more with OPENJPA_SEQUENCES...


About the doubts expressed:

 * @Massimiliano: I don't believe it would take too much time: my 
estimate is for 1~2 weeks at most, once I've understood how to manage 
things at OpenJPA level [6]; moreover, I would say that such a step is 
for new major releases, so it's something for 2.0 (or 3.0), I would 
hardly introduce it in - say - 2.1.


 * @Guido: the migration path from 1.2 to 2.0, at least for how it is 
being developed [7] is not affected by this change: users (and 1.2 
roles, now groups) are meant to be pulled (synced in 1.2 terms) via a 
"Syncope" ConnId connector; naturally, if someone uses the Syncope user 
id outside of Syncope, this is definitely going to be problematic as you 
highlight, even though there are some resolving strategies as replacing 
user id with username for external reference, or to map somewhere 
externally UUIDs to long.


I have opened SYNCOPE-822 for tracking this.

Regards.

On 04/04/2016 22:22, Guido Wimmel wrote:

I'd also prefer UUIDs over the current primary keys.

However, that would make migrations from 1.2.x to 2.0 even more 
difficult than they probably already will be

- especially if someone uses the Syncope user id outside of Syncope.

Cheers,
  Guido

Am 04.04.2016 um 15:51 schrieb Colm O hEigeartaigh:

+1 if it is feasible for 2.0.0. Having a unique global Id maps nicely to
the SCIM Id which "MUST be unique across the SCIM service provider's 
entire

set of resources.".

Colm.

On Mon, Apr 4, 2016 at 11:11 AM, Massimiliano Perrone 
 wrote:



Il 04/04/2016 10:23, Francesco Chicchiriccò ha scritto:


Hi all,
a recent e-mail on user@ [1] (about SCIM) made me reconsider one of 
the

choices we've made in Syncope since the beginning, e.g. using table
generators for long primary keys in several entities, and 
especially for
users, groups and any objects (and maybe related as attributes, 
memberships

and relationships).

It seems that UUID offers several advantages, compared to natural keys
(as "long" we use for the aforementioned entities) [2][3][4].

There is some open source UUID generator around [5], which is 
reported to

perform quite better than standard JDK's, and also features time-based
generation, particularly useful in cluster scenarios.

Naturally, all this would mean changing some logic and data
representation, hence a relevant impact on the codebase, but with
considerable improvements in portability and performance.

It is my opinion, after a quick chat with Mark Struberg on 
#openjpa, that
this change might worth the effort, and also that we can make it 
before

finalizing 2.0.0.

I am going anyway to ask for details on users@openjpa.

WDYT?

It seems to be a good enhancement, my only doubt is only about the 
time.
Do you think it's a good idea (I'm supposing that you know how much 
time
you need to implement the feature) implementing it before the 2.0.0 
release?


Regards,
Massi
[1] 
http://syncope-user.1051894.n5.nabble.com/Get-list-of-Users-from-a-Syncope-Group-td5708406.html 


[2] http://blog.codinghorror.com/primary-keys-ids-versus-guids/
[3] 
http://web.archive.org/web/20150511162734/http://databases.aspfaq.com/database/what-should-i-choose-for-my-primary-key.html 

[4] 
http://blog.xebia.com/jpa-implementation-patterns-using-uuids-as-primary-keys/ 


[5] https://github.com/cowtowncoder/java-uuid-generator

[6] http://markmail.org/message/licbo2xitkkh2qhu
[7] 
https://cwiki.apache.org/confluence/display/SYNCOPE/[DISCUSS]+Migrate+from+1.2+to+2.0


--
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC, CXF committer
http://home.apache.org/~ilgrosso/