October 2014 - overlord-issues - Jboss List Archives

[JBoss JIRA] (RTGOV-556) RTGov UI no longer working on FSW 6.0

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/RTGOV-556?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on RTGOV-556: ----------------------------------------------- George Varsamis <gvarsami(a)redhat.com> changed the Status of [bug 1146206|https://bugzilla.redhat.com/show_bug.cgi?id=1146206] from ASSIGNED to ON_QA > RTGov UI no longer working on FSW 6.0 > ------------------------------------- > > Key: RTGOV-556 > URL: https://issues.jboss.org/browse/RTGOV-556 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > Attachments: overlord-rtgov-elasticsearch.properties > > > RTGov UI beta 1 worked on FSW 6.0, but subsequent changes to rtgov have caused it to stop working. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (OVERLORD-154) Move shared Elasticsearch functionality from rtgov into commons

by Gary Brown (JIRA)

Gary Brown created OVERLORD-154: ----------------------------------- Summary: Move shared Elasticsearch functionality from rtgov into commons Key: OVERLORD-154 URL: https://issues.jboss.org/browse/OVERLORD-154 Project: Overlord Issue Type: Task Reporter: Gary Brown Assignee: Gary Brown Fix For: Overlord-Commons-2.0.12.Fina Move the Elasticsearch functionality, currently used in rtgov, that is of common use to other Overlord projects. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-594) Move common Elasticsearch capabilities into overlord-commons

by Gary Brown (JIRA)

Gary Brown created RTGOV-594: -------------------------------- Summary: Move common Elasticsearch capabilities into overlord-commons Key: RTGOV-594 URL: https://issues.jboss.org/browse/RTGOV-594 Project: RTGov (Run Time Governance) Issue Type: Task Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.1.0.Final Move Elasticsearch functionality that may be of use to other overlord projects into overlord-commons. This could include the basic Elasticsearch client code (and configuration) and the proxy REST service for adding authentication support when accessing the Elasticsearch server. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-593) UX: Make filtering more full-text

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-593?page=com.atlassian.jira.plugin.... ] Gary Brown reassigned RTGOV-593: -------------------------------- Assignee: ivan mckinley (was: Gary Brown) Any thoughts Ivan? I know the elasticsearch has a score associated with a search - do we need to make this configurable? Although wondering whether increasing the score may improve the situation with example (2), but possible make it worse for (1). > UX: Make filtering more full-text > --------------------------------- > > Key: RTGOV-593 > URL: https://issues.jboss.org/browse/RTGOV-593 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: User Interface > Affects Versions: 2.0.0.Final > Reporter: Andrej Vano > Assignee: ivan mckinley > Fix For: 2.1.0.Final > > > The filtering in the UI is a bit confusing, here are some examples: > 1. Have 1 situation with subject "{urn:switchyard-soa:rtgov_console:1.0.0}OrderService|submitOrder" > If I want to filter by the subject the results are: > - "o" - no situations > - "or" - no situations > - "ord" - no situations > - "orde" - no situations > - "order" - no situations > - "orders" - no situations > - "orderse" - no situations > - "orderser" - no situations > - "orderserv" - finally the situation is found > This is why I set it as a bug: > 2. Have 4 situations with descriptions "CPS", "HPS", "MPS", "LPS" representing "Critical Priority Situation" etc. > If I want to filter these situations by description: > - "h" - no situations > - "hp" - no situations > - "hps" - All 4 situations returned -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-593) UX: Make filtering more full-text

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/RTGOV-593?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated RTGOV-593: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1150870 > UX: Make filtering more full-text > --------------------------------- > > Key: RTGOV-593 > URL: https://issues.jboss.org/browse/RTGOV-593 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: User Interface > Affects Versions: 2.0.0.Final > Reporter: Andrej Vano > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > The filtering in the UI is a bit confusing, here are some examples: > 1. Have 1 situation with subject "{urn:switchyard-soa:rtgov_console:1.0.0}OrderService|submitOrder" > If I want to filter by the subject the results are: > - "o" - no situations > - "or" - no situations > - "ord" - no situations > - "orde" - no situations > - "order" - no situations > - "orders" - no situations > - "orderse" - no situations > - "orderser" - no situations > - "orderserv" - finally the situation is found > This is why I set it as a bug: > 2. Have 4 situations with descriptions "CPS", "HPS", "MPS", "LPS" representing "Critical Priority Situation" etc. > If I want to filter these situations by description: > - "h" - no situations > - "hp" - no situations > - "hps" - All 4 situations returned -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-593) UX: Make filtering more full-text

by Andrej Vano (JIRA)

Andrej Vano created RTGOV-593: --------------------------------- Summary: UX: Make filtering more full-text Key: RTGOV-593 URL: https://issues.jboss.org/browse/RTGOV-593 Project: RTGov (Run Time Governance) Issue Type: Bug Components: User Interface Affects Versions: 2.0.0.Final Reporter: Andrej Vano Assignee: Gary Brown Fix For: 2.1.0.Final The filtering in the UI is a bit confusing, here are some examples: 1. Have 1 situation with subject "{urn:switchyard-soa:rtgov_console:1.0.0}OrderService|submitOrder" If I want to filter by the subject the results are: - "o" - no situations - "or" - no situations - "ord" - no situations - "orde" - no situations - "order" - no situations - "orders" - no situations - "orderse" - no situations - "orderser" - no situations - "orderserv" - finally the situation is found This is why I set it as a bug: 2. Have 4 situations with descriptions "CPS", "HPS", "MPS", "LPS" representing "Critical Priority Situation" etc. If I want to filter these situations by description: - "h" - no situations - "hp" - no situations - "hps" - All 4 situations returned -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-590) StoredQueryWorkspace must include all available queries in its app:collection

by Brett Meyer (JIRA)

Brett Meyer created SRAMP-590: --------------------------------- Summary: StoredQueryWorkspace must include all available queries in its app:collection Key: SRAMP-590 URL: https://issues.jboss.org/browse/SRAMP-590 Project: S-RAMP Issue Type: Sub-task Reporter: Brett Meyer Assignee: Brett Meyer -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-590) StoredQueryWorkspace must include all available queries in its app:collection

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-590?page=com.atlassian.jira.plugin.... ] Brett Meyer updated SRAMP-590: ------------------------------ Description: {quote}The workspace for the query artifact model MUST contain an app:collection element for each Stored Query that exists in the S-RAMP implementation.{quote} > StoredQueryWorkspace must include all available queries in its app:collection > ----------------------------------------------------------------------------- > > Key: SRAMP-590 > URL: https://issues.jboss.org/browse/SRAMP-590 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > > {quote}The workspace for the query artifact model MUST contain an app:collection element for each Stored Query that exists in the S-RAMP implementation.{quote} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-169) Organization hierarchy

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-169?page=com.atlassian.jira.plugin.... ] Brett Meyer commented on SRAMP-169: ----------------------------------- Converting to separate Feature Request. Not required by the spec. > Organization hierarchy > ---------------------- > > Key: SRAMP-169 > URL: https://issues.jboss.org/browse/SRAMP-169 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Gary Brown > Assignee: Kurt Stam > > The SRAMP spec defines an Organization entity (derived from HumanActor) that can be related to a ServiceImplementation using the 'provides' relationship. > In large organizations it may be necessary to define more of a organizational structure, to correctly associate the services with the appropriate business units, departments, etc. that are responsible for the service. > The other issue is whether a 'provides' relationship is enough. This may indicate the implementers of the service, but not necessarily the support contact if there is a problem with the service. So potentially there should also be a 'supports' relationship that can optionally be used where the support is provided by a different team. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-169) Organization hierarchy

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-169?page=com.atlassian.jira.plugin.... ] Brett Meyer updated SRAMP-169: ------------------------------ Parent: (was: SRAMP-462) Issue Type: Feature Request (was: Sub-task) > Organization hierarchy > ---------------------- > > Key: SRAMP-169 > URL: https://issues.jboss.org/browse/SRAMP-169 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Gary Brown > Assignee: Kurt Stam > > The SRAMP spec defines an Organization entity (derived from HumanActor) that can be related to a ServiceImplementation using the 'provides' relationship. > In large organizations it may be necessary to define more of a organizational structure, to correctly associate the services with the appropriate business units, departments, etc. that are responsible for the service. > The other issue is whether a 'provides' relationship is enough. This may indicate the implementers of the service, but not necessarily the support contact if there is a problem with the service. So potentially there should also be a 'supports' relationship that can optionally be used where the support is provided by a different team. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

overlord-issues October 2014