Review of write_only fields in pulp and plugins
In #6346, we are trying to fix the problem where write_only fields are not showing up in the api schema. We think though that most of the use of write_only fields are unnecessary. In some cases, a serializer with write_only fields can be split in two: one for read operations and one for write operations. In other cases, write_only fields can be converted to SecretCharFields.
This task is to go through and try to eliminate write_only field usage when possible. From there we can examine which use cases still require use of write_only fields.
write_only still in use:
SingleArtifactContentSerializerOK, since there is no
relative_pathin the database model. Also it is dynamically deactivated.
PulpExportSerializer. Obviously ok, as this will not persist in the db.
PulpExportSerializer. Should those values be persisted?
add/remove_content_units' on theRepositoryAddRemoveContentSerializer`. Is this a POST-only serializer?
UploadChunkSerializer. OK, special case for file uploads.
UploadSerializerFieldsMixin. OK, special case for file uploads and the repository being used for a non exclusive convenience association.
GemContentSerializer. Could use the UploadSerializerFieldsMixin. Artifact is special here.
RecursiveManageSerializer. Probably a POST-only serializer.
CopySerializer. Probably a POST-only serializer.
OCIBuildImageSerializer. Probably a POST-only serializer.
#12 Updated by email@example.com 3 months ago
We need to remove the write_only designation on the RepositoryAddRemoveContentSerializer serializer fields in pulpcore.
We need to remove the write_only designation on the OCIBuildImageSerializer, CopySerializer, RecursiveManageSerializer serializers in pulp_container.
Please register to edit this issue