When I open a new WME tab, I get update notifications for URO+ alternating between 3.147 and 3.164 each time. I tried reinstalling 3.164, but I still get notified about 3.147.
Iām guessing youāre using Chrome, used to use the Chrome Web Store version of URO, and then switched over to the Tampermonkey version after I stopped updating the web store version?
If so, then it sounds like youāve still got the web store version enabled, in which case you need to go to the āMore tools > Extensionsā option in the Chrome menu (or enter the following into the address bar: chrome://extensions/), then remove the URO+ entry you should find listed there.
Thanks, that did it!
CCP closure feeds are treated as app closures, is that an issue? This doesnāt seem to be related to the segment-ID issue, it is showing a segment ID for the one I saw.
Do you have a PL to an example of such a closure? I had a quick scan around the PA area just now but couldnāt see any mis-flagged RTCs.
Note that the missing segment ID issue was only a concern to the editor creating the RTC - if their WME session was missing the IDs at the point where they generated the new RTC object, it would be saved to the server with a blank location field and thus be misclassified by URO regardless of whether or not the WME session used to view the RTC had correctly loaded IDs. Conversely, a correctly saved RTC object would then be correctly classified by URO even if the viewing WME session was missing its IDs.
https://www.waze.com/en-US/editor/?env=usa&lon=-79.82003&lat=40.54218&zoom=5&segments=506745108
PA_Turnpike is the CCP. He disabled URO to edit the closure.
Your explanation of the ID issue makes sense. No way to know for sure after the fact unless you see something in the closure info.
Today, during initialization, I saw the following error message in the console, which I traced to URO+:
Uncaught TypeError: Cannot read property 'totalSessions' of undefined userscript.html?id=63e47901-0691-48be-b1eb-4764b60bff21:12762
at XMLHttpRequest.dteReq.onreadystatechange
Empty location field, null provider property, and a userID > 0ā¦ all unfortunately consistent with the signature of an in-app closure, so no way to differentiate without having URO learn all the possible userIDs for accounts that only generate closures from within WME. Easier to just wait for the segmentID fix to make its way into production.
Thanks, this has now been fixed for the next release
OK, thanks for checking Chris.
3.165 fixes the DTE error noted above, PUR filtering by age works again, and makes the migration from countries.top to getTopCountry(). For those of us living on the cutting edge over in betaland, it also removes the hide sidebar profile info option for reasons which will be obvious to anyone whoās seen the current betaā¦
3.166 adds the option to show only those MPs with a specific start and/or end date (useful when dealing with multiple MPs raised for the same event - no prizes for guessing what Iād been doing earlier this weekendā¦), or with an end date in the past.
When selecting and deselecting places issues or Residential issues, or parking issues in the WME layers menu, at first the update requests disappear / appear on the map (with correlation to what is checked / not checked) however after a few such selections and decelections the update requests stop appearing / disappearingā¦ When removing URO+ the problem doesnāt happen.
Another issues is blocking Parking lot Map problems such as āMissing Parking Lot Placeā. When blocking them in the MP menu most of the time also most of the URās disappear. Sometimes when refreshing WME the URās reappear but most of the time they donāt.
3.167 allows URO to cope with the occasional delay in WME creating the getTopCountry() function at the start of a session, and tidies up parts of the code which have been seen throwing errors recentlyā¦
I havenāt been able to reproduce either of these problems, however please try the new version to see if the general bugfixes thatāve been made have any effect.
Hi,
The scripts does not recognize an in-app closure correct.
Here I have a closure just made in WME, but URO+ recognize this as an in-app closure.
As you can see in Screenshot 1 this is no app-closure because the closure mark is grey and not red,
The closure isnāt edited either as I can see in the history:
In the second screenshot you can see that I am not allowed to edit the closure.
I think the problem is that the closure is made in WME by a editor with a lower rank than the segment itself is locked. The segment is locked at L2 and the editor is a L1. That editor is allowed to add closures because we gave him a closure area.
Can you please take a look at this?
Thnks
1 Like
I wouldnāt be surprised if itās yet another closure created whilst the users WME session was suffering from the ālost segment IDā bug:
https://www.waze.com/forum/viewtopic.php?f=819&t=29054&start=1870#p1987742
Iāll have a quick look at the data for this RTC when I get home later just to be sure, but Iād be amazed if it was anything but this problem yet againā¦
Having now looked at the RTC data, the missing ID bug does seem to be the reason for this one being flagged as an in-app RTC as well.
Thanks for looking out. Wasnāt aware of that issue.
As I understood well this WME bug is already fixed in the beta WME?
So let that version come out to production.
I still have this BUG in the latest beta WME.
Is there a separate BUG report about this issue?