Propagate multiple group members
We have users that can be members of multiple groups with extended attributes. We want to propagate each group membership including the extended attributes for users to a table in a database. We have only been able to do this by mapping each group as its own resource. Is there a way to propagate all group memberships at once ie mapping like memberships[*].attribute? -- Sent from: http://syncope-dev.1063484.n5.nabble.com/
Speakers needed for Apache DC Roadshow
We need your help to make the Apache Washington DC Roadshow on Dec 4th a success. What do we need most? Speakers! We're bringing a unique DC flavor to this event by mixing Open Source Software with talks about Apache projects as well as OSS CyberSecurity, OSS in Government and and OSS Career advice. Please take a look at: http://www.apachecon.com/usroadshow18/ (Note: You are receiving this message because you are subscribed to one or more mailing lists at The Apache Software Foundation.) Rich, for the ApacheCon Planners -- rbo...@apache.org http://apachecon.com @ApacheCon
[jira] [Updated] (SYNCOPE-1369) User requests
[ https://issues.apache.org/jira/browse/SYNCOPE-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated SYNCOPE-1369: Component/s: documentation > User requests > - > > Key: SYNCOPE-1369 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1369 > Project: Syncope > Issue Type: New Feature > Components: common, console, core, documentation, enduser >Reporter: Francesco Chicchiriccò >Assignee: Francesco Chicchiriccò >Priority: Major > Fix For: 2.1.2, 3.0.0 > > > With user requests, users can initiate whichever request among the ones > defined, for example "assign me a mobile phone" or "give me those groups on > AD", for them or on behalf of others; once initiated, such requests can then > follow their own path, which might include one or more approval steps. > There is also no limitation on the number of concurrent requests that an user > can initiate. > Unfortunately, our current implementation is not able to properly implement > the user requests as briefly outlined above; among other things, the > impossibility to handle more than an approval process at a time, per user. > Hence, and a major refactoring is needed: > # remove approvals features from the current Flowable user workflow adapter > # define a new UserRequest entity, which includes at least > ## some triggering conditions > ## a Flowable workflow definition, possibly containing approval form(s) > # adjust REST services, Admin Console and Enduser UI to cope with the new > User Request entity -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SYNCOPE-1369) User requests
[ https://issues.apache.org/jira/browse/SYNCOPE-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated SYNCOPE-1369: Component/s: enduser > User requests > - > > Key: SYNCOPE-1369 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1369 > Project: Syncope > Issue Type: New Feature > Components: common, console, core, documentation, enduser >Reporter: Francesco Chicchiriccò >Assignee: Francesco Chicchiriccò >Priority: Major > Fix For: 2.1.2, 3.0.0 > > > With user requests, users can initiate whichever request among the ones > defined, for example "assign me a mobile phone" or "give me those groups on > AD", for them or on behalf of others; once initiated, such requests can then > follow their own path, which might include one or more approval steps. > There is also no limitation on the number of concurrent requests that an user > can initiate. > Unfortunately, our current implementation is not able to properly implement > the user requests as briefly outlined above; among other things, the > impossibility to handle more than an approval process at a time, per user. > Hence, and a major refactoring is needed: > # remove approvals features from the current Flowable user workflow adapter > # define a new UserRequest entity, which includes at least > ## some triggering conditions > ## a Flowable workflow definition, possibly containing approval form(s) > # adjust REST services, Admin Console and Enduser UI to cope with the new > User Request entity -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [DISCUSS] User requests
Hi all, no objections, hence I created https://issues.apache.org/jira/browse/SYNCOPE-1369 Regards. On 07/09/2018 14:52, Francesco Chicchiriccò wrote: On 06/09/2018 12:31, Francesco Chicchiriccò wrote: Hi all, I have been lately involved into some considerations around user workflow, approvals and user requests. As stated in [1], "Workflow manages the internal identity lifecycle by defining statuses and transitions that every user, group or any object in Apache Syncope will traverse.". For users, the Flowable adapter is available [2] (Activiti up to Syncope 2.0), which allows to define approvals [3] as additional steps to traverse, to which approval forms are bound. So far, so good. The current approval forms can be seen as a particular case of a more general concept, e.g user requests - a core concept of Identity Governance (IGA). With user requests, users can initiate whichever request among the ones defined, for example "assign me a mobile phone" or "give me those groups on AD", for them or on behalf of others; once initiated, such requests can then follow their own path, which might include one or more approval steps. There is also no limitation on the number of concurrent requests that an user can initiate. Unfortunately, I came to the conclusion that our current implementation is not able to properly implement the user requests as briefly outlined above; among other things, the impossibility to handle more than an approval process at a time, per user. Hence, and a major refactoring is needed; I propose to: 1. remove the current Flowable user workflow adapter After some further considerations, I think that this statement could be reformulated as 1. remove approvals features from the current Flowable user workflow adapter leaving it still open for usage in Syncope 2.1 and future releases, but only to manage the internal user lifecycle and *not* for approvals - which will be anyway replaced by user requests. 2. power up the DefaultUserWorkflowAdapter to allow easier injection of custom logic, with the usual way we already take for PullActions, PushActions, RealmActions etc, e.g. WorkflowActions 3. define a new UserRequest entity, which includes at least 3.1 some triggering conditions 3.2 a Flowable workflow definition, possibly containing approval form(s) 4. adjust REST services, Admin Console and Enduser UI to cope with the new UserRequest concept In my idea, the changes above should take place in the 2_1_X branch (and thus be likely available with Syncope 2.1.2), along with proper upgrade instructions from Syncope 2.1.1. WDYT? Regards. [1] https://ci.apache.org/projects/syncope/2_1_X/reference-guide.html#workflow [2] https://ci.apache.org/projects/syncope/2_1_X/reference-guide.html#flowable-user-workflow-adapter [3] https://ci.apache.org/projects/syncope/2_1_X/reference-guide.html#approval -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Member at The Apache Software Foundation Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail http://home.apache.org/~ilgrosso/
[jira] [Created] (SYNCOPE-1369) User requests
Francesco Chicchiriccò created SYNCOPE-1369: --- Summary: User requests Key: SYNCOPE-1369 URL: https://issues.apache.org/jira/browse/SYNCOPE-1369 Project: Syncope Issue Type: New Feature Components: common, console, core Reporter: Francesco Chicchiriccò Assignee: Francesco Chicchiriccò Fix For: 2.1.2, 3.0.0 With user requests, users can initiate whichever request among the ones defined, for example "assign me a mobile phone" or "give me those groups on AD", for them or on behalf of others; once initiated, such requests can then follow their own path, which might include one or more approval steps. There is also no limitation on the number of concurrent requests that an user can initiate. Unfortunately, our current implementation is not able to properly implement the user requests as briefly outlined above; among other things, the impossibility to handle more than an approval process at a time, per user. Hence, and a major refactoring is needed: # remove approvals features from the current Flowable user workflow adapter # define a new UserRequest entity, which includes at least ## some triggering conditions ## a Flowable workflow definition, possibly containing approval form(s) # adjust REST services, Admin Console and Enduser UI to cope with the new User Request entity -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SYNCOPE-1019) Template mechanism for Enduser UI
[ https://issues.apache.org/jira/browse/SYNCOPE-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Alessandroni resolved SYNCOPE-1019. -- Resolution: Fixed > Template mechanism for Enduser UI > - > > Key: SYNCOPE-1019 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1019 > Project: Syncope > Issue Type: New Feature > Components: enduser >Reporter: Francesco Chicchiriccò >Assignee: Matteo Alessandroni >Priority: Major > Labels: gsoc2018 > Fix For: 2.0.11, 2.1.2, 3.0.0 > > > Provide a mechanism for defining templates (in terms of HTML, CSS and image > files) to simply the appearance customization of the Enduser UI. > The the goal of the issue is to provide a way to: > - avoid HTML code duplication, and define reusable components. > - define an HTML template mechanism which aim is to improve customizability > of the enduser (enduser is meant to be customized and extended, it is not a > finite product, but a proposal from which to start a new implementation). > - exploit as much as possible code re-usability features provided by > AngularJS (if possible). > - if needed review actula CSS implementation, in order to better fit the new > template mechanism > - do NOT compromise (or change) enduser functionalities at all! Buttons, > selects, wizard and other components should preserve their role and function; > the core logic should remain the same, though enduser is open to discuss > improvements also in that way ;) > [This|https://code.angularjs.org/1.6.3/docs/guide/templates] could be a good > starting point to understand how to use AngularJS tools to implement > templating. > BTW If you have proposals that does not involve AngularJS features, they are > well accepted and can be accepted anyway. > Some of the features described there, like directives, have also been used in > the Enduser to define some reusable components (e.g. dynamic-plain-attribute). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SYNCOPE-1019) Template mechanism for Enduser UI
[ https://issues.apache.org/jira/browse/SYNCOPE-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16610205#comment-16610205 ] ASF subversion and git services commented on SYNCOPE-1019: -- Commit f9937e77b78057f91a35d6caa46e9b1e3af832c7 in syncope's branch refs/heads/master from skylark17 [ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=f9937e7 ] [SYNCOPE-1019] Added dynamic templating feature to Enduser app > Template mechanism for Enduser UI > - > > Key: SYNCOPE-1019 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1019 > Project: Syncope > Issue Type: New Feature > Components: enduser >Reporter: Francesco Chicchiriccò >Assignee: Matteo Alessandroni >Priority: Major > Labels: gsoc2018 > Fix For: 2.0.11, 2.1.2, 3.0.0 > > > Provide a mechanism for defining templates (in terms of HTML, CSS and image > files) to simply the appearance customization of the Enduser UI. > The the goal of the issue is to provide a way to: > - avoid HTML code duplication, and define reusable components. > - define an HTML template mechanism which aim is to improve customizability > of the enduser (enduser is meant to be customized and extended, it is not a > finite product, but a proposal from which to start a new implementation). > - exploit as much as possible code re-usability features provided by > AngularJS (if possible). > - if needed review actula CSS implementation, in order to better fit the new > template mechanism > - do NOT compromise (or change) enduser functionalities at all! Buttons, > selects, wizard and other components should preserve their role and function; > the core logic should remain the same, though enduser is open to discuss > improvements also in that way ;) > [This|https://code.angularjs.org/1.6.3/docs/guide/templates] could be a good > starting point to understand how to use AngularJS tools to implement > templating. > BTW If you have proposals that does not involve AngularJS features, they are > well accepted and can be accepted anyway. > Some of the features described there, like directives, have also been used in > the Enduser to define some reusable components (e.g. dynamic-plain-attribute). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
