ilml-plugin-linkedin 1.20.11 → 1.20.12

package/CHANGELOG.md

@@ -1,5 +1,11 @@
 # Changelog
 
+## 1.20.12
+- **`apply`, `scout`, `read-post` and `enrich` now recover on their own from LinkedIn's sign-in wall on the pages they open — completing the coverage begun in 1.20.9 and 1.20.11.** These commands open a page by a direct link (a job search, a post, a profile's detail page), which triggers LinkedIn's "join / sign in" screen more readily than clicking through the app does. Until now some of them still gave up on that screen — `apply` stopped with "not logged in", `scout` aborted the run, `read-post` reported an auth wall — even though the session was still valid. They now refresh through your feed and retry once, the same hands-free way the other commands do, and only report a real sign-in problem if the wall is still up afterwards.
+- **Fixed: `read-post` could report an auth wall on a post you were actually signed in to see.** Its readiness check matched an element that also renders on the logged-out wall, so it never triggered the recovery added in 1.20.11 and fell back to asking you to sign in. It now waits for a signed-in-only element, so recovery actually runs; and a rare crash when a page redirected mid-read is now handled.
+- **`enrich --with-experience` no longer risks overwriting saved profile data when a section is missing.** When a profile has no Experience (or other detail) section, LinkedIn silently bounces to the main profile page; the extractor now detects that and skips it (keeping your stored data) instead of parsing the unrelated page as fake entries.
+- No schema change.
+
 ## 1.20.11
 - **Fixed: `read-post` reported "Auth wall — cookies expired or not logged in" on a post you could actually open — even while every other command was signed in on the same account.** Opening a post by its direct link lands on LinkedIn's brief "signing you back in" screen more often than an in-app click does, and `read-post` decided too early that you'd been logged out, with no attempt to recover. It now waits through that screen and self-heals the same way the other commands do (reopens your feed to refresh the session, then retries the post), so a valid session reads the post instead of failing. It only reports a real sign-in problem if the wall is still up after recovery.
 - **Fixed (Windows): a `read-post` that hit that sign-in wall could leave a hidden browser open that blocked your next command.** On the way out it force-closed its browser in a way that doesn't work on Windows, so the browser stayed running and held the automation profile — and the next command failed with "another LinkedIn automation command is already running". `read-post` now closes its browser cleanly before it exits.