[jira] [Updated] (SYNCOPE-1061) Support SAML 2.0 Redirect profile
[
https://issues.apache.org/jira/browse/SYNCOPE-1061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò updated SYNCOPE-1061:
Description: SYNCOPE-1041 introduced the SAML 2.0 SP extension, supporting
only the POST binding profile; adding support for the Redirect profile should
not be hard, thanks to the underlying support from
{{cxf-rt-rs-security-sso-saml}}. (was: SYNCOPE-1041 introduced the SAML 2.0 SP
extension, supporting only the POST binding profile; tadding support for the
Redirect profile should not be hard, thanks to the underlying support from
{{cxf-rt-rs-security-sso-saml}}.)
> Support SAML 2.0 Redirect profile
> -
>
> Key: SYNCOPE-1061
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1061
> Project: Syncope
> Issue Type: Improvement
> Components: extensions
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 2.0.3, 2.1.0
>
>
> SYNCOPE-1041 introduced the SAML 2.0 SP extension, supporting only the POST
> binding profile; adding support for the Redirect profile should not be hard,
> thanks to the underlying support from {{cxf-rt-rs-security-sso-saml}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (SYNCOPE-1061) Support SAML 2.0 Redirect profile
[
https://issues.apache.org/jira/browse/SYNCOPE-1061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò reassigned SYNCOPE-1061:
---
Assignee: Francesco Chicchiriccò
> Support SAML 2.0 Redirect profile
> -
>
> Key: SYNCOPE-1061
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1061
> Project: Syncope
> Issue Type: Improvement
> Components: extensions
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 2.0.3, 2.1.0
>
>
> SYNCOPE-1041 introduced the SAML 2.0 SP extension, supporting only the POST
> binding profile; tadding support for the Redirect profile should not be hard,
> thanks to the underlying support from {{cxf-rt-rs-security-sso-saml}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SYNCOPE-1055) Provide Flowable 5.X-based workflow adapter
[
https://issues.apache.org/jira/browse/SYNCOPE-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15964464#comment-15964464
]
ASF subversion and git services commented on SYNCOPE-1055:
--
Commit cd8b72deac696e62bcad042179b9366ec191eba2 in syncope's branch
refs/heads/master from [~ilgrosso]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=cd8b72d ]
[SYNCOPE-1055] Adding ref to Flowable in the docs
> Provide Flowable 5.X-based workflow adapter
> ---
>
> Key: SYNCOPE-1055
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1055
> Project: Syncope
> Issue Type: New Feature
> Components: console, core
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 2.0.3
>
>
> As discussed in ML, provide an additional {{workflow-flowable}} adapter based
> on Flowable 5.23.0 which should be a simple drop-in replacement of Activiti
> 5.22.0.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SYNCOPE-1055) Provide Flowable 5.X-based workflow adapter
[
https://issues.apache.org/jira/browse/SYNCOPE-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15964462#comment-15964462
]
ASF subversion and git services commented on SYNCOPE-1055:
--
Commit 10d53d2bda9bab857f08a04aa9dc0e8991ee2ee9 in syncope's branch
refs/heads/2_0_X from [~ilgrosso]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=10d53d2 ]
[SYNCOPE-1055] Adding ref to Flowable in the docs
> Provide Flowable 5.X-based workflow adapter
> ---
>
> Key: SYNCOPE-1055
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1055
> Project: Syncope
> Issue Type: New Feature
> Components: console, core
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 2.0.3
>
>
> As discussed in ML, provide an additional {{workflow-flowable}} adapter based
> on Flowable 5.23.0 which should be a simple drop-in replacement of Activiti
> 5.22.0.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (SYNCOPE-1020) Support for BPMN call activity
[
https://issues.apache.org/jira/browse/SYNCOPE-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò resolved SYNCOPE-1020.
-
Resolution: Fixed
> Support for BPMN call activity
> --
>
> Key: SYNCOPE-1020
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1020
> Project: Syncope
> Issue Type: Improvement
> Components: core
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 2.0.3, 2.1.0
>
>
> From the [Activiti User
> Guide|https://www.activiti.org/userguide/#bpmnCallActivity]:
> {quote}
> BPMN 2.0 makes a distinction between a regular subprocess, often also called
> embedded subprocess, and the call activity, which looks very similar. From a
> conceptual point of view, both will call a subprocess when process execution
> arrives at the activity.
> The difference is that the call activity references a process that is
> external to the process definition, whereas the subprocess is embedded within
> the original process definition. The main use case for the call activity is
> to have a reusable process definition that can be called from multiple other
> process definitions.
> {quote}
> It is currently possible to create more process definitions (besides the
> default {{userWorkflow}}) by empowering the REST endpoint
> {code}
> PUT /workflows/{anyTypeKind}
> {code}
> The new process(es) defined can then be called from the main {{userWorkflow}}
> via the {{}} element(s): the main advantage is that, by doing
> so, there are no more problems about the process definition versions, as they
> only apply to the main process (e.g. {{userWorkflow}}).
> What is currently lacking is:
> # proper management for getting all available process definitions
> # proper handling for initial loading of several process definitions from XML
> files
> # proper editing features from Admin Console
> as all the items above only consider the possibility that a single process
> definition is available.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SYNCOPE-1020) Support for BPMN call activity
[
https://issues.apache.org/jira/browse/SYNCOPE-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15964321#comment-15964321
]
ASF subversion and git services commented on SYNCOPE-1020:
--
Commit 7a4406185310898b95bd6c6af2ae6e20e28392d3 in syncope's branch
refs/heads/2_0_X from [~ilgrosso]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=7a44061 ]
[SYNCOPE-1020] Implementation completed: now several sub-processes can be
managed besides the main workflow definition; for both Activiti and Flowable
> Support for BPMN call activity
> --
>
> Key: SYNCOPE-1020
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1020
> Project: Syncope
> Issue Type: Improvement
> Components: core
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 2.0.3, 2.1.0
>
>
> From the [Activiti User
> Guide|https://www.activiti.org/userguide/#bpmnCallActivity]:
> {quote}
> BPMN 2.0 makes a distinction between a regular subprocess, often also called
> embedded subprocess, and the call activity, which looks very similar. From a
> conceptual point of view, both will call a subprocess when process execution
> arrives at the activity.
> The difference is that the call activity references a process that is
> external to the process definition, whereas the subprocess is embedded within
> the original process definition. The main use case for the call activity is
> to have a reusable process definition that can be called from multiple other
> process definitions.
> {quote}
> It is currently possible to create more process definitions (besides the
> default {{userWorkflow}}) by empowering the REST endpoint
> {code}
> PUT /workflows/{anyTypeKind}
> {code}
> The new process(es) defined can then be called from the main {{userWorkflow}}
> via the {{}} element(s): the main advantage is that, by doing
> so, there are no more problems about the process definition versions, as they
> only apply to the main process (e.g. {{userWorkflow}}).
> What is currently lacking is:
> # proper management for getting all available process definitions
> # proper handling for initial loading of several process definitions from XML
> files
> # proper editing features from Admin Console
> as all the items above only consider the possibility that a single process
> definition is available.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SYNCOPE-1020) Support for BPMN call activity
[
https://issues.apache.org/jira/browse/SYNCOPE-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15964322#comment-15964322
]
ASF subversion and git services commented on SYNCOPE-1020:
--
Commit 4c2dd4433353a47b98fbdc4a9706ba6726b9fd44 in syncope's branch
refs/heads/master from [~ilgrosso]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=4c2dd44 ]
[SYNCOPE-1020] Implementation completed: now several sub-processes can be
managed besides the main workflow definition
> Support for BPMN call activity
> --
>
> Key: SYNCOPE-1020
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1020
> Project: Syncope
> Issue Type: Improvement
> Components: core
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 2.0.3, 2.1.0
>
>
> From the [Activiti User
> Guide|https://www.activiti.org/userguide/#bpmnCallActivity]:
> {quote}
> BPMN 2.0 makes a distinction between a regular subprocess, often also called
> embedded subprocess, and the call activity, which looks very similar. From a
> conceptual point of view, both will call a subprocess when process execution
> arrives at the activity.
> The difference is that the call activity references a process that is
> external to the process definition, whereas the subprocess is embedded within
> the original process definition. The main use case for the call activity is
> to have a reusable process definition that can be called from multiple other
> process definitions.
> {quote}
> It is currently possible to create more process definitions (besides the
> default {{userWorkflow}}) by empowering the REST endpoint
> {code}
> PUT /workflows/{anyTypeKind}
> {code}
> The new process(es) defined can then be called from the main {{userWorkflow}}
> via the {{}} element(s): the main advantage is that, by doing
> so, there are no more problems about the process definition versions, as they
> only apply to the main process (e.g. {{userWorkflow}}).
> What is currently lacking is:
> # proper management for getting all available process definitions
> # proper handling for initial loading of several process definitions from XML
> files
> # proper editing features from Admin Console
> as all the items above only consider the possibility that a single process
> definition is available.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (SYNCOPE-1065) Failure deploying with mysql/mariadb as internal storage
[
https://issues.apache.org/jira/browse/SYNCOPE-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò closed SYNCOPE-1065.
---
Resolution: Cannot Reproduce
I was not able to reproduce this issue, with both MariaDB 10.0 and 10.1 on
Linux 64 bit.
Please be sure to follow the [indications for deploying on
MariaDB|http://syncope.apache.org/docs/reference-guide.html#mariadb]; in
particular
{code}
Master.databasePlatform=org.apache.openjpa.jdbc.sql.MariaDBDictionary(blobTypeName=LONGBLOB)
{code}
> Failure deploying with mysql/mariadb as internal storage
>
>
> Key: SYNCOPE-1065
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1065
> Project: Syncope
> Issue Type: Bug
> Components: core
>Affects Versions: 2.0.3
> Environment: Real environment with MySQL/MariaDB as internal storage
>Reporter: fabio martelli
>Assignee: Francesco Chicchiriccò
>
> At DB initialization time the following exception is raised.
> Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: (conn:70)
> Specified key was too long; max key length is 767 bytes
> Query is : CREATE TABLE AccessToken (id VARCHAR(255) NOT NULL, body TEXT,
> expiryTime DATETIME, owner VARCHAR(255), PRIMARY KEY (id)) ENGINE = innodb
> {stmnt 131207471 CREATE TABLE AccessToken (id VARCHAR(255) NOT NULL, body
> TEXT, expiryTime DATETIME, owner VARCHAR(255), PRIMARY KEY (id)) ENGINE =
> innodb} [code=1071, state=42000]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SYNCOPE-1065) Failure deploying with mysql/mariadb as internal storage
[
https://issues.apache.org/jira/browse/SYNCOPE-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò updated SYNCOPE-1065:
Fix Version/s: (was: 2.0.3)
(was: 2.1.0)
> Failure deploying with mysql/mariadb as internal storage
>
>
> Key: SYNCOPE-1065
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1065
> Project: Syncope
> Issue Type: Bug
> Components: core
>Affects Versions: 2.0.3
> Environment: Real environment with MySQL/MariaDB as internal storage
>Reporter: fabio martelli
>Assignee: Francesco Chicchiriccò
>
> At DB initialization time the following exception is raised.
> Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: (conn:70)
> Specified key was too long; max key length is 767 bytes
> Query is : CREATE TABLE AccessToken (id VARCHAR(255) NOT NULL, body TEXT,
> expiryTime DATETIME, owner VARCHAR(255), PRIMARY KEY (id)) ENGINE = innodb
> {stmnt 131207471 CREATE TABLE AccessToken (id VARCHAR(255) NOT NULL, body
> TEXT, expiryTime DATETIME, owner VARCHAR(255), PRIMARY KEY (id)) ENGINE =
> innodb} [code=1071, state=42000]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
