HIFIS 4

In 4.0.60, when users are sent a password reset link, the host (first) portion of the URL is missing. For example, it will say: "Please click the following link to reset your password: /Account/ResetPassword/123456" Instead of the necessary: " https://acre.hifis.site /Account/ResetPassword/123456"

The Client Search is really different than in our current production version (4.0.59.4). Is it working the way you expect it to? For example, to get to my client John William Test (Alias 1 Jonathan Silly Pants), it no longer works to search jo te or wi pa. john test doesn't work either, you have to type in test, john. But jonathan silly works. Is that by design? Absurdly, han sil works.

When we assign rights to a user, either via individual rights or a Template, sometimes the rights related to client vitals don't apply properly. So in the section Client Details > Vitals, there are 4 rights. I commonly want to assign Add Vitals, Edit Vitals, and Display Vitals, but not Ability to Hide Clients. If I individually check off the rights, then the user won't actually have access to the Vitals tab. However, if I hit the "select all" parent right, and then remove Ability to Hide Clients, the rights the user has end up being exactly the same, but it works properly in that case. So there's something misconfigured, but I don't know what exactly. Here's a video: https://www.loom.com/share/405270bb37db481ebe414982f14f4c7e?sid=38ccf871-6bca-41c0-9216-819d63fc84de

Winnipeg is having an issue testing 4.0.60.2.1 on their training database. They're getting a database table error when they load the Client List = All but not when they load the Client List = Active (and they say it takes a really long time).

This is another version of https://acreconsulting.canny.io/hifis-4/p/housing-status-duplicated-statuses but it's distinct enough that I'm giving it its own ticket. I have a total of 36 clients. I found the issue for 7 clients including Anonymous, Anonymous, that's around 20% of clients affected. I tested the demo site and the issue is present for over 1200 clients. Here are some examples of affected clients: all clients between 2,881 and 2,895 inclusive; 2,723; 800; 259.... there's lots. It's always duplicated Unknown status. Every time. I haven't found a duplicated status that wasn't Unknown. It's always the same client becoming unknown a bunch of times at the exact same timestamp. The timestamp is the same timestamp as the client created date. There are always 77 copies of the duplicated unknown status. The number 77 probably has to do with something in my database. I tested on demo.hifis.ca and the number was 615. I don't know what I have 77 of and demo.hifis.ca has 615 of, but there's probably something.

When attempting to upgrade the HIFIS database in our test environment using the database upgrade script for HIFIS version 4.0.60.2, we ran out of disk space. This did not occur when upgrading our test environment to any version of HIFIS prior to 4.0.60.2. To see what was causing this, I ran the database upgrade script on my laptop (which has more space). The size of tempDB transaction log had increased from 4 GB to almost 30 GB after running the script. Subsequent executions of the sp_UpdateClientChronicityStatus stored procedure after the initial run of the upgrade script caused tempDB’s transaction log to grow to 15 GB in size. The cause of tempdb transaction log’s growth appears to be the logging of the numerous updates made to the #T_CLIENT_CALENDAR table from the sp_UpdateClientChronicityStatus stored procedure. The artcle below suggests that using a SELECT INTO can be more efficient as Bulk operations are minimally logged under the Simple recovery model used by TempDB. https://learn.microsoft.com/en-us/sql/t-sql/queries/select-into-clause-transact-sql?view=sql-server-ver16#logging-behavior "The amount of logging for SELECT...INTO depends on the recovery model in effect for the database. Under the simple recovery model or bulk-logged recovery model, bulk operations are minimally logged. With minimal logging, using the SELECT...INTO statement can be more efficient than creating a table and then populating the table with an INSERT statement. For more information, see The Transaction Log (SQL Server)." Infrastructure Canada has been provided with this information and a re-written sp_UpdateClientChronicityStatus stored procedure that uses SELECT INTO instead of INSERT INTO and UPDATE. Ticket 13385 has been opened for this issue.

When you use the Client Search, results show but the ability to navigate to another page is missing, so if your search result returns more than X clients, they cannot be found.

Sometimes the Chronic Homelessness YN field is a "Y", sometimes a "N", and sometimes a "0." Also results in duplicated records (in the screen shot, one of the records on 2022-11-04 was a "Y" and the other was a "1")

An error related to merging clients has been brought to my attention in v60. It looks like merging any two clients throws an error. Notably though, there seems to be multiple errors thrown, and it seems somewhat random which error message you get. I've seen at least 3 different ones.

When closing a case, get an error saying "The value '## Days' is not valid for TotalElapsedTime."