Page Comparison

...

// ResourceGroupSession - gets the list of "people" in a "organization of people who can create holds"
public getResourcesByGroup(org.osid.id.Id groupResourceId) {
    // assumption: groupResourceId is an org Id
 
    java.util.Collection<org.osid.resource.Resource> ret = new java.util.ArrayList<>();
    try (org.osid.personnel.PositionList positions = positionLookupSession.getPositionsForOrganization(groupResourceId)) {
        while (positions.hasNext()) {
            org.osid.personnel.Position position = positions.getNextPosition();
            // can add a filter on a type of position
            try (org.osid.personnel.AppointmentList appointments = appointmentLookupSession.getAppointmentsForPosition(position.getNextId()) {
                 if (appointments.hasNext()) {
                    ret.add(convertPerson2Resource(position.getPerson()));
                }
            }
        }
    }
 
    return (new net.okapia.osid.jamocha.resource.resource.ArrayResourceList(ret));
}

...

Wait a minute...

What Was The Question?

These iterations make an assumption. The assumption is part of the original functional requirement basing authorizations on organizations. It assumes that authorizations are completely derived from job positions and the organizational hierarchy.  If this is the case, then in order to grant access to or remove a person from this authorization either requires changing their job appointments or having a conversation with the Authorization OSID or the Resource OSID directly. 

The service architect poses the question to the product owner who reiterates that the authorizations should be based on organizations. When she asks if there are any exceptions to the organization rule, the product owner reports that these exceptions do exist but the project can iterate on the development of that feature later. However, the service architect wants to nail down the services to which application will interface and contain development iterations to within those boundaries.