Bug 993079
| Summary: | RFE: Ability to remove SCAP scans from RHN Satellite database | ||
|---|---|---|---|
| Product: | Red Hat Satellite 5 | Reporter: | Šimon Lukašík <slukasik> |
| Component: | New Feature | Assignee: | Šimon Lukašík <slukasik> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Lukas Pramuk <lpramuk> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 550 | CC: | achan, cperry, dyordano, lpramuk, tlestach, xdmoon |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | spacewalk-schema-2.0.2-4 spacewalk-java-2.0.2-41 satellite-branding-5.6.0.16-1 | Doc Type: | Release Note |
| Doc Text: |
Previously, Satellite SCAP results could not be deleted. In Satellite systems where there are a great number of SCAP scans being performed, there is a degradation in web interface performance. This has been fixed in the present version of SCAP. The Satellite/Organization administrator may now choose the period of time that a SCAP scan will be retained. When a scan falls out of the retention period, the "delete scan" link appears in the scan details page. Scans from a specific system may also be deleted via the system's scan list page.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-10-03 12:15:59 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 924171 | ||
|
Description
Šimon Lukašík
2013-08-05 15:07:30 UTC
This has been implemented in upstream project. spacewalk.git 1fae462932207..6b4ccd7994780 spacewalk.git 7d06206839128..dd1d0122387a7 spacewalk.git 0f60532652c4e Scope of the work done and the test plan: General Info ------------ We do not allow deletion of SCAP results by default. The deletion has to be explicitly allowed for each organization in the Organization Configuration dialog (or using org.setPolicyForScapResultDeletion() API). User can specify retention period (in days) for each organization, default is 90 days (arbitrary choice). Only those SCAP Scans can be deleted which have passed their retention period. Changes to WebUI ---------------- The choice of retention period has been added to Organization Configuration dialog (admin/multiorg/OrgConfigDetails.do). If the given scan can be deleted, the 'delete scan' link appears at the Scan's details page toolbar (systems/details/audit/XccdfDetails.do). This link redirects to deletion confirmation page (systems/details/audit/XccdfDeleteConfirm.do). At the page which lists all the scans for the given single system (systems/details/audit/ListScap.do), there are select boxes added. User is able to select any scans and hit <Remove Selected Scans> button. The button again redirects to a confirmation page. If the scan is deleted, any assigned files (detailed results) are deleted as well. Added Frontend API ------------------ system.scap.deleteXccdfScan() org.getPolicyForScapResultDeletion() org.setPolicyForScapResultDeletion() + added 'deletable' property to system.scap.getXccdfScanDetails() result dict. VERIFIED. At least for now ;-) Verified webui funcionality together with API funcionality. Missing API calls are in place. (comment #8) spacewalk-schema-2.0.2-13.el5sat spacewalk-java-2.0.2-46.el5sat satellite-branding-5.6.0.22-1.el5sat BUT, I don't like the feeling it ignores me somehow, see: API: >>> client.org.setPolicyForScapResultDeletion(key, 1, {'retention_period': 15, 'enabled': False}) 1 >>> client.org.getPolicyForScapResultDeletion(key,1) {'retention_period': 0, 'enabled': False} 'retention_period': 0 !!! Oh, no, it simply discarded retention period when switching to false WEBUI: same behavior - unchecking Allow Deletion of SCAP Results: [_] will discard value of Allow Deletion After (period in days) and set it to 90 days. Possibly new BZ... Possibly? No, definitely ;-) On behalf of comment #17 filed new bz #1016675 |