User Story #323 (closed)
Opened 18 years ago
Closed 18 years ago
Add subsystem disabling to SecuritySystem
| Reported by: | jamoore | Owned by: | jamoore |
|---|---|---|---|
| Priority: | trivial | Milestone: | 3.0-M3 |
| Component: | Security | Keywords: | iteration5,REVIEW, LATER |
| Cc: | Story Points: | n.a. | |
| Sprint: | n.a. | Importance: | n.a. |
| Total Remaining Time: | n.a. | Estimated Remaining Time: | n.a. |
Description
Certain backend/subsystem tasks such as object loading, flushing, committing, etc. can sometimes happen at unexpected times, (i.e. "lazily"). In order to get control over this, it would help to be able to "disable" certain operations for a limited period of time. (Conceivably, certain tasks could also be disabled for particular users.)
The original idea for this comes from the (misdiagnosed) issue described under #322.
Change History (4)
comment:1 Changed 18 years ago by jmoore
comment:2 Changed 18 years ago by jmoore
Subsumes #233.
comment:3 Changed 18 years ago by jmoore
- Keywords iteration5 added; iteration4 removed
Moving to iteration 5 for review. May need to be postponed. May or may not be necessary for security reworking (#328)
comment:4 Changed 18 years ago by jmoore
- Keywords REVIEW LATER added
- Resolution set to fixed
- Status changed from new to closed
As seen with #366 disabling is working, but will have to be configured on a case by (use) case basis. Eventually, we'll want to refactor it and probably create a Subsystems object with an enum of all the types which can more efficiently test for enabled/disabled systems than a Set.contains() lookup. For now, works great.
r910 provides a pretty naive implementation. It would be better to have a SubSystems class which provided all necessary keys. And depending on the overhead, it could even be useful to have wildcard matching.