Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

organizationIssueRecord

MethodgetHoldCreatorOrganizationIds
DescriptionGets the list of Organization Ids who can create Holds using this Issue.
Returnosid.id.IdListthe list of Organization Ids
CompliancemandatoryThis method must be implemented.
MethodgetHoldCreatorOrganizations
DescriptionGets the list of Organizations who can create Holds using this Issue.
Returnosid.personnel.OrganizationListthe list of Organizations
ErrorsOPERATION_FAILEDunable to complete request
CompliancemandatoryThis method must be implemented.
MethodgetHoldUpdaterOrganizationIds
DescriptionGets the list of Organization Ids who can update Holds of this Issue.
Returnosid.id.IdList the list of Organization Ids
CompliancemandatoryThis method must be implemented.
MethodgetHoldUpdaterOrganizations
DescriptionGets the list of Organizations who can update Holds of this Issue.
Returnosid.personnel.OrganizationList the list of Organizations
ErrorsOPERATION_FAILED unable to complete request
CompliancemandatoryThis method must be implemented.

With this data the service architect believes she can create the proper Authorizations. But how? 

Code Block
public org.osid.hold.Issue createIssue(org.osid.hold.IssueForm form) {
    foreach (org in getHoldCreatorOrganizationIds) {
        foreach (person in org) { // insert complexity from first iteration here
            createAuthorization(person, function, newIssue);
        }
    }
    ....
}

This doesn't seem right. This is worse than the code from the first iteration. Yes, it's now in the service provider but it fixes the membership such that if the organization changes, the authorization service is out of date. 

It appears that the Organization OSID is important but it has no idea about hold authorizations. Resolving the organization above the Hold OSID looks terrible and resolving it within the Hold OSID Provider isn't an improvement. There's only one service left.

It's A Song About Alice