I think eventually getting to the point where we don't need to specify the specific keys for the special groups would be great but this isn't going to happen for 3.0 and likely would happen as part of integrating stand-along GAP which will likely be part of 3.1. Looking at the stand-alone code I think there are several possibilities for reducing the need to configure these keys.
Another option would be to add an additional group_key field for local groups beyond the synthetic group_id and descriptive name which would be human-readable and unique, similar to what fnames are used for. I think this pattern of having a unique synthetic key used for referencing in the database and code and a unique human-readable key is something we want to look into for all of the portal to make import, export and access easier.
I'll create some jira issues from this thread and schedule them for 3.1 -Eric Dan Ellentuck wrote:
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=43464It 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
smime.p7s
Description: S/MIME Cryptographic Signature
