MozillaSecurity / MozillaSecurity/FuzzManager
[EC2SpotManager] PoolConfiguration user action history should be accessible.
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 208
- Forks
- 48
- Avg merge
- 23h 5m
- Merged PRs (30d)
- 2
Description
It would be useful to know when changes are made to PoolConfigurations and by whom. We should log this and show it in the web interface.
class PoolConfigurationChangeEvent(models.Model):
config = models.ForeignKey(PoolConfiguration)
user = models.ForeignKey(User)
timestamp = models.DateTimeField(default=timezone.now)
action = models.CharField(max_length=4096, blank=False)
The log history would be trimmed in a periodic task, so that history is kept for one month, but the latest entry is never removed.
These should be applied downwards in the hierarchy. ie. if a is parent to b, and a is edited, the edit should show up in the log of both a and b (assuming the edit affected b after flattening).
The algorithm might look like this:
affected configs = [target] + [all configs inheriting from target]
old configs = serialize all affected configs (flattened)
make change to target
for all affected configs
if old config != new config (flattened)
generate change event
And I propose to display this history in the PoolConfiguration view in a simple preformatted div like a log.
[YYYY-mm-dd HH:MM:SS][user@email.com] action
Where action might look like:
created
size: 1 -> 2, ec2_allowed_regions += [us-east-2], ec2_userdata changed
ec2_userdata changed (via ancestor %d)
It won't be possible to perfectly capture changes (eg. value removed from dict reverts to parent value), but it should be enough information to track down bad changes.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating the PoolConfiguration model, its hierarchy-flattening logic, the PoolConfiguration web view, and the periodic-task entry point. Trace how edits propagate from a target to inheriting configurations before deciding where change events belong. Done means affected configurations record attributable changes, history is retained for one month with the latest entry preserved, and the web view displays the log.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- django, python
- Domain
- backend, database, frontend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100