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 for container requests 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 if no container is available. * It should show fields from the container if no container request is that are not available or don't exist on container request records. request. We also want to be able to display a work unit for a container by itself. You should 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 children of the work unit should be the 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.