Route all backing bean requests through coordinator methods. Only the coordinator should ever talk to an integrator. Adjust pattern in PUTs and Icons please.
Create deactivate pathsways for icons and puts
Run the SQL add columns for PUTs and Icons
Create deactivateIcon(Icon i) and deactivatePUT(Put p) in SystemIntegrator . These methods should check that incoming object is not null. If not null, then create a SET active = False WHERE putid = ? and inject the object id
Create corresponding deactivate methods in the SystemCoordinator. Optional logic check here would be to see if the PUT or Icon has been referenced in another record. The formal way to do this would be to select records with that PUT or Icon's ID from any table that has a PUT or Icon FK. PUT is easy since it's only one table that has a PUT, which is property table usetype_typeid. You'd make a use check method on the Integrator called something like "PUTCheckForUse" that returns a record count and the coordinator method would say: if it's not zero, don't let the user deactivate
Update the getIcon or getIcons and getPUT or getPUTS methods to have SQL that includes a WHERE active = TRUE clause so the managements pages don't see the deactivated record
Update the backing bean and UI to call proper methods on Coordinator. Look at template coordinator methods that throw an exception like BOBStatusException and contain a message in its belly. This message is turned into a FacesMessage instance in the BackingBean which gets displayed to the user. Check the PUT and Icon manage pages to make sure they use the p:growl component.
Make sure the page knows how to refresh its list after a deactivation so the use cannot see the deleted record.
BBs talk only to Coordinators
Route all backing bean requests through coordinator methods. Only the coordinator should ever talk to an integrator. Adjust pattern in PUTs and Icons please.
Create deactivate pathsways for icons and puts