- Issue created by @tostinni
- π¦πΊAustralia thomwilhelm Sydney
Agree, report data should not be stored in configuration, as on each deployment it will be reset.
I've had a stab at moving this data to be stored in state data instead, including having an update hook to migrate this data.
I'll try running this on a few different sites shortly, if there are any issues I'll update the patch accordingly.
- First commit to issue fork.
- Status changed to Needs review
3 months ago 6:35pm 6 September 2024 - πΊπΈUnited States generalredneck
@thomwilhelm,
Your patch doesn't apply cleanly against 2.x. I'm not sure, but you may have made the patch against 8.x-1.x?
In any case, I took my best attempt at merging what you had with what I had come up with before I found this issue. I added a configuration schema to square things away a bit too.
Care to give it a try? I used a different key name than you did when I initially did my changes. Let me know if it looks like I missed anything you had implemented.
- πΊπΈUnited States generalredneck
@thomwilhelm,
I think your patch contained parts of π update report data permission not working Fixed .
- π¦πΊAustralia thomwilhelm Sydney
Hey @generalredneck just gave PR 17 a test and all worked nicely for me, thanks for rerolling, apologies for including those lines from the other ticket.
- πΊπΈUnited States generalredneck
No problem. When I get a chance I'll get it merged in.
- πΊπΈUnited States miwayha
I'd love to get this merged and deployed as soon as it's reasonable. Without this patch, this module has the risk to white screen on different environments that share config but may have a different database (e.g. local vs dev vs prod)
-
generalredneck β
committed cfda1304 on 2.x
Issue #3423079 by generalredneck, thomwilhelm, tostinni: Why are...
-
generalredneck β
committed cfda1304 on 2.x
- Status changed to Fixed
12 days ago 12:14pm 12 November 2024 Automatically closed - issue fixed for 2 weeks with no activity.