Sorry, I hit send by accident before I was done.

Hi Eric, et. al.,

I think this question boils down to what's the best way to enforce a single namespace for group aliases. You can search for a group by name, but as we know, unique names are not required or enforced. Or you can declaratively alias a group or groups to a particular symbolic name. In the composite group service bean in spun-off gap there is a Map of symbolic names and their related group keys:

       <!--
        |  Declare DISTINGUISHED GROUP KEYs here.
        |  These are simply aliases for group keys
        |  that are known to the group service.  (A

        |  single group can have more than one
        |  alias.)  At runtime, a distinguished group
        |  can be retrieved from the service
        |  using getDistinguishedGroup(String name).
        |  Note that in the Map defined below,
        |  the entry key is the ALIAS and the entry
        |  value is the GROUP KEY.
        -->
            <property name="distinguishedGroupKeys">
              <map>
                <entry key="Everyone">
                  <value>local.0</value>
                </entry>
                <entry key="Everyone-Redux">
                  <value>local.0</value>
                </entry>
                <entry key="Students">
                  <value>local.1</value>
                </entry>
              </map>
            </property>

These symbolic (or "DISTINGUISHED") names are different from
the names returned by IEntityGroup.getName().

If it makes sense, we could backport something like this to earlier versions of GaP in uPortal.

   Dan


Eric Dalquist wrote:
Thanks for the update. I have a few ideas for getting rid of the explicit configuration tie to the synthetic group IDs.

1. Switch to just using well known names. An example would be "All uPortal Users" for everyone, "All uPortal Channels" for all channels and "uPortal Administrators" for admins. Some effort would need to be done in the composite group store to prevent these groups from being created by users for security reasons which may be a bit of a road block.

2. Move the config into the database. A table could contain a known real id and the corresponding synthetic id of the designated group. This information could more easily be exported and would reduce the configuration tie to specific group keys.

Thoughts from any devs out there?
-Eric


Drew Wills wrote:
Eric,

I updated dbunload,crn per our discussion on IRC: http://developer.ja-sig.org/source/changelog/jasigsvn/?cs=43464

It still needs some attention, though...

There are 3 rows defined in the UP_GROUP.default-data.xml file, each of which refers to an EntityType by Id: IPerson or IChannel. We either need to include a .default-data.xml file that defines these dependencies, or remove the need for 'Everyone', 'Portal Administrators', and 'All Channels' to have specific Ids.

drew



--
Join your friends and colleagues at JA-SIG 2008 - "Higher Education Solutions: The 
Community Source Way!"
April 27th - 30th, 2008 in St. Paul, Minnesota USA

Featuring CAS, DSpace, Fedora, Fluid, Internet2, Kuali, Sakai, uPortal, and 
more!
Information/Registration at: 
http://www.ja-sig.org/conferences/08spring/index.html

Subscribe to the conference blog, The Community Source Way
http://jasig2008.blogspot.com, for news and updates about the  event.

Join the Conference networking site at http://ja-sigspring08.crowdvine.com/

You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL 
PROTECTED]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Reply via email to