| [21:15:44] | <symbioquine[m]> | paul121 & jgaehring I tested that archive timestamp behavior... it looks like a bug to me;... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/e26a8f8e09...) |
| [21:15:47] | <symbioquine[m]> | Thoughts? |
| [21:18:32] | <symbioquine[m]> | Context for anyone else who wants to follow along: an offline client like FieldKit should presumably be able to record that an asset has been archived and have the archived date be the time that the action was taken, not the time the action was synced back to farmOS. The commands above create a new animal and attempt to archive it with a historical archive date. |
| [21:47:34] | <paul121[m]> | Haha `jq` is so cool :D |
| [21:49:44] | <paul121[m]> | But yeah, this makes sense that it updates the archived correctly when you send the request twice. That's due to the `AssetStorage::preSave` logic - IIRC it was checks for a state change from `active -> archived`, and in that case, it updates the archive timestamp |
| [21:50:00] | <paul121[m]> | s/was// |
| [21:52:16] | <paul121[m]> | The state change only happens the first time that request is sent |
| [21:55:13] | <paul121[m]> | Maybe we just need to check if the `archived` attribute changed between the `$old` and `$new` versions of the entity in the `::preSave` method? If it changed, then that means a new archived timestamp was specified, and should be used instead? |
| [21:55:33] | <paul121[m]> | (going off memory on some of this) |
| [01:33:04] | <symbioquine[m]> | Thanks for the tip! That seems to be it... |
| [01:33:40] | <symbioquine[m]> | This seemed to fix it;... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/458e1ab128...) |
| [01:34:13] | <symbioquine[m]> | I'll need to test a bit more thoroughly in the morning, but I'll probably send a PR then. :) |
| [01:41:42] | <paul121[m]> | That would be a simple fix! |
| [09:44:00] | <symbioquine[m]> | <paul121[m]> "That would be a simple fix!" <- Yeah, I think it's going to work :) |
| [09:53:51] | <mstenta[m]> | Cool! Good sleuthing symbioquine ! |
| [09:53:56] | <mstenta[m]> | Fix makes sense! |
| [09:54:12] | <symbioquine[m]> | Thanks! |
| [09:54:17] | <mstenta[m]> | One thought: do we set archived to null if it gets unarchived? |
| [09:54:23] | <mstenta[m]> | If not, then that might not be null |
| [09:54:43] | <symbioquine[m]> | Yeah, I'm curious about what should happen in those cases too... |
| [09:55:02] | <symbioquine[m]> | i.e. setting the archived date to a non-null value while the asset is still active |
| [09:55:06] | <mstenta[m]> | I forget if we handle that in pho |
| [09:55:11] | <mstenta[m]> | PHP* |
| [09:55:17] | <symbioquine[m]> | and setting the archived date to null when the asset is archived |
| [09:55:39] | <symbioquine[m]> | I suspect that should trigger the state changes... |
| [09:55:54] | <symbioquine[m]> | Otherwise it leaves the asset in an inconsistent state. |
| [09:56:43] | <symbioquine[m]> | However, it gets more complex if the intention was to support additional asset states via contrib modules. |
| [11:21:34] | <paul121[m]> | One approach could be to add an entity validation condition that ensures the state and archived fields are correct |
| [11:23:20] | <paul121[m]> | If you tried to update the archived timestamp while it is active, it would return an error via JSONAPI |
| [12:25:45] | <symbioquine[m]> | mstenta: Do you know of any use-cases where a contrib module would want to define additional asset states beyond active/archived? If not, my inclination would be to code the archived date logic based on that assumption and wait for such a use-case to arise... |
| [12:40:37] | <botlfarm[m]> | Quick question. Im working on my first 2.x migration form 1.x when running the "drush migrate:import --group=farm_migrate_area" I get an error " IllegalArgumentException: Points of LinearRing do not form a closed linestring". Any thoughts on this? |
| [12:46:10] | <symbioquine[m]> | Maybe related to https://farmos.discourse.group/t/issue-adding-area-from-coordinates-kml/... (In that there could be differences in the pure-PHP geometry parsing vs GEOS. |
| [12:46:13] | <symbioquine[m]> | ) |
| [12:47:33] | <symbioquine[m]> | * vs GEOS.) |
| [12:56:29] | <botlfarm[m]> | Thanks. Any idea on tracking down which land asses may be causing this problem without going in and checking them 1 at a time? |
| [13:10:40] | <botlfarm[m]> | Actually looks like I found an area in my production site that will not even open. When I click on it I get "The website encountered an unexpected error. Please try again later." I only have a handful of logs associated with this area, I don't use it very often. |
| [14:15:14] | <mstenta[m]> | botlfarm try opening the edit form for that asset directly if you can |
| [14:15:34] | <mstenta[m]> | Sounds like an invalid geometry |
| [14:15:46] | <mstenta[m]> | A polygon that doesn't close |
| [14:15:59] | <mstenta[m]> | You may be able to fix it if you can get to the edit form |
| [14:16:08] | <mstenta[m]> | Otherwise you might need to edit the database directly |