> > > I have double checked with Galen and more than two contacts can be > > attached, the schema specifies those two contacts as a minimum. The > > API I implemented allows accessing the poc and metadata_author objects > > as layer properties so the use is not complicated by having the more > > liberal many-to-many relationship and we get the benefit of being able > > to use the layer/contact/role/permission architecture to allow some > > level of per-object permissions based on the contact role. > > These shortcut methods will error if, for whatever reason a layer, has > more than one poc or metadata_author. It doesn't seem unreasonable to > expect multiple of either, so if we are going this way then we should > probably ditch the properties and make developers deal with the idea > that there might be more than one party playing any particular role for > any particular layer. Otherwise, we should add a uniqueness constraint > on ContactRole on (layer, role). >
Is there a way to write the shortcut method in a way that it doesn't fail when there are multiple authors? Maybe return them all in a collection, or else return just one of them? I am concerned about some related user interface recommendations according to which in certain places (on the Data grid, for example). According to these designs, these rows have an "Author" or "Owner" column that has a singular name in it. So far, nobody has specified the logic for choosing one of many points of contact or authors as the primary owner of a resource. What I'm trying to figure out is whether this is a flaw in our design, or whether there is some kind of appropriate logic for determining this. Maybe a hierarchy of the "roles" used in the metadata could be used to select the person who is _most_ responsible for the resource. This could easily be an orthogonal point, but it could also be a point of inspiration. <snip cause="already in the repo!">bit about using a fixture for > roles</snip> > > Everything else looks good to me too[1]. Let's figure out how we want > to handle contacts before merging this into master though. > [1] Well, we might have some issues with caching logged-in-ness across > all GeoServer/GeoNetwork access later, but we can deal with that when/if > it becomes a problem. It's not a new issue anyway. > > -- > David Winslow > OpenGeo - http://opengeo.org/ > > > -- Sebastian Benthall OpenGeo - http://opengeo.org
