HIFIS Feedback

From time to time I encounter an issue or hear about an issue where a user's rights don't seem to be having the intended behaviour. Well, I'm not sure if this is the root cause or not, but I have discovered a large number of duplicated record in the HIFIS_User_Rights table. For example, here's four identical copies of the same user having the same right at the same organization. However, more distressingly, sometimes they don't match. Here you see the same right, same user/organization, and two records saying the right IS allowed and one right saying that it is NOT allowed. I am not sure how significant this finding is, but I thought I would share it with you in hopes that it might help with troubleshooting something. Somewhat interestingly, this seems to be most prevalent for one user at one organization in my database, and this is what their rights looks like. In other words, not attached to a rights template, and very minimal rights. For this specific UserOrganizationRightsID, there are 539 rows. The user has been granted a total of 4 rights at this organization.

Currently, Assets and Liabilities (Debts) are bundled together. If users have rights to one, they have rights to the other. Similarly, they are both stored in the same table, with the same fields (a Debt is simply a negative Asset). It is suggested that these be split into two distinct entities, with updated rights and database to illustrate this. Separate rights for Assets and Liabilities (Debts) into two categories Separate Assets and Debts into two separate database tables

Another issue with the Debts module is it is unclear how it should be used to manage changing debts. Each Debt record has an amount and a start date and an end date. If a client owes $1000, then pays off $100 and now owes $900, how should that be recorded? If interest increases it to $925, how can a user easily capture that? One option is to add an end date to the old record and start a new record with the new amount, but that is a cumbersome process. Alternatively, a user could change the amount, but that erases the history (a similar challenge as in Rent Adjustments). Keep a history of Debt adjustments, and display this information As in Action Item RA-3: Create a “Add Rent Adjustment” form, a separate form could be created that simply allows a user to update the current Debt amount, along with a date. A similar discussion could be had (as in Rent Adjustments) as to whether it is also necessary to include a “Reason for Adjustment” field. Alternatively, adjusting the Debt amount could be part of the Edit Debt screen that would allow a user to change the Amount value, while somehow keeping a record that the amount was changed and what the previous and current values are. This would be a model more akin to how Statuses are updated in the Waiting List module. Add a way to easily update Debt amounts Regardless of the specific approach undertaken, the Start Date and End Date fields seem problematic, as it is unclear to users how they should be used. Given the preferred method of use, it may be most logical to remove the Start and End Date fields altogether, and have them replaced by a series of update dates. Or, perhaps the Start Date and End Date are hidden from the user, and are automatically populated: the Start Date with the first date listed, and the End Date with the date attached when the Amount reaches 0. It is still necessary to be able to indicate which Debts are “active” and which are “archived,” but this can simply be achieved by reviewing what the current Debt amount is. Reconfigure Start Date and End Date fields; a Debt should be considered active if its current value is not $0.00, regardless of the Start and End Dates.

The current “Country” and “Province/Territory” fields in the Debts module are not particularly relevant. The utility of these fields is unclear, and it is suggested that the possibility of removing these fields be investigated.

A field to indicate whether a repayment plan is in place or not

One key piece of information that is missing is who the debt is owed to, as an optional field. There was some discussion about linking this field to People instead of Places, or possibly having two fields, one linking to each. However, the idea of two fields was discarded because it would be too confusing and/or cluttered.

Some suggested options include: Rent ArrearsUtility ArrearsTelecommunications ArrearsCredit Card DebtStudent LoanBusiness LoanPersonal LoanAutomobile LoanPayday LoanMortgageMedical BillsLegal FeesUnpaid TaxesUnpaid FinesStreet Debt

In testing 60.3 we have found an issue with the “View All Session Details” button in the Case Management area. To see this, create a new case management record, or open a client that already has an open case management record, either from Front Desk > Case Management, or from Client Management > Case Management. Then Click on the Display button to view the details. What we expect to see here is a summary of all sessions attached to the case management record. In our production environment (v4.0.59.7.1) we see a summary of all sessions attached to the case management record.

Sometimes a user account might get added with a typo, or in contravention of a naming policy. It would be great if we could be able to modify user accounts.

For most users, Bing Maps will stop working on June 30, 2025. New HIFIS instances are already unable to create new Bing Maps keys. This means that on June 30, 2025 any feature that has to do with mapping will stop functioning. That includes: Directory of Services mapHousing Unit Search mapGoods & Services and Group Activities geo-taggingOutreach mapEncampments geo-tagging and map display