|Anonymous | Login||2023-03-28 01:25 EDT|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details [ Jump to Notes ]||[ Issue History ] [ Print ]|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001555||PacketFence||web admin||public||2012-09-19 15:33||2012-10-24 12:24|
|Target Version||3.6.1||Fixed in Version|
|Summary||0001555: Violations that have been deleted are selectable from PF::Violation::Add or PF::Violation::Edit|
|Description||After deleting a few custom violations (and restarting the PacketFence server) the deleted violations are still selectable options in the PF::Violation::Add "Identifier" dropdown box and in the PF::Violation::Edit "Description" dropdown box. The custom violations no longer show up in the "Configuration -> Violations" menu.|
-From the webadmin, created violation with Identifier 7100001 and description "Test"
-Restarted PacketFence services
-Applied violation to node using PF::Violation::Add (Violation tab -> Add tab from webadmin)
-Closed violation and deleted the record in the webadmin Violation tab
-Deleted the violation from the "Configuration -> Violations" tab
-Confirmed that neither conf/violations.conf nor the webadmin "Configuration -> Violations" tab showed the violation anymore
-Restarted the PacketFence server (hard restart)
From there, conf/violations.conf and the webadmin "Configuration -> Violations" tab continue to show that the custom violation no longer exists. However, by going to the "Violation -> View" tab, editing an existing violation and choosing the "Description" dropdown OR going to the "Violation -> Add" tab and choosing the "Identifier" dropdown the custom violation is still selectable.
|Tags||No tags attached.|
|fixed in git revision||0fa41aae771a1e655f92515ed641c2ccc76f5a0a|
|fixed in mtn revision|
|Attached Files||packetfence.log [^] (136,305 bytes) 2012-09-20 11:40|
|Log out the UI and log back in. You won't see them anymore.|
-Closing the browser entirely
-Flushing the browsers cache
-Using a different browser
-Using a different system
And the entries still appear.
- pfcmd reload violation
- log off
- log on
|Gave 'pfcmd reload violations' a shot then retried the 5 steps in my previous note, the deleted entries are still there.|
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.
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.)
|We need to try reproducing this in the lab. Transfered to the investigate queue.|
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.
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.
|Fixed in devel. Will be part of 3.6.0.|
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.
|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|
|Copyright © 2000 - 2012 MantisBT Group|