Our Openboxes account has two warehouse locations: one Chicago; one in the Dominican Republic. Our colleague, when using his account on site in the DR to change item counts gets error messages (Error: 500 Internal Server Error) when updating counts for certain items. This is not true of all items, and it does not happen when we access the DR Openboxes warehouse from a US location. We can correct the item counts for the which he gets error messages. Help.
Hello,
which version of OB are you using? Can you write more precise steps (which page, and what exactly that user is trying to do, is it through stock card or something else)? Do you have more logs available from the server, or just this “internal server error”?
A couple of ideas for something that might be happening, from a non-developer perspective.
- OpenBoxes sometimes gives that generic error when there was an internet issue that interrupted the save. The would explain why it’s only happening to your colleague in the DR. I cant tell you what the solution for that is, but its an area to investigate
- I assume your colleague in the DR has all of his computer settings set to Spanish (Dominican Republic). OpenBoxes tends to assume English (US), which can mean that it does not properly parse numbers with comma as a decimal separator, words with accents, date in dd/mm/yyyy, etc. This can cause a generic error. I’m not sure where this would come up on the record stock modal - maybe the expiry date - but its something to look for. If he is importing from excel, then almost certainly it’s a localization issue with his excel settings, which can be fixed by changing his excel setting to US, or manually forcing the data in certain columns into US conventions. By the way, later versions of OB are much better with localization, so if that is your problem, consider an upgrade.
Thank you for jumping in. I’ll try to provide some more context since Dina and Zoe reached out to me first a few weeks ago.
@drubakha and Zoe are from Rush University and work with the Community Empowerment implementation in the Dominican Republic.
They are currently running OpenBoxes v0.8.19-hotfix2
Here’s the original message Zoe sent to me.
Writing to see if you have help us troubleshoot a problem with OB that our Dominican colleagues are having.
When Jose has tried to adjust the counts of certain items with OB from the DR on the “Santo Domingo” side of our Community Empowerment OB account, he gets error messages—but only for certain items. Medications and syringes are among the culprits.
I tried to adjust the count of one of those same items on the Santo Domingo side of the platform from Chicago and had no problem.
What might account for this? How do we fix this?
There was a bug a few years ago where a space in the lot number would cause this problem. However, this appears to be a different issue as all request parameters are being chopped off.
In my initial response, I provided a temporary workaround until we could investigate the issue. Here was the workaround.
I forgot to mention that there’s one obvious workaround that Joe can use until I get a chance to look closer.
Navigate to the stock card of the product (i.e. using global search) and adjust the item from there.
@Artur We’ll probably recommend an upgrade to the latest 0.8.23 version, but I would like to try to understand what’s going on with v0.8.19 so we can try to reproduce the issue on v0.8.23.
It seems to be a data issue or a problem with the way we work with jquery or the dataTables plugin to retrieve the data we need for the request parameters.
Ok it looks like it is the same issue as before (a space in the text used for the request parameter), but this time within the productCode, not the lotNumber.
Searching for this product by product code produces no results with or without the space. I assume we’re trimming
Looking at the Product Code in the Edit Product page clearly shows a space.
Removing the space allows the Global Search to find the product
… and more importantly fixes the bug on Manage Inventory
NOTE: This page will eventually be replaced by a React app, but in the meantime, we should probably URL encode the data being used as request parameters and clean data (i.e. trim whitespace) before it’s persisted to the database.
@drubakha Let us know if there are other inventory items that exhibit the same behavior within the Manage Inventory feature.
Some notes/questions about all the insights provided. We’ve used the workaround that Justin offered, and it works.
When we were on site in the DR, in the warehouse with our colleague using his same Wifi and the same version of OB, his device would continue getting the error while ours did not. The only distinction, per our perception, is the primary language of the software being used by each party. We were able to modify the counts of syringes for his SD warehouse and he could, after a couple rounds of refreshing the page, see those updates, but he is unable to make them.
Regarding the notion that there is white space in front of the product code in the edit page, I am happy to investigate if possible, using his login, but wouldn’t this problem have presented earlier? Why was it working before, stopped randomly and started producing this error; what inserted that white space?
his device would continue getting the error while ours did not.
This probably won’t matter, but for the sake of completeness, what type of device was he using?
after a couple rounds of refreshing the page, see those updates, but he is unable to make them.
This is probably a different issue. There’s sometimes a lag with the background process that refreshes the database table we use to cache the Quantity Available and Quantity on Hand for each inventory item.
And just to confirm, you said …
we’ve used the workaround …, and it works
Does that mean it fixed the issue for all users?
I am happy to investigate if possible, using his login,
As a Superuser, you can impersonate another user.
- Click Configuration > Users
- Search for the user you want to impersonate
- Click the link to enter the Edit User page
- Click the Impersonate button
but wouldn’t this problem have presented earlier? Why was it working before, stopped randomly and started producing this error;
I have no idea why you are not seeing the issue. I recorded a video that demonstrates the problem and suggests that it is not a locale-specific issue.
what inserted that white space?
I honestly don’t know. The space could have been inserted inadvertently by a user through the Edit Product or Import Product features.
In the email that you sent directly to me you also posed the following questions, so I wanted to take a second to respond.
If I understood correctly, I need to go in and remove white space from the product code; is this correct?
Yes. It looks like the version you are using has the fix for the lot number, but the product code and bin location (which I guess we thought wouldn’t ever have spaces) should also be escaped. So I’ll create a ticket for that. Until that bug is fixed you’ll need to remove whitespace from the product code and bin location fields.
By the way, you’ll notice I trailed off at the end of the video. I paused the video to pursue a hunch, but it didn’t materialize into anything.
But one question I had, based on the original screenshot you sent … did you change the product code for the product that was originally causing the problem?
The hunch I was pursuing was whether there might be duplicate products in the system
- DEXAMETHASONA (the product code from your original screenshot)
- DEXAMETHASONE (the product code that’s in the system now)
But it looks like there’s only one DEXAMETHASONE
mysql> select id, product_code, name, date_created, last_updated from product where product_code like 'DEX%' order by product_code limit 1 \G;
*************************** 1. row ***************************
id: 8a80808482cd96fb018358b75ae600a3
product_code: DEXAMETHASONE
name: Dexamethasone Mix doses
date_created: 2022-09-20 02:25:55
last_updated: 2023-01-26 21:21:24
1 row in set (0.00 sec)
I found one other product that looks like it was “soft deleted”. Not sure if this one is related to this issue somehow or just a duplicate. We could probably trace through the stock history.
mysql> select id, product_code, name, date_created, last_updated from product order by product_code limit 1 \G;
*************************** 1. row ***************************
id: 8a8080847c687223017f6b1f604b0122
product_code: 0
name: .
date_created: 2022-03-08 20:01:33
last_updated: 2023-01-13 14:35:46
1 row in set (0.00 sec)
And yes, it does appear to be related since the bin location used is the same as the bin location for DEXAMETHASONE.
Stock History > (soft deleted product)
Stock History > DEXAMETHASON
So I would recommend talking to the CE Staff to see why that product was deactivated.
I also went back to look for other products and bin locations that might cause this problem.
There are 12 more products with a space.
mysql> select id, product_code from product where product_code like '% %' order by product_code;
+----------------------------------+-------------------------+
| id | product_code |
+----------------------------------+-------------------------+
| 8a8080846ed6f341016ed72bc4fe027d | 1600TLC |
| 8a8080847c687223017f6b1f53aa0073 | 1621W TEMP |
| 8a8080846ed6f341016ed72bd72d0369 | 25-806 1PR |
| 8a8080846ed6f341016ed72bd741036a | 25-806 2WC |
| 8a8080847c687223017f6b1f5fe5011c | 502 01509038 0749692001 |
| 8a8080846ed6f341016ed72c4a570767 | 7496-PUP 31150470 |
| 8a80808482cd96fb018358b75f7f00f6 | BROWN BAG |
| 8a8080846ed6f341016ed72d171c0bdf | Easy Cap II |
| 8a80808482cd96fb01834d0f533d006a | fakeitem |
| 8a8080846ed6f341016ef108f4dc1b25 | K 834 |
| 8a8080847c687223017f6b1f701601ca | MDS 160824 |
| 8a8080846ed6f341016ed72d91eb0df5 | MYSTERY ITEM |
+----------------------------------+-------------------------+
12 rows in set (0.01 sec)
and maybe one potential bin location
mysql> select id, location_number from location where location_number like '% %';
+----------------------------------+-----------------+
| id | location_number |
+----------------------------------+-----------------+
| 8a8080846ed6f341016f0003efcb1dd5 | Outbound Source |
+----------------------------------+-----------------+
1 row in set (0.00 sec)
How do I get into the Spanish inventory in the SD warehouse to test the correction to this problem. As long as it is in English, the system functions.
I logged in as myself into the SD warehouse, and I can adjust all counts for the “problem items”. I thought if I logged in as Jose, I’d encounter the error, but when I impersonate his profile, the SD warehouse inventory remains in English, which is not how his appears, and all the “problem items” are still functional. This continues to suggest that it is specific to the items as they are written in Spanish, in his literal log in version of the SD warehouse in OB. It may be a white space issue with the Spanish version of the inventory item, but I cannot get in to test because even when I impersonate, it’s still the English version of that inventory. I need to test this with the Spanish inventory items in his SD warehouse in OB. Suggestions?
How do I get into the Spanish inventory in the SD warehouse to test the correction to this problem. As long as it is in English, the system functions.
There’s no “Spanish” inventory. We just allow users to change their locale (language) either as a preference on their user account or by selecting a locale in the footer of the page.
I logged in as myself into the SD warehouse, and I can adjust all counts for the “problem items”.
Could you provide more specific information on the “problem items” you’re still dealing with? Are they included in the 12 products that I mentioned in my previous reply? Besides those, the only other one I am familiar with is the DEXAMETHASONE product (there may have been one other, but I have forgotten).
I was able to get one of the products I mentioned in my last post (i.e “BROWN BAG”) to fail in both locales.
English
Spanish
I thought if I logged in as Jose, I’d encounter the error, but when I impersonate his profile, the SD warehouse inventory remains in English, which is not how his appears, and all the “problem items” are still functional.
I just impersonated him on your server and his locale was set to Spanish, as expected. Then I navigated to the Manage Inventory page and opened a few random Adjust Item dialogs. I was unable to reproduce the error with any of those random clicks, but I wasn’t trying any of the known “problem items”.
I’m still confused about what’s working and what’s not working. From one of your previous posts I thought the problem had been resolved.
We’ve used the workaround that Justin offered, and it works.
If you have time, we could schedule a video call / screen share early next week to walk through the problem with Jose. I’m only available on Monday and Tuesday, then will be on vacation with the family until April.
By the way, I have not fixed any of the 12 products I mentioned in an earlier post, including BROWN BAG. So if all of the outstanding “problem items” are in that list, then you should be able to apply the workaround to those (i.e. remove whitespace) and be done with this issue. If there are other “problem items” then you’ll need to provide more details so we can troubleshoot together.