OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (CAMP-217) Use cases for "Row Filtering"


    [ https://issues.oasis-open.org/browse/CAMP-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62699#comment-62699 ] 

David Laurance commented on CAMP-217:
-------------------------------------

Assigned this to Gil.  As agreed, we're jointly responsible, but I am owner so I can already track it.

> Use cases for "Row Filtering"
> -----------------------------
>
>                 Key: CAMP-217
>                 URL: https://issues.oasis-open.org/browse/CAMP-217
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Improvement
>            Reporter: David Laurance
>            Assignee: Gilbert Pilz
>            Priority: Minor
>
> Use cases for filtering collections can be broken into three groups
> 1. In displaying a long collection, an end user may want to filter on some attribute or attributes of the collection elements: 
>     * As a cloud administrator, I want to view only the Assemblies that are currently in an Active state. 
>     * As a cloud administrator, I want to view only the Assemblies that were created from a specific Plan. 
> (Note that for smaller Cloud installations, Sort functionality will provide an adequate substitute for use cases in this category.) 
> 2. In displaying a long collection, a user may want to filter elements on attributes that are not directly available from the elements; for example, filtering Assemblies based upon attributes associated with their corresponding Plans.
>     * As a cloud administrator, I want to view Assemblies that trace to a specific Plan version.
> 3.  In order to meet data visibility requirements, a provider may be required to filter collection elements to reflect visibility rules, and show only those elements that a user is allowed to see. 
>  In this case, visibility is not requested by the user, but rather it is determined by the server, based upon the user identity or other user attributes. 
> We have agreed that ownership of collections will not be managed within the CAMP model. If ownership or other permission attributes are required, they must be associated with collection elements by a separate mapping or mechanism, and any policy engine or other access control mechanism must understand and use that mechanism. 
>  However, note that the server must be able to determine the user identity or other user attributes in order to evaluate and enforce access control rules. If requests are truly stateless, this will mean that user attributes (at a minimum, user identity) must be provided in the user's request for the collection. If session state is maintained so that the server can track a session across requests, then it is possible for the server to authenticate a user in a separate interaction and rely on session identity to track the user and authorize user access. 



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]