Hi David,
This sounds like a great set of code, I'm sure we are going to
realize
we want it sooner or later! Unfortunately I can't consume code in this
way (I can't propose code written by somebody else) and I can't spend
significant time on it right now.
Would you or Anton be willing to propose whatever code and
documentation
you have to Horizon? It doesn't have to be complete; it doesn't need to
have grammar cleaned up or anything like that. You could mark it as a
"Work in progress", and make it clear in the commit message that you
aren't planning further work on this, so the patch is available for
adoption. That way somebody else may be able to pick this up and
work on
it in the future, but Anton could get credit for the work he has done.
Doug Fish
----- Original message -----
From: David Chadwick <[email protected]>
To: OpenStack Development Mailing List
<[email protected]>
Cc:
Subject: [openstack-dev] [horizon][keystone]
Date: Tue, Oct 6, 2015 2:13 PM
Dear All
One of my students, Anton Brida, has developed an Attribute
Mapping GUI
for Horizon as part of his MSc project. Attribute mappings are an
essential, though complex, part of federated Keystone.
Currently they
can only be created as JSON objects in the config file. The
Horizon code
allows them to be dynamically created via an easy to use GUI.
Since Anton has now left the university for full time
employment, he is
not able to go through the process of submitting his code to
the next
release of Horizon. His design however was submitted to
InVision and
commented on by various people at the time of the development.
I am now looking for someone who would like to take a copy of
this code
and go through the process of submitting this to the next
release of
Horizon. I have a copy of Anton's MSc dissertation as well which
explains the work that he has done.
All the attribute mapping features are supported in Anton's code
(groups, users, direct mapping, multiple attribute values etc.)
However the whitelist/blacklist feature is not, since this was
not fully
incorporated into Keystone when Anton was doing his
implementation. (I
am still not sure if it has been.)
The code has a couple of known bugs:
1. when a user tries to enter an email address into an
attribute value
(i.e. [email protected]) and saves the mapping rule into the
database, after reloading the new list of mappings rules the
interface
does not work as intended. The particular reason why this is
happening
is yet unknown. The only way to avoid such disruption is to
delete the
faulty mapping rule from the table. After removing the faulty
rule the
interface works as intended.
2. Some of the descriptive text needs improvement due to incorrect
grammar.
There is also the following suggested enhancement which can be
added
later:
1. After the mapping rules are created with the GUI, when they are
displayed, they are still in JSON format. It would be nice to
be able to
display the rules in a table or similar.
If you would like to take on the job of submitting this code to
Horizon
for review and incorporation, please contact me
regards
David
__________________________________________________________________________
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
