How about a settings.py switch that would simply allow the deployer to
entirely disable the list users functionality?
Best,
-jay
On 08/18/2015 12:52 PM, Timur Sufiev wrote:
IMO, if that's impossible to provide Users pagination/indexing for LDAP
from technical point of view, we'd better revise the current UI of
Identity->Users, since most likely production-grade OpenStack
installations will have LDAP instead of MySQL storage. So I'm for
gathering more operators/deployers feedback on the pagination (Users
panel particularly).
I'm inclined to revising existing UI not because I think the Keystone
community is adamant in doing things the way they're going to, but
because LDAP storage backend seems to be unavoidable for large OpenStack
deployments and Horizon shouldn't ignore this fact (what's the point in
having fancy UI when it's broken for real-world installations?). Of
course, 'unavoidable' thing is open to discussion.
On Tue, Aug 18, 2015 at 6:30 AM Adam Young <[email protected]
<mailto:[email protected]>> wrote:
On 08/17/2015 09:53 PM, David Lyle wrote:
I think we've conveniently been led off track here. The original
request/subject was regarding pagination of projects in the v3
API. Since this is purely a keystone construct it seems
implausible to me that ldap or the IdP of choice would be limiting
the ability to return a paginated list of all projects. Or groups
or domains or roles for that matter.
Yeah, SQL can support it. LDAP assignment can't. But that is not
going to have a long life.
With Hierarchical projects, we'll probably also have to keep nesting
in mind for how we display a project list: do we always show a flat
list, or is a tree closer to what users expect?
Both are going to work poorly for some deployments and work well for
others.
There is no reason to punt on pagination across the API for one
resource type, which actually would also work with select
backends. Give me something that I can exhaustively list in the
API I can build from.
David
On Aug 17, 2015 10:53 AM, "Fox, Kevin M" <[email protected]
<mailto:[email protected]>> wrote:
1. yes, but probably only if its a short list. It may be
feasible to show it only if there are 5 or less pages, and
maybe just load all pages of data and paginate it on the
client. If too big, ask the user to refine their search? Or
always paginate to 5, and then the 6th page have a page
requesting further refinement?
2. Not sure what the difference between searching and
filtering is in this context? something like facets? If so,
probably the 5 or less thing would work here too.
3. Yes, but again, probably within a smaller set of pages?
Thanks,
Kevin
________________________________________
From: Kruithof, Piet [[email protected]
<mailto:[email protected]>]
Sent: Sunday, August 16, 2015 9:41 AM
To: [email protected]
<mailto:[email protected]>
Subject: Re: [openstack-dev] [UX] [Keystone] [Horizon]
Pagination support for Identity dashboard entities
I like Michael’s response because it moved the thread towards
identifying actual user needs before digging into the
technical feasibility. IMHO, it would be helpful to have a
few people on the list answer his questions:
1 - Do users want to page through search results?
2 - Do users want to page through filter results? (do they use
filter results?)
3 - If they want to page, do they want to be able to go back a
page and/or know their current page?
I understand that even if we answer “yes” to all three
questions that there could be issues around implementation,
but at least we’ll know a gap exists.
Piet Kruithof
Sr UX Architect, HP Helion Cloud
PTL, OpenStack UX project
"For every complex problem, there is a solution that is
simple, neat and wrong.”
H L Menken
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:[email protected]?subject:unsubscribe
<mailto:[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
