Project Standards Requests

When a Draft is linked to a Standard Library draft, any explanations for deviations from the standards may be explained and the explanation either approved, conditionally approved or denied (see Explaining and Approving Differences).

The Project Standards Requests page has as tab for each of these states where all Explanations with that state are listed.

Users with the permission to Approve standards requests may move explanations between the states, typically from an Approval Requested state to one of the Approved, Conditionally Approved or Denied states.

Obsolete Requests

As users make changes to objects in the drafts of the project they may request approval for changes made (e.g. making a field inactive) and later revert that change. If the same draft object in other drafts does not have this change then the request for approval becomes "obsolete", meaning that it's a request for a change that is no longer valid since no object actually has that change.

Similarly, obsolete requests might become active again if the change is re-introduced. In that case, the request for approval is for a valid change and so should be considered for approval by a standards manager user.

The TrialGrid System tracks changes to objects and updates the obsolete status of explanations.

Renaming an object also makes its requests obsolete

A request for approval is matched to the object it explains by that object's identifier. Renaming the object therefore leaves the request describing a name that no object answers to, and it becomes obsolete in exactly the same way as a change that was reverted - the deviation it explains is no longer there to explain.

This includes renames the user may not think of as renaming an object at all. A Custom Object's identifier is built from the values of its identifier properties, so renaming, merging, converting or deleting one of those values moves the identifiers of every object built from it, and the requests recorded against the old identifiers become obsolete together. See Effects of a Bulk Value Change.

Nothing is lost when this happens. The request keeps its explanation and its approved, conditionally approved or denied state, and becomes active again by itself if the identifier returns - for example if the value is renamed back.

Forcing recalculation of Obsolete / Reactivated Requests

In the event that TrialGrid System does not correctly update the obsolete status of explanations it is possible to use the Identify Obsolete button on the Project list page to update the obsolete status of explanations on that page/tab. For example, clicking the button on the Approved tab will recalculate the obsolete status of the Approved requests listed there.