Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 972923

Summary: uploads erratum doesn't check the updated and issued parameters for the proper format
Product: [Retired] Pulp Reporter: Jeremy Cline <jcline>
Component: rpm-supportAssignee: pulp-bugs
Status: CLOSED DUPLICATE QA Contact: Preethi Thomas <pthomas>
Severity: unspecified Docs Contact:
Priority: low    
Version: 2.2 BetaCC: jason.dobies, mhrivnak, nobody
Target Milestone: ---Keywords: Triaged
Target Release: 2.6.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-12-01 17:24:52 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jeremy Cline 2013-06-10 19:58:36 UTC
Description of problem: According to the CLI, the --updated and --issued options of the 'pulp-admin rpm repo uploads erratum' command expect the format "YYYY-MM-DD HH:MM:SS". However, this is not checked, and no sort of error is reported.


Version-Release number of selected component (if applicable): pulp-rpm-admin-extensions-2.2.0-0.2.beta.fc18.noarch


How reproducible:


Steps to Reproduce:
1. pulp-admin rpm repo create --repo-id=uploads_errata
2. create a fake pkglist csv in the format "name,version,release,epoch,arch,filename,checksum,checksum_type,sourceurl"
3.pulp-admin rpm repo uploads erratum --repo-id=uploads_errata --erratum_id=test_id --title="Title of the Erratum" --description="A terse description of the erratum" --version=1.0.0 --release=stable --type=enhancement --status=final --updated="A long, long time ago" --issued="The day after tomorrow" --pkglist-csv=/home/jcline/fake_pkg_csv --from="someone"

Actual results: The erratum is created and uploaded.


Expected results: Error message indicating the updated and issued fields are not of the expected format ("YYYY-MM-DD HH:MM:SS")


Additional info:

Comment 2 Jeremy Cline 2014-12-01 17:24:52 UTC

*** This bug has been marked as a duplicate of bug 1101597 ***