3.157 adds enhanced history support for PURs, and fixes an error thrown when selecting places.
Note that the PUR enhanced history is still a work in progress - I’m still working my way through all of the available data in the history object to figure out a) what can (and should) be shown, and b) whether my interpretation of the object attributes is accurate. If anyone sees the enhanced history disagreeing with what they know for certain the PUR actually involved, please get in touch…
Also note that the enhanced history doesn’t bother adding all the fine details for PURs which have been approved - for every place I’ve looked at so far where a PUR has been approved, there’s a corresponding place update entry in the history which WME natively shows the details for, so URO only adds these details for PURs which have been rejected.
Also also note that, as with road closure requests, it appears that any PURs generated from within the app only generate a history entry once they’ve been approved or rejected, so some manual interpretation of the history entries may be required to work out just what the timeline of events actually means…
It appears that the Feed Filter is no longer working. I have mine set to exclude MPs and PURs and they still show up on my feed. Confirmed I’m on version 3.158
The adding of Alt Names in the popup is terrific. Saves me a ton of time. Also, I agree that cloning an in-app-closure is a terrible idea, so removing that button was a great addition. Thanks for your continued work on this script!
I’ll second those comments. This release was a great leap forward, imho. Thanks for the critical work of yourself, T-UK, … and all the other script writers.
I’m wondering about that, too. I may have missed something, but I thought in-app closures were supposed to be editable – assuming they haven’t already expired or failed. I have been in the habit of checking them in LiveMap and then adding the correct end time, based on an official source. Is that not advised?
In app closures are editable, but lately we’ve been having more problems with them not appearing in the app (even if edited by an editor) to the point where it’s just better to delete and recreate. Something may have changed on the back end, but that’s what we’ve been seeing.
Sadly, with the disabling of features, URO will now be disabled most of the time, for me. That’s a deal-killer.
Closure failures are a thing to be dealt with by HQ, but other functionality should not be disabled because of it.
I also regret the disabling of the edit function. I’ve had pretty good luck lately with live app closures persisting post-editing, though it’s not perfect. There are times when it makes more sense to keep the app closure that’s already gone live than killing it and recreating, given the lag time in the closure going live.
I would suggest that, if you really want to edit in-app closures, then you ask nicely if it can be made optional. That is the only feature being disabled by this script. Saying it’s a “deal-killer” and saying you’re mostly going to disable the script sounds more like sulking and isn’t likely to get you what you want.
Quite right - except they are not dealing with it. The forum has plenty of reports of in-app closures that don’t work; that work up until their original end-time even when that’s been changed by editing. We have seen several cases where editors didn’t realise they were editing an in-app closure and got bitten when it later failed to match the edits.
Personally, I think identifying them and disabling their editing is a sensible response to the reality of the situation. But if enough people consider it a problem, I’m sure Twister-UK can squeeze another option box in there somewhere.
The problem is, as Iain’s already explained, that there are absolutely ZERO guarantees that any edits made to an in-app closure will have any effect on routing in the app. There’s also the issue that in-app closures which make it into WME aren’t even guaranteed to have any effect on routing (or even show up at all) in the app before any of us try to adjust their properties to better match the actual closure period. So whilst you, and a few other editors, may have had some success in editing in-app closures in your part of the Waze world, evidence from elsewhere suggests you’re in a fairly small minority of editors for whom modifying in-app closures does what you expect it to do.
And as you’ve just said - “though it’s not perfect”. I’m sorry, but I just don’t understand why, if you know it doesn’t always work, you’d then want to take the risk of having any closures you’ve spent the time editing then failing to work properly in the app, when recreating the closure as a native WME one takes barely any more time than editing the existing in-app one?
My own experience of adding closures suggests we’re talking a matter of seconds or maybe a minute at most before they take effect in the app, so it’s not as if deleting an in-app closure in order to set up a WME one should cause the road to reopen (assuming it’s being treated as closed in the first place…) for long enough to cause any real issues, and the trade-off for potentially having it reopen for that short period is the guarantee that the closure will then act as expected for the remaining duration that’s been set. That to me feels like something worth doing, and something we really all ought to be getting into the habit of doing for as long as the problems with in-app closures persist.
As a result, I took an “executive decision” to prevent easy editing of in-app closures from anyone running URO. If you really feel the need to continue editing them, then it’s not difficult to temporarily disable the script, make the changes and then re-enable it later. But given the myriad of problems editing in-app closures has caused and will continue to cause so long as the devs continue to ignore this problem, putting a roadblock in the way of anyone thinking of editing one felt like the right and responsible thing to do.
The whole issue over why WME doesn’t natively mark in-app closures differently to genuinely active WME-submitted closures is a seperate gripe I have with the devs, hence my earlier efforts to make it easier to tell them apart from real closures, efforts not made any easier by the recent change in the start date properties of in-app closures which now makes it harder to reliably differentiate them (hence the problem noted above by turbomkt), which did little to make me think any more charitably towards whichever part of the dev team is responsible for closure handling… Quite frankly, I consider this to be yet another example of the devs having little or no real understanding of how real editors use WME, and adding stuff that makes maintaining closures harder than it ought to be. So whatever I can do to push back against these design decisions, I’ll do it.
The problem I have (and Tony feels it just as much since he works directly with the partner who is screwing things up) is feed based closures are being treated as in-app closures. When improperly set and using URO+, the only way to handle them is to remove and rebuild. I can’t even get to the description field if there is one.
The answer you give may be pop ups. I find pop ups get in the way and only enable them when doing significant amounts of work that benefits from them.
With in-app RTCs I’d rather have the RTC highlighted (as it is now) but still be able to go into it/edit it, knowing I’m looking at something that might not work after the original expiration.
So back to my original issue - we need to be able to edit RTCs that were submitted via feed. Can we get that back?
I’ve now seen this problem here for the closures added by ClosureMonitor, are these the ones you’re referring to in your area, or are yours tagged as having been added by a different user ID? If it’s the latter, please provide a PL so I can see what identifying properties there are of this type of closure in order to avoid classifying them as in-app.
Thanks for explaining what the real issue is with this new feature, and as per my earlier reply to your original post about this - if you can provide a PL to examples of these closures I’ll see what I can do about it.
Note that treating these types of closures as in-app was definitely NOT intentional, so any problems this causes with maintaining feed-related closures is unfortunate and I’ll obviously do my best to resolve this. But this shouldn’t cloud people’s opinions of the intended behaviour here, which is to prevent script users from doing something that we now know to be a really bad idea.
