ilml-plugin-linkedin 1.20.10 → 1.20.12
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +12 -0
- package/dist/connect.mjs +34 -34
- package/dist/enrichProfile.mjs +16 -16
- package/dist/enrichProfiles.mjs +49 -49
- package/dist/funnelRunner.mjs +26 -26
- package/dist/readPost.mjs +12 -10
- package/dist/run.mjs +47 -47
- package/dist/scout.mjs +31 -29
- package/dist/syncAll.mjs +74 -74
- package/dist/verifyAbout.mjs +18 -18
- package/dist/version.mjs +1 -1
- package/dist/visit.mjs +48 -48
- package/ilml-plugin.json +1 -1
- package/package.json +2 -2
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,17 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## 1.20.12
|
|
4
|
+
- **`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.
|
|
5
|
+
- **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.
|
|
6
|
+
- **`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.
|
|
7
|
+
- No schema change.
|
|
8
|
+
|
|
9
|
+
## 1.20.11
|
|
10
|
+
- **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.
|
|
11
|
+
- **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.
|
|
12
|
+
- **Fixed: `scout` aborted the whole run with "session expired" the moment LinkedIn showed its sign-in wall on a job search — even when your session was still good.** Job-search links trigger that wall more readily than other pages, and `scout` gave up instantly instead of recovering. It now self-heals the same way the rest of the plugin does (refresh via your feed, then return to the search) before concluding you're signed out, and only stops if it genuinely can't get back in.
|
|
13
|
+
- No schema change.
|
|
14
|
+
|
|
3
15
|
## 1.20.10
|
|
4
16
|
- **Fixed: `messages --push-drafts` could report a message as "sent" without actually delivering it.** When the draft's thread was already open in your inbox, the send ran on the shared messaging page and could land on the WRONG message box — a leftover floating chat bubble for a different person — then see that box clear and report "✓ sent" while the intended person received nothing. Push now prefers the reliable path that opens the recipient's own profile and confirms the recipient before sending (the same path `--send` has used since 1.17.2, which the draft push never actually adopted), and only falls back to the inbox path when no profile link is on file. A send that can't be confirmed is now reported as "failed" (your draft is kept) instead of a false "sent". Under the hood, the "did it actually send?" check is now one shared piece of logic used by both send paths, so it can't drift out of sync between them again.
|
|
5
17
|
- **Fixed: `messages --send "First Last" "text"` no longer sends a garbled fragment when the name or message contains spaces.** A quoted multi-word argument can get split on spaces before the plugin sees it, which could turn `--send "Jane Doe" "hi there"` into sending just a stray word. `--send` now detects the split and refuses with a clear message pointing you to the file-based form (`--send-batch @file.json`, or `--draft-batch @file.json` → `--push-drafts`), instead of delivering garbage.
|