0001555: Violations that have been deleted are selectable from PF::Violation::Add or PF::Violation::Edit - PacketFence

(0003081)
fgaudreault (viewer)
2012-09-20 07:33

Log out the UI and log back in. You won't see them anymore.

(0003082)
mada (reporter)
2012-09-20 08:52

I've tried:
-Logging out
-Closing the browser entirely
-Flushing the browsers cache
-Using a different browser
-Using a different system

And the entries still appear.

(0003083)
fgaudreault (viewer)
2012-09-20 08:57

try:
- pfcmd reload violation
- log off
- log on

(0003084)
mada (reporter)
2012-09-20 09:05

Gave 'pfcmd reload violations' a shot then retried the 5 steps in my previous note, the deleted entries are still there.

(0003087)
obilodeau (reporter)
2012-09-20 10:57

Wow, if this is a regression I think it was introduced a long time ago and I'm actually surprised that we weren't bitten by this earlier..

Grepping the code history it looks it never worked. class_delete or class_cleanup where never really called. I remember tweaking some startup code but not sure if it was related and not able to find it.

Can you crank up the logs in conf/log.conf to TRACE and do a pfcmd reload violations. Then attach the log here. I'll see if I'm missing something.

(0003088)
mada (reporter)
2012-09-20 11:45

Sure thing, the log's attached. (I cleaned it up a bit, just the DHCP info.)

----
(Also fixed the
Sep 20 11:34:18 pfcmd(27110) ERROR: attempt to add existing trigger 806 806 [os] (pf::trigger::trigger_add)
error - just had the trigger in there twice, as it says.)

(0003173)
fgaudreault (viewer)
2012-10-19 13:45

We need to try reproducing this in the lab. Transfered to the investigate queue.

(0003219)
fgaudreault (viewer)
2012-10-22 14:48

Confirmed Bug, the violation is still available when doing a violation add. Reproduced in the lab using 3.6.0-devel.

I remember that we had another report about the violation reload not being agressive enough. The database is not flushed properly when you delete a violation. I'll check to see if it's a simple fix.

(0003220)
fgaudreault (viewer)
2012-10-22 15:00

Will implement a class_flush sub in pf/class.pm. When we will reload the violations.conf file, we will flush the class table first, before flushing the trigger table.

It will be a bit slower for people having hundreds of violations, but that should fix the issue.

(0003221)
fgaudreault (viewer)
2012-10-22 15:18

Fixed in devel. Will be part of 3.6.0.

(0003240)
fgaudreault (viewer)
2012-10-24 11:44

I guess it's a big oops to myself. Naively, I did a delete from class when you reload the violations. The problem, there is a ON DELETE CASCADE on the violation IDs. So when you drop the class, it also wipe the violation table. Not good!

I will revert the fix, and think a bit more.

Issue History
Date Modified	Username	Field	Change
2012-09-19 15:33	mada	New Issue
2012-09-20 07:33	fgaudreault	Note Added: 0003081
2012-09-20 08:52	mada	Note Added: 0003082
2012-09-20 08:57	fgaudreault	Note Added: 0003083
2012-09-20 09:05	mada	Note Added: 0003084
2012-09-20 10:57	obilodeau	Note Added: 0003087
2012-09-20 10:57	obilodeau	Status	new => assigned
2012-09-20 10:57	obilodeau	Assigned To	=> obilodeau
2012-09-20 11:40	mada	File Added: packetfence.log
2012-09-20 11:45	mada	Note Added: 0003088
2012-10-19 13:45	fgaudreault	Assigned To	obilodeau =>
2012-10-19 13:45	fgaudreault	Target Version	=> investigate
2012-10-19 13:45	fgaudreault	Note Added: 0003173
2012-10-22 14:45	fgaudreault	Assigned To	=> fgaudreault
2012-10-22 14:45	fgaudreault	Status	assigned => confirmed
2012-10-22 14:48	fgaudreault	Note Added: 0003219
2012-10-22 15:00	fgaudreault	Note Added: 0003220
2012-10-22 15:01	fgaudreault	Target Version	investigate => 3.6.0
2012-10-22 15:18	fgaudreault	git revision	=> 0fa41aae771a1e655f92515ed641c2ccc76f5a0a
2012-10-22 15:18	fgaudreault	Note Added: 0003221
2012-10-22 15:18	fgaudreault	Status	confirmed => resolved
2012-10-22 15:18	fgaudreault	Resolution	open => fixed
2012-10-22 15:18	fgaudreault	Fixed in Version	=> 3.6.0
2012-10-22 15:22	fgaudreault	Relationship added	has duplicate 0001415
2012-10-24 11:43	fgaudreault	Resolution	fixed => reopened
2012-10-24 11:44	fgaudreault	Note Added: 0003240
2012-10-24 11:45	fgaudreault	Status	resolved => confirmed
2012-10-24 11:45	fgaudreault	Fixed in Version	3.6.0 =>
2012-10-24 12:24	fgaudreault	Target Version	3.6.0 => 3.6.1

Notes
(0003081) fgaudreault (viewer) 2012-09-20 07:33	Log out the UI and log back in. You won't see them anymore.

(0003082) mada (reporter) 2012-09-20 08:52	I've tried: -Logging out -Closing the browser entirely -Flushing the browsers cache -Using a different browser -Using a different system And the entries still appear.

(0003083) fgaudreault (viewer) 2012-09-20 08:57	try: - pfcmd reload violation - log off - log on

(0003084) mada (reporter) 2012-09-20 09:05	Gave 'pfcmd reload violations' a shot then retried the 5 steps in my previous note, the deleted entries are still there.

(0003087) obilodeau (reporter) 2012-09-20 10:57	Wow, if this is a regression I think it was introduced a long time ago and I'm actually surprised that we weren't bitten by this earlier.. Grepping the code history it looks it never worked. class_delete or class_cleanup where never really called. I remember tweaking some startup code but not sure if it was related and not able to find it. Can you crank up the logs in conf/log.conf to TRACE and do a pfcmd reload violations. Then attach the log here. I'll see if I'm missing something.

(0003088) mada (reporter) 2012-09-20 11:45	Sure thing, the log's attached. (I cleaned it up a bit, just the DHCP info.) ---- (Also fixed the Sep 20 11:34:18 pfcmd(27110) ERROR: attempt to add existing trigger 806 806 [os] (pf::trigger::trigger_add) error - just had the trigger in there twice, as it says.)

(0003173) fgaudreault (viewer) 2012-10-19 13:45	We need to try reproducing this in the lab. Transfered to the investigate queue.

(0003219) fgaudreault (viewer) 2012-10-22 14:48	Confirmed Bug, the violation is still available when doing a violation add. Reproduced in the lab using 3.6.0-devel. I remember that we had another report about the violation reload not being agressive enough. The database is not flushed properly when you delete a violation. I'll check to see if it's a simple fix.

(0003220) fgaudreault (viewer) 2012-10-22 15:00	Will implement a class_flush sub in pf/class.pm. When we will reload the violations.conf file, we will flush the class table first, before flushing the trigger table. It will be a bit slower for people having hundreds of violations, but that should fix the issue.

(0003221) fgaudreault (viewer) 2012-10-22 15:18	Fixed in devel. Will be part of 3.6.0.

(0003240) fgaudreault (viewer) 2012-10-24 11:44	I guess it's a big oops to myself. Naively, I did a delete from class when you reload the violations. The problem, there is a ON DELETE CASCADE on the violation IDs. So when you drop the class, it also wipe the violation table. Not good! I will revert the fix, and think a bit more.