Idea #9372
Updated by Peter Amstutz almost 8 years ago
These pages currently use the default property rendering. They should be updated to use the work unit layout used by jobs and pipelines: /container/<uuid> /container_request/<uuid> Work units The work unit for container requests @container_request@ should logically combine both the container request and underlying container (if available). This means: * It should return and display both fields when the container request and container differ. * It should show fields from the container request have @container_uuid@ as a child work unit, if no container is available. * It should show fields from the container that are not available on container request. We also want to be able to display a The work unit for a container by itself. You may want to implement the combined container/container request work unit in a way so that either the underlying container and container request fields can be nil. When there is a container defined for the work unit, the @container@ should list as children of the work unit should be the container requests any @container_requests@ which have the parent container in "requesting_container_uuid". The work unit for @container_request@ should allow "cancel" behavior. If the user pushes "cancel", it should set "priority = 0" on the container request. Containers themselves cannot be canceled directly and should not present a cancel button. Finally, a container will be referenced by one or more container requests, so the individual container page should link to the container requests it is associated with. This may be something that goes into the template for containers specifically and not part of the work unit code. 0".