NADGIT
commented
4 years ago @Xiaohong-Chen did most of the work and I did some in UIUpdate20200829. My pull request (#177 ) should clean up the last few issues. Not shutting this issue down though as I still need feedback on stuff I wasn't sure about.
edarsow
Not all upgrades are created equal. Here are some that can wait until I'm done with more important things.
[ ] 1. The column
propertyunitidon theoccpermitapplicationtable istextinstead ofint. This is technically functional for now, but it doesn't let us use the benefits of linking table through constraints.[x] 2. Clean up the code in
OccPermitApplicationBB. There are entire fields that don't need to exist, there's no Javadocs, and the methods are pretty messy. It could be optimized, though it technically works right now.[x] 3. Clean up
CEActionRequestSubmitBBtoo, it could use a code review too.[x] 4. The Occupancy Application public interface currently has no way of labeling minors. The integration methods can be used to count adults and minors. Still, I'm not sure if those columns on the
occpermitapplicationtable are needed. those numbers can be easily counted in a for loop.[x] 5. This is unrelated but the NavStack should really be on the NavigationBB, not the SessionBean. (It was decided to keep it on sessbean. The NavBB refreshes every time a page is loaded and the NavStack would be lost)
[x] 6. There are a lot of classes that need to convert between
Java.Util.DateandLocalDateTime. There should be a method on superclasses (BObUtils etc.) that convert between the two of them. It would save a lot of space and make coding quicker.[x] 7. #147
[x] 8. The
occPermitAddPropertyUnit.xhtmlunit editor is active-agnostic. It doesn't filter according to active or really directly set active. All units created by this workflow are inactive (which might be a plus). Overall I need to reconsider the unit display methods of this interface. (The editor now filters out inactive units. I don't remember if it creates active units, but the unit change order and unit list editing interface on the page for managing OccPermitApplication can activate new units quite easily)[ ] 9. Replace the search panel in the CEAR and OccPermitApplication interfaces with the standard lookup panel. Move the search tools into a panel on the left, like the property page.
[x] 10. #140
[x] 11. Probably one of the most important improvements on the backburner, we need more continuity in the Occ Permit Application process. First of all, when selecting a unit to apply for occupancy, the user isn't informed of which units they have already applied to. Maybe change store a
List<>of already applied units, and if the unit is already applied to change the text on the button to "Already Applied".[x] 12. Get rid of the "required" attribute on public forms and replace it with Java-based validation. I think this is better for several reasons: The attribute causes issues with other XHTML elements & JavaScript stuff, we can customize error messages (e.g. "You forgot to enter your first name" as opposed to "The field is required"), and I've seen the error messages from the required attribute fail horribly. I just think it would be better to leave the logic to the Java.
[x] 13. Figure out a system to inform code officers that a public user left a message on an entity. Otherwise they'll never know which entities have messages or not, and they'd have to check manually.
[ ] 14.
PublicInfoCoordinator.javadoes note use theMessageBuilderParamsobject to attach public messages. An example of use is onOccPermitApplicationManageBB.java.I can do these myself, but I'm leaving this issue here as a to-do list for my future self. I'll continue to edit it as I find more