I can’t find any release notes or anything for 2024 either to verify that it’s being delivered.
Good question! We just upgraded this past weekend to 2023.2.14. And I did not change my profile until just now since you reminded me.
Man, that’s a tough one.
So, there was like one time I saw the {{Strings}} thing over the weekend, and I refreshed the browser and it was fine. So, maybe?
Here’s the complicated part.
Since our move to the browser in January, I have had nonstop problems with crazy oddball sporadic UI issues (affects some users and not others, etc.). Things like a “New Line” button being disabled - and not for a legitimate reason. Order Entry is probably the biggest offender, but it was well distributed among other modules, especially in finance (maybe that’s just because they use Kinetic the most).
I bring this up because
- The fix was to run conversion 191, just like this
{{Strings}}issue. - Sometimes 191 would create the problem of
{{Strings}}displaying when it wasn’t there earlier in the day.
To flesh out that last point:
- Imagine Cash Receipt Entry is not displaying properly - missing sidebar; cannot retrieve invoices
- Also imagine that Order Entry was working fine that day
- If I run 191 during the day, it might happen that Cash Receipt Entry would be fixed (fully functional again) and yet Order Entry would get the
{{Strings}}issue after 191 finished.
Now, this week (after upgrading to 2023.2), I was rather disappointed to still have users get these UI bugs again. HOWEVER, I don’t think we’ve seen the specific {{Strings}} text.
There is a slight silver lining to the story. We found that if the user opens the browser in Incognito/InPrivate mode, then the 191-related UI glitches all go away.
Now, I can’t prove this, but I feel like we had tried incognito before, and it didn’t help. So I don’t know, but maybe the upgrade at least got us that much farther?
Sorry, that’s not very definitive.
1 Like
I appreciate the time you took to document what you’re seeing and respond. Thank you.
It sounds like it’s still lurking, although we can’t truly say it is or it isn’t, just like nobody could really figure out root cause to begin with… BUT one thing IS FOR SURE… there is a PRB for it and it does not appear on any of the release notes for the most current on prem release+patch.
I feel like if they delivered the fix it would be in the notes, but I feel like I recall a post or two from @josecgomez and/or @hkeric.wci, @jgiese.wci on whether the notes have everything that they delivered.
This happened to a user today and he also refreshed his browser and it also fixed it for him.
For reference, this is what he sent me (well, I cropped it, etc.):
So I guess it is resolved. Kind of.
I guess… the fact that it’s still happening is troubling.
What release are you on? 2023.2?
Yes 2023.2.14
Okay, well it looks like they still have yet to get it resolved. Hoping for 2024.1 like they said.
we will see if it shows up at insights. I imagine we will be using 2024.1 there in the VMs? I hope anyways.
Did you see it crop up in any of your classes?
Today, I decided to dive into Kinetic and start using it prior to our upgrade for 2023. I immediately ran into the issues described here and in the other MES menu topic. Of course, the magical app studio refresh works. Big thanks to y’all for saving me the trouble of getting a ticket open just to get that answer, or to run C 191.
This is an immediate non-starter for Kinetic adoption, especially with it is just sitting around unfixed for months. They seem to be heading in the right direction with changes but are missing important issues. The metadata issue for ECM comes to mind and how long that sat for, in addition to this sitting around for months.
We’ll get to Kinetic eventually… I’m certainly going to be pointing to these issues as the reason when asked why we aren’t on Kinetic and how we feel about it.
Grateful for this user group.
4 Likes
Can you point out what specific fix that was with app studio… what post on here?
I assume you’re cloud so this fix is relevant to cloud. I also have a fix for the specific screen but you have to be storing the cache file on a server (not database) to be able to do the fix- and of course have access to the server.
My bad, I assumed a bit of information here. We are on-premise Kinetic in our own Azure setup.
I came from this topic as I was unable to open Part Tracker in 2022.2 from menu or context with no actual error thrown (undefined). The fix described to a user was to simply open the broken application layer in Application Studio which causes some sort of cache refresh. Doing so, without any other intervention, it started working. https://www.epiusers.help/t/2022-2-8-due-to-security-settings-or-module-licensing-process-is-unavailable/97565/52
1 Like
I’ll tag this in also, as I see them all as related.
I see, yeah you can delete the cache yourself as well (try this at your own free will- on our testing environment first) if you have the settings on to save the cache as a file on the server it’s here under the related “app”. This is not blessed by Epicor or anything, but I was desperate, and I deleted it because I wanted to see what would happen.
For example, imagine you were having the error with Sales Order Entry, you’d enter this folder and then delete the cache file…
SERVERDIRECTORY:\Epicor\Websites\ENVIRONMENTNAME\Server\Apps\MetaUI\Erp.UI.SalesOrderEntry\cache
1 Like
It gets re-created when you close and re-open order entry and compiles without issue and users are happy again… until it happens again.
The circular logic of this is hilarious because it is exactly the issue.
Admin: “I FIXED IT”
[One day later]
“I HATE MY JOB”
1 Like
I’m serious @JasonMcD … I found this through the event log and saw that this file was having an error and got so sick of it I just deleted it (in test of course) to see if it fixed it and it did.
I watched this folder first to try and understand, and what I know is, if you delete this or run 191 or whatever it clears this file.
But when you open sales order entry app again, you’ll see that a bunch of files get written to this folder then they go away and you’re left with one file… the json file pictured above.
Now when two people open sales order entry at the same time and both actions write the same exact files to the same directory… what do you think happens? A conflict… That’s what I boiled down our issue to. Two people opening same form at same time… which happens often especially when customer service all starts at 8AM and production starts at 6aM etc. A bunch of the same forms are opened at once.
Deleting the related file in the related app directory resolves it for us, but I’ll try the app studio thing too next time.
Hey all can you drop what exact versions you are seeing this on right now. We have some recent bugfixes out to address the race condition bug that leads to you seeing our locale injection {{strings and i’d like to confirm.
others from my team may reach out also.
1 Like
Like I implied earlier today, I seem to be having some success with clearing personalizations, too, in extreme cases.
Or it’s all luck. 
1 Like
11.2.300.9
Try this cache file one time if you want to, it has worked every time for me to fix the issue.
@bconner 2023.2.14, but take my comments with a grain of salt.
I am conflating (issues solved by conversion 191) with ({{strings}} issues ALSO solved by 191)
They may be unrelated for me.