Bobsource manage page

[edarsow]

Introduction to BOBSources

A BObSource is a business object source, it's a plain java object that represents where a record in the database comes from, such as scraping from a python script, or entry by a public user, or entry by an internal user

Table structure

You can see that a bobsource primary key called sourceid, creator is a FK to the login table, and muni_municode is a FK to the municipality table

Sample data on Eric's test stystem

Goal

Create a management page just like for icons, except for BOBsource objects. Users should be able to view all existing bob sources, update names of existing ones, deactivate by writing FALSE to the field called active.

Existing Infrastructure

• There are a few integration methods in SystemIntegrator but for retrieval only, no insert and no update
• One coordinator method exists for getting a complete list of bobsources
• No UI exists for managing these

Requirements

1. Users should be able to attach a bobsource to their own municipality, or if we want all municipalities to use the source, we attach that bobsource to COGLand, our municipality whose municode is 999. There should be a note on the management page to this effect. Users should be given a drop-down box to select a given municipality for assignment.
2. Round out infrastructure in SystemIntegrator for inserting new BOBsources, updating a BOBsource, deactivating a bobsource, and getting bobsources by municipality. Use the IntensityClass methods on the SystemIntegrator as models for your bobsource methods, namely for inserting, updating. Unlike intensity classes whose deactivation process is just to call updateIntensityClass with the active flag as false. For BOBsource, let's make a dedicated deactivateBOBSource(BOBSource source) method
3. Create mapped methods on the SystemCoordinator for getting, updating, deactivating bob sources. Now, these methods won't have much in them by way of business logic, but backing bean classes shouldn't be calling integrator methods directly.
4. Refactor the current getBobSourceListComplete() method on SystemCoordinator to NOT include any BOBsource whose active flag is FALSE. Implement logic inside the for loop to ask the BOBsoruce that came back from the integrator if it's active, if so, add it to the list we ship back to caller, if not, skip.
5. Create a method on the SystemCoordinator called getBOBSourceListByMunicipality(Muncipality muni) which requires a not-null muni object. This method should get ALL the bob sources from the integrator and iterate over them, selecting only the sources who have a muni inside of their belly that matches the inputted muni.
6. Write JAVADOC comments for all bob source related methods on the coordinate and the integrator.
7. Use your iconManage page as a template for a page called bobsourceManage.xhtml

Technical Notes

• BOBSources are used when creating or updating all sorts of other business objects. They are usually presented as a drop-down menu. Now, drop down lists only know how to display strings, but a BOBSource is not a String, it's an object, so our drop down lists use a converter class which basically maintains a map of String:BOBSources so when a user selects a given String in a BOBsource select menu, we look up that string in the map, and extract its value, which is the actual BOBSource. Study this puppy BObSourceConverter to see how its two methods work.
• In your UI, you'll need to have a drop down list of Municipalities, which works the same way as BOBSources with converters, so check out a sample use of a municipality drop down. Check out personSearch.xhtml for a sample selectOneMenu for choosing a municipality:

Note how this works: The selectonemenu's <f:selectItems> tag grabs its list of possible values from the SystemServicesBB which has on it a list of all possible Municipality objects, see: value="#{systemServicesBB.municipalityListForSearch}" you can use this same list, but you'll want a BackingBean called something like BObSourceManageBB with field called currentBObSource and inside that BObSource object, you'll inject the chosen municipality.

So the pattern for creating a new BObSource will be to ask the SystemCoordinator for an empty BObSource object, often called a skeleton, and then this becomes the currentBObSource on your backing bean. The user then injects field values in the form directly into the BObSource object. Then when the user's ready to write it to the database, pass this skeleton object which doesn't have an ID yet (since it didn't come from the DB, it came from the coordinator) to your coordinator method called something like insertBObSource(BObSource source).

Note on adding and updating

It's handy to reuse the same form for updating and inserting objects, since they have same fields! When we have a skeleton, meaning a new BObSource, it's ID will be zero, so we know we're inserting a new one. Non zero IDs mean the object came from an actual DB record. See ceCaseProfile.xhtml for a sample. Find the dialog with an ID of person-addupdate-dialog for a multi-purpose form.

Permissions (added during meeting 9-JUL-2021)

The add/edit source function should require a user rank of System admin (6+) or higher. Implement this by asking the current user for their credential, and only allow writes with systemadmin or better