merefield
(Robert)
August 5, 2023, 12:13pm
918
paviliondev:main
← paviliondev:map_route_fixes
opened 11:58AM - 05 Aug 23 UTC
* FIX: opening the global Topic map directly should not cause an issue
* FIX: t… ransitioning between a Category map and the global map should now work correctly
FIX: opening the global Topic map directly should not cause an issue
FIX: transitioning between a Category map and the global map should now work correctly
Non-functioning WIP map tests
@vincefrommtl , @Stephane_Roy @packman could you please give this update a try? Note the scope of the fixes. Another fix coming soon.
(Technical note: due to Leaflet library being a global object, apparently QUnit cannot see it, so I’ve not been able to provide fully integrated FE tests for these fixes - if anyone knows how I might get Leaflet and QUnit to play together please let me know)
3 Likes
My feedback:
Transitioning between the global map and a category map is working. But the opposite is broken (category map to global map), just like category to category.
I have not seen this error in my log since I upgraded: ActionView::Template::Error (No route matches {:action=>"map_feed", :controller=>"list"})
.
New bug: Sometimes, clustered links on the map are only showing the position marker on the map when zoomed in, not the label.
New bug: Sometimes, labels of markers on the map are not linking to the corresponding topic.
New bug: the global map is now affected by the same bug as category maps: only showing a few markers (see below).
Concerning maps that have fewer markers than supposed to: I took a good look at it, and it’s only showing markers for topics active in the last 20 days (or something like that), and a maximum of 30 of them. Is it possible it’s a configuration issue on our forum? It seems very specific! But we did not change anything in those settings. I have a maximum of 1700 location map max topics and I don’t think there is any setting related to time that would lead to only show markers from topics active in the last 20 days?
1 Like
packman
(Chris McMahon)
August 6, 2023, 12:52pm
920
After upgrading I opened the global map and there were no markers (topic) displayed. If I edit the location for a topic with a marker and just save with no changes the marker appears. All my markers are over 20 days old so maybe this is the same issue that @vincefrommtl is seeing?
Edit: The Show Map button for each topic still shows the correct marker location when that marker doesn’t display on the global map.
1 Like
merefield
(Robert)
August 6, 2023, 1:04pm
921
Thanks guys, I’ll take another look.
2 Likes
merefield
(Robert)
August 6, 2023, 6:49pm
922
This is not a full fix but should I believe, restore the old topic locations whilst avoiding the map error when loading directly from an external link or a browser refresh:
paviliondev:main
← paviliondev:map_route_fixes
opened 06:23PM - 06 Aug 23 UTC
Known issue: I haven’t solved the direct Map => Category Map transition (but this should be an edge case), but everything else should be better.
1 Like
packman
(Chris McMahon)
August 6, 2023, 8:40pm
923
I’ll test tomorrow but a user has just pointed out that US locations are now being named as City, Country, State, e.g. Atlanta, US, Georgia
Quick test: I can confirm that I can see every markers on the map with this new update. Thank you very much.
For the moment I will advise my users not to jump from one Category Map to another, to bypass the broken transition.
1 Like
merefield
(Robert)
August 7, 2023, 7:03am
925
The only recent changes are related to the map population.
packman
(Chris McMahon)
August 7, 2023, 9:26am
926
The country/state order isn’t the very latest version. I mentioned it because I don’t remember seeing that in before the versions of the last couple of days.
1 Like
merefield
(Robert)
August 7, 2023, 11:47am
927
@packman for now I’ve fixed your earlier issue:
paviliondev:main
← paviliondev:default_topic_from_user_location_fix
opened 01:29PM - 28 Jul 23 UTC
and this is now covered by tests.
thanks again to @david for getting me out of the bunker on that one.
3 Likes
blake
(Blake Erickson)
August 9, 2023, 4:46pm
928
@merefield Hey just a heads up, the modify_user_params
method has been deprecated for sometime now, and will be removed soon now that Discourse is on version 3.2.0.beta1-dev
discourse-locations/lib/users_map.rb
35: def modify_user_params(attrs)
Could you work on updating it to use the users_controller_update_user_params
modifier when you get a chance? Thanks!
1 Like
merefield
(Robert)
August 9, 2023, 4:50pm
929
sure, thanks for the additional heads up, I’ll look at it this week.
1 Like
merefield
(Robert)
August 10, 2023, 7:22pm
930
Blake, this is done, mind if I add you as reviewer?
paviliondev:main
← paviliondev:user_controller_method_deprecation
opened 05:45PM - 10 Aug 23 UTC
3 Likes
Richie
(Richie Rich)
August 12, 2023, 11:00am
933
Sorry to bring bad news, but I have a bug report.
We’re currently running latest, we updated this morning: 3.2.0.beta1-dev (7ca5ee6cd2 )
Running in to a strange issue, which wasn’t present two weeks ago when we last updated, whereby we can no longer edit a user profile if they have custom fields.
I wish to edit this user: https://example.com/u/username/preferences/profile
Page loads fine:
As soon as I click on Save, I get an error:
This came to light because one of our other web sites updates the “membership” custom field when our club members upgrade, and it the Discourse API endpoint was throwing a 500 error.
This is evident when I try to repro using Postman too:
The discourse logs show:
and:
plugins/discourse-locations/plugin.rb:188:in `block (2 levels) in activate!'
lib/discourse_plugin_registry.rb:293:in `apply_modifier'
app/controllers/users_controller.rb:2036:in `user_params'
app/controllers/users_controller.rb:198:in `update'
actionpack (7.0.7) lib/action_controller/metal/basic_implicit_render.rb:6:in `send_action'
actionpack (7.0.7) lib/abstract_controller/base.rb:215:in `process_action'
actionpack (7.0.7) lib/action_controller/metal/rendering.rb:165:in `process_action'
actionpack (7.0.7) lib/abstract_controller/callbacks.rb:234:in `block in process_action'
activesupport (7.0.7) lib/active_support/callbacks.rb:118:in `block in run_callbacks'
app/controllers/application_controller.rb:420:in `block in with_resolved_locale'
i18n (1.14.1) lib/i18n.rb:322:in `with_locale'
app/controllers/application_controller.rb:420:in `with_resolved_locale'
activesupport (7.0.7) lib/active_support/callbacks.rb:127:in `block in run_callbacks'
activesupport (7.0.7) lib/active_support/callbacks.rb:138:in `run_callbacks'
actionpack (7.0.7) lib/abstract_controller/callbacks.rb:233:in `process_action'
actionpack (7.0.7) lib/action_controller/metal/rescue.rb:23:in `process_action'
actionpack (7.0.7) lib/action_controller/metal/instrumentation.rb:67:in `block in process_action'
activesupport (7.0.7) lib/active_support/notifications.rb:206:in `block in instrument'
activesupport (7.0.7) lib/active_support/notifications/instrumenter.rb:24:in `instrument'
activesupport (7.0.7) lib/active_support/notifications.rb:206:in `instrument'
actionpack (7.0.7) lib/action_controller/metal/instrumentation.rb:66:in `process_action'
actionpack (7.0.7) lib/action_controller/metal/params_wrapper.rb:259:in `process_action'
activerecord (7.0.7) lib/active_record/railties/controller_runtime.rb:27:in `process_action'
actionpack (7.0.7) lib/abstract_controller/base.rb:151:in `process'
actionview (7.0.7) lib/action_view/rendering.rb:39:in `process'
actionpack (7.0.7) lib/action_controller/metal.rb:188:in `dispatch'
actionpack (7.0.7) lib/action_controller/metal.rb:251:in `dispatch'
actionpack (7.0.7) lib/action_dispatch/routing/route_set.rb:49:in `dispatch'
actionpack (7.0.7) lib/action_dispatch/routing/route_set.rb:32:in `serve'
actionpack (7.0.7) lib/action_dispatch/journey/router.rb:50:in `block in serve'
actionpack (7.0.7) lib/action_dispatch/journey/router.rb:32:in `each'
actionpack (7.0.7) lib/action_dispatch/journey/router.rb:32:in `serve'
actionpack (7.0.7) lib/action_dispatch/routing/route_set.rb:852:in `call'
lib/middleware/omniauth_bypass_middleware.rb:74:in `call'
rack (2.2.8) lib/rack/tempfile_reaper.rb:15:in `call'
rack (2.2.8) lib/rack/conditional_get.rb:40:in `call'
rack (2.2.8) lib/rack/head.rb:12:in `call'
actionpack (7.0.7) lib/action_dispatch/http/permissions_policy.rb:38:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:389:in `call'
lib/middleware/gtm_script_nonce_injector.rb:10:in `call'
rack (2.2.8) lib/rack/session/abstract/id.rb:266:in `context'
rack (2.2.8) lib/rack/session/abstract/id.rb:260:in `call'
actionpack (7.0.7) lib/action_dispatch/middleware/cookies.rb:704:in `call'
actionpack (7.0.7) lib/action_dispatch/middleware/callbacks.rb:27:in `block in call'
activesupport (7.0.7) lib/active_support/callbacks.rb:99:in `run_callbacks'
actionpack (7.0.7) lib/action_dispatch/middleware/callbacks.rb:26:in `call'
actionpack (7.0.7) lib/action_dispatch/middleware/debug_exceptions.rb:28:in `call'
actionpack (7.0.7) lib/action_dispatch/middleware/show_exceptions.rb:29:in `call'
logster (2.12.2) lib/logster/middleware/reporter.rb:43:in `call'
railties (7.0.7) lib/rails/rack/logger.rb:40:in `call_app'
railties (7.0.7) lib/rails/rack/logger.rb:27:in `call'
config/initializers/100-quiet_logger.rb:20:in `call'
config/initializers/100-silence_logger.rb:29:in `call'
actionpack (7.0.7) lib/action_dispatch/middleware/remote_ip.rb:93:in `call'
actionpack (7.0.7) lib/action_dispatch/middleware/request_id.rb:26:in `call'
lib/middleware/enforce_hostname.rb:24:in `call'
rack (2.2.8) lib/rack/method_override.rb:24:in `call'
actionpack (7.0.7) lib/action_dispatch/middleware/executor.rb:14:in `call'
rack (2.2.8) lib/rack/sendfile.rb:110:in `call'
actionpack (7.0.7) lib/action_dispatch/middleware/host_authorization.rb:131:in `call'
message_bus (4.3.7) lib/message_bus/rack/middleware.rb:60:in `call'
lib/middleware/request_tracker.rb:233:in `call'
railties (7.0.7) lib/rails/engine.rb:530:in `call'
railties (7.0.7) lib/rails/railtie.rb:226:in `public_send'
railties (7.0.7) lib/rails/railtie.rb:226:in `method_missing'
rack (2.2.8) lib/rack/urlmap.rb:74:in `block in call'
rack (2.2.8) lib/rack/urlmap.rb:58:in `each'
rack (2.2.8) lib/rack/urlmap.rb:58:in `call'
unicorn (6.1.0) lib/unicorn/http_server.rb:634:in `process_client'
unicorn (6.1.0) lib/unicorn/http_server.rb:739:in `worker_loop'
unicorn (6.1.0) lib/unicorn/http_server.rb:547:in `spawn_missing_workers'
unicorn (6.1.0) lib/unicorn/http_server.rb:143:in `start'
unicorn (6.1.0) bin/unicorn:128:in `<top (required)>'
vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `load'
vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `<main>'
Strangely, I can edit my OWN profile and update the custom user fields just fine.
But I can no longer edit any other user, and neither can system
perform the updates through our API either.
If I disable the Locations plugin, everything works fine again:
3 Likes
merefield
(Robert)
August 12, 2023, 11:08am
934
@Richie thanks for your report.
I can reproduce this.
It only seems to happen when someone does not have a location.
This code was recently refactored due to a deprecation in core and I’ve missed (a pretty big) case.
I’ll patch it soon.
5 Likes
Richie
(Richie Rich)
August 12, 2023, 11:41am
935
Ah, so maybe me editing my own profile successfully was a red herring, as I do have a location on mine
Robert:
I’ll patch it soon
No worries, thanks for the continued support
merefield
(Robert)
August 12, 2023, 1:10pm
936
I believe that should be fixed now:
paviliondev:main
← paviliondev:user_fields_fix
opened 12:49PM - 12 Aug 23 UTC
8 Likes
Richie
(Richie Rich)
August 13, 2023, 6:54am
937
Update this morning, no more HTTP/500 errors.
Thanks for the speedy fix Robert
3 Likes