Nimble Lead to Cash -- WordPress 插件

开发者	nimbleplugin
更新时间	2026年11月9日 20:43
PHP版本:	8.1 及以上
WordPress版本:	7.1
版权:	GPLv2 or later
版权网址:	版权信息

1.37.58

An unread notification now shows in the browser tab itself. The bell inside the app can only be read while you are looking at the app, and a message is worth the most when you are doing something else. The tab title now carries the count - "(2) Lead to Cash" - and the tab icon carries a red badge with the same number.
When the app is installed on the machine, the application icon's own badge is set as well. All three follow the same number as the bell, and they fail independently: if the icon cannot be redrawn, the count still stands in the title.
The app stopped asking for notifications as soon as the tab was hidden. That is exactly the case the badge exists for, so it keeps asking now.

1.37.57

Et tal i menuen peger nu paa sine egne raekker. Henvendelser, Kunder, Opgaver, Fakturaer og Afsluttede kan alle vise et tal, men det sagde kun hvor mange - ikke hvilke, og den ene opgave bag et 1-tal skulle findes i hovedet. De raekker, tallet er talt paa, faar nu en blaa markering i listen.
Markeringen kommer fra serveren sammen med tallet, saa badgen og listen ikke kan blive uenige: det er de samme raekker begge veje. Aabner man et afsnit, hvor tallet slukkes ved at se det - Kunder og Afsluttede - bliver markeringen staaende besoeget ud, saa man naar at se hvad der var nyt.
Tallet ved Kunder taeller nu kunder i stedet for vundne henvendelser. Vandt en kunde to henvendelser siden sidst, sagde det to om en liste, der kun havde en enkelt raekke at vise for det.

1.37.56

En afsluttet kunde uden nogen oekonomi er nu maerket i kundelisten. Det er seks nuller i traek - ingen opgave, ingen faktura, intet faktureret, intet anslaaet, intet udestaaende - som ellers skulle laegges sammen i hovedet for hver raekke. Den er enten aldrig blevet til noget eller lukket for tidligt, og begge dele er vaerd at faa oeje paa.
En sletning er markeret med roedt i loggen. Resultatfeltet siger kun om handlingen lykkedes, ikke hvor meget den fjernede, saa en vellykket sletning saa ud som enhver anden linje. Det gaelder enhver sletning, ikke kun kunder: det er handlingen, der ikke kan fortrydes.

1.37.55

Adressen en faktura sendes til kan rettes, ogsaa efter at den er sendt. En faktura baerer sin egen kopi af kunden, taget da den blev dannet, og den kopi var laast sammen med belob og linjer. Var adressen tastet forkert, kunne fakturaen derfor aldrig naa kunden: at rette kundekortet hjalp ikke, for fakturaen laeser sin egen kopi, og den eneste vej uden om var at taste adressen ind i haanden i sende-dialogen hver eneste gang. Nu rettes den paa fakturaen, og aendringen staar i fakturaens forlob med foer og efter. Belob, linjer, navn og fakturaadresse er fortsat laaste - det er hele grunden til at en sendt faktura er laast.

1.37.54

1.37.53 tog hele sitet ned, hvis Pro var aeldre end Free. AuditTrail fik en paakraevet fjerde parameter, men Pro booter sin egen kopi af den klasse og kaldte fortsat med tre. Parameteren er nu valgfri, saa en aeldre Pro ikke kan vaelte Free igen.

1.37.53

Loggen skrev "AEndrede opgave" uden at sige hvilken. Navnet paa det beroerte element gemmes nu, naar handlingen sker - opgavenummer, titel og kunde - og vises i loggen. At slaa det op bagefter ville efterlade netop sletningerne uden navn, for der findes raekken ikke mere.
Slettes en henvendelse, en kunde eller en opgave helt, staar det nu i loggen med navnet paa det, der blev slettet.
Over halvdelen af loggen var brugerflade-husholdning: markering af badges som set, aabning af dagens overblik, laesning af notifikationer. Det logges ikke laengere. Kun handlinger paa forretningsdata.
Titler og emner ligger krypteret og blev aldrig sammenlignet, saa loggen kunne kun sige at titlen "blev angivet". De laeses nu, saa aendringen staar med foer og efter.
Feltnavne blev filtreret bort, hvis de lignede noget personfoelsomt, saa en aendret adresse forsvandt helt ud af loggen. Navnet paa et felt er ikke det foelsomme - vaerdien er. Navnene staar nu altid, mens vaerdierne for personoplysninger fortsat holdes ude.
Loggens taeller svarede 0, mens listen leverede en fuld side, saa Forrige og Naeste aldrig kunne virke. Taellingen stiller nu samme spoergsmaal som listen.

1.37.52

En opgave kan nu holde flere tilsyn. Hvert tilsyn har titel, status, planlagt og udfoert tidspunkt, varighed, hvem der var der og en bemaerkning, og de staar som en liste paa opgaven. Foer dette var den eneste maade at notere to tilsyn paa at skrive det i opgavens titel, hvor ingen optaelling eller sum kunne laese det.
Registreret tid paa en opgave er nu summen af de tilsyn, der er markeret udfoert, og vedligeholdes automatisk. Opgaver uden tilsyn beholder det tal, der er skrevet i haanden.
Loggen blev tegnet tom for brugere, der har Lead to Cash-rettighederne, men ikke ogsaa er WordPress-administratorer. Menupunktet blev vist ud fra den rettighed, serveren faktisk kraever, mens indlaesningen spurgte efter WordPress' manage_options og derfor aldrig sendte forespoergslen. Siden saa tom ud uden fejlbesked, mens raekkerne laa urorte i databasen. Begge steder bruger nu samme port som serveren.

1.37.51

Aendringsloggen i readme.txt stoppede ved 1.37.29, og det er den, der vises paa plugin-siden hos wordpress.org. Enogtyve udgivelser var dermed usynlige for alle, der ikke havde pakken i forvejen. Posterne fra 1.37.30 og frem er nu skrevet ind, saa siden viser det samme som changelog.txt.
Ingen aendringer i kode eller funktion.

1.37.50

Opretter man en kunde direkte, bliver der nu spurgt, om der skal laves en henvendelse paa kunden. Svarer man ja, aabner henvendelsen med kunden udfyldt. Det er ikke et krav - flytter man et bestaaende kundekartotek ind, er svaret nej hver gang, og et krav ville spaerre for det.
Kunder uden en henvendelse er maerket "Ingen henvendelse" ved navnet i kundelisten. Foer stod der et nul i henvendelseskolonnen, som var let at overse, og i Pro stod der ingenting. Uden en henvendelse er der intet at haenge en pris, en opgave eller en faktura paa, og kunden staar uden for henvendelsestallene.

1.37.49

En faktura, der naevner sin egen opgave, lukkede ogsaa kundens andre opgaver paa samme henvendelse. En kunde her har en vaskehal og et salgskontor paa samme henvendelse; regningen for salgskontoret fik vaskehallens 43.250 kr. til at forsvinde ud af baade kundekolonnen og "Samlet opgavevaerdi". Kun bilag uden egen opgave lukker nu en opgave paa henvendelsen - naevner bilaget en opgave, har det betalt for den opgave, ikke for de andre.
Kontakter, der er sat til at blive holdt ude af tallene, taelles ikke laengere med i summerne paa kundeoversigten. Tre proevefakturaer paa en krone fik "Faktureret netto" til at staa 3,00 kr. over rapportens tal. Raekken viser fortsat sit eget beloeb; det er summen, flaget handler om.

1.37.48

Afslutter man en kunde, der stadig har en aaben opgave, bliver der nu spurgt foerst, og opgavens nummer og titel staar i spoergsmaalet. Opgaven forsvinder ikke af at kunden lukkes - den holder bare op med at ligge oeverst, og dens budget bliver ved at staa i tallene som arbejde, der venter paa en regning.
Ikke en spaerring: svarer man ja, afsluttes kunden. Afslaget kommer fra serveren, saa det gaelder ogsaa et API-kald, ikke kun listen.

1.37.47

"Samlet opgaveværdi" lagde det fakturerede sammen med alle prissatte opgaver, men udelukkede kun en opgave, hvis fakturaen pegede direkte paa den. De fleste bilag peger paa henvendelsen i stedet, saa betalt arbejde blev talt med baade som faktureret og som forventet - paa denne installation 16.000 kr. for meget.
Tallet regnes nu samme sted som kundelistens kolonne: opgavebudget hvor der ikke er faktureret, ellers estimatet paa henvendelsen, aldrig to kilder paa samme henvendelse. Estimaterne er dermed med, hvor de foer manglede helt.
job_expected_ex_vat_minor staar uroert for dem, der laeser det; det nye tal hedder uninvoiced_value_ex_vat_minor.

1.37.46

"Estimeret, ikke faktureret" kunne staa ved siden af et beloeb, der allerede var faktureret. Udelukkelsen spurgte kun, om fakturaen bar henvendelsens id, men de fleste bilag goer ikke - de henfoeres via opgaven eller via kundens senest vundne henvendelse foer bilaget. En faktureret henvendelse saa derfor ufaktureret ud, og dens estimat blev talt med oveni. Samme arbejde to gange.
Udelukkelsen bruger nu samme tre trin som rapporten, gennem den faelles LeadAttribution, saa der kun er ét sted at rette reglen.

1.37.45

"Estimeret, ikke faktureret" talte kun budgetter paa opgaver. En kunde med 41.907 kr. i estimat paa selve henvendelsen og ingen opgave stod derfor stadig med 0,00 kr., mens kundekortet viste estimatet lige nedenunder. To skaerme, samme kunde, to svar.
Vaerdien tages nu fra den bedste kilde henvendelsen har, i samme raekkefoelge som rapporten bruger: er der faktureret, taeller intet her; ellers opgavebudgettet; ellers estimatet paa henvendelsen. Aldrig to af dem paa samme henvendelse - et estimat og et opgavebudget er to gaet paa det samme arbejde, ikke to stykker arbejde.

1.37.44

Kundeoversigten viser nu ogsaa totalerne "Faktureret netto" og "Estimeret, ikke faktureret" ved siden af udestaaende. De tre svarer paa hver sit spoergsmaal om de samme kunder - hvad der er sendt regning paa, hvad der ligger paa opgaverne uden at vaere faktureret, og hvad der mangler at blive betalt - og hver for sig er de til at misforstaa.

1.37.43

Kundeoversigten viser nu ogsaa "Estimeret, ikke faktureret". En kunde med en opgave til 20.000 kr. stod med 0,00 kr. i begge beloebskolonner, og begge tal var rigtige - der var ikke faktureret noget, og der skyldtes derfor heller ikke noget - men listen saa ud, som om der slet ikke laa arbejde paa kunden.
Beloebet er budgettet paa opgaven, ikke en pris kunden har accepteret. Derfor hedder kolonnen "estimeret" og ikke "aftalt".
En opgave taelles kun med, hvis hverken den selv eller dens henvendelse har en faktura. Fakturaen haenger ikke altid paa opgaven, og uden den regel ville en opgave til 10.000 med 6.000 faktureret staa med hele sit budget ved siden af de 6.000 i fakturerings-kolonnen - det samme arbejde talt to gange. Reglen underdriver hellere end at puste op.

1.37.42

Kolonneoverskriften "Faktureret netto" stod paa engelsk i en dansk brugerflade. Overskrifterne oversaettes gennem i18n, og den nye stod ikke paa listen - saa den faldt tilbage til sin engelske kildetekst og var den eneste engelske overskrift i tabellen.

1.37.41

Et bilag henfoeres ikke laengere til en henvendelse, der foerst blev vundet bagefter. Reglen satte sit svar til kundens aeldste vundne henvendelse, foer den begyndte at lede, og var alle vundet efter bilaget, blev den foerste returneret alligevel - en faktura fra marts kunne saaledes staa paa en henvendelse vundet i maj. Omsaetningen forsvandt ikke, men den laa paa det forkerte arbejde. Nu vaelges intet, naar intet var vundet i tide, og bilaget taelles som ikke henfoert, hvor det kan ses.
Kundeoversigten viser nu "Faktureret netto" ved siden af udestaaende. De to er blevet forvekslet, og det er til at forstaa: en kunde med en betalt faktura paa 20.000 stod med 0,00 kr., fordi 0 var det rigtige svar paa et andet spoergsmaal. Beloebet er uden moms, kreditnotaer traekker fra, og hvert bilag taelles én gang. Kilden er den samme tabel som udestaaende regnes af.
Rapporten har faaet fem vaerdikategorier, der udelukker hinanden og summerer til de vundne henvendelser: faktureret, aftalt men ikke faktureret, kun estimat, og uden registreret vaerdi - med delvist faktureret som en delmaengde af faktureret, ikke en kategori for sig. Et estimat regnes aldrig som en accepteret ordre. De hidtidige felter staar uroert ved siden af.
Diagnosen taeller nu ogsaa de bilag, rapporten aldrig ser: fakturaer til en kunde uden en eneste vundet henvendelse, og fuldt krediterede par. Begge dele hoerer med rette udenfor, men en sum, der udelader noget uden at sige det, er svaer at afstemme mod regnskabet.

1.37.40

Ny read-only diagnose af hvordan en vundet henvendelse fik sin vaerdi. Rapporten kunne sige "elleve henvendelser uden kendt vaerdi", men ikke hvilke elleve, hvad der blev ledt efter, eller hvorfor der intet blev fundet - og saa kunne tallet ikke efterproeves af andre end den, der ville laese forespoergslerne igennem. Ruten svarer paa netop det: pr. henvendelse vaerdikilden og aarsagen, pr. bilag hvilken henvendelse det blev henfoert til, ved hvilken af de tre metoder, og om valget var rettidigt. Den skriver intet, hverken her eller i regnskabet.
Adgangen er rapportens egen, og en begraenset konsulent afvises af selve ruten - at skjule et menupunkt er ingen adgangskontrol. Svaret indeholder public id'er, datoer, beloeb og metoder, og hverken navne, e-mail, telefon eller adresser.
Reglen for hvilken henvendelse et bilag hoerer til er flyttet fra rapporten ud i en faelles service, saa diagnosen og rapporten svarer det samme. To kopier ville foer eller siden give to svar paa det samme spoergsmaal. Flytningen aendrer ingen tal: den er ordret, og en proeve haandhaever det.

1.37.39

En kreditnota er ikke en faktura, der venter paa penge. Fakturalisten talte kreditnotaerne med blandt de sendte: tre af dem fik "Sendt" til at staa paa fem, mens to fakturaer faktisk var ude. En krediteret faktura havde laenge haft sin egen rubrik, men selve kreditnotaen faldt igennem til sin almindelige status - og en kreditnota er "sendt" som ethvert andet dokument. Den har nu sin egen taelling, saa fliserne stadig svarer til raekkerne i listen. Beloebene var rigtige i forvejen; de modregnede parret.

1.37.37

Ny status Ikke relevant. Manden der troede vi var kommunen, henvendelsen fra den anden ende af landet, leverandoeren der ringede paa salgsnummeret - de skal modtages og besvares som alt andet, men at arkivere dem som "Tabt" siger, at vi bod paa arbejdet og tabte. Det traekker vindprocenten ned for arbejde, ingen nogensinde har haft. Den nye status lukker henvendelsen - ingen opfoelgning, ikke "aaben" - og holdes ude af salgstallene.
Henvendelser taget af en maskine taeller foerst med, naar et menneske har set paa dem. En AI-telefonbesked er et gaet paa hvad opkaldet handlede om, og et gaet hoerer ikke hjemme i en konverteringsrate. Den staar ude af salgstallene saa laenge status er "Ny", og taeller fra det oejeblik nogen giver den en rigtig status - i den uge opkaldet kom, for det var da telefonen ringede.
Og den mekanisme virkede slet ikke foer. Lead to Cash har haft filteret nimble_ltc_non_sales_mediums siden tidligere, og telefonsvareren meldte sig korrekt til det - men mediet gemmes gennem sanitize_key(), saa "AI-telefonsvarer · ikke-salg" bliver til ai-telefonsvarerikke-salg. Filteret sammenlignede den uberoerte tekst med den gemte, de moedte aldrig hinanden, og alt det der skulle holdes ude blev talt med. Medierne sammenlignes nu efter samme normalisering.

1.37.36

Mærkater som "E-mail" bryder ikke laengere midt over. Bindestregen var et lovligt sted at bryde, saa en smal kolonne delte pillen i "E-" og "mail".
Hjaelpeteksten under Betalingsoplysninger stod paa engelsk i en dansk graenseflade. Den er nu i oversaettelseskataloget som alle de andre.

1.37.35

Etiketten for skatte-id laeses fra den oekonomiske profil, ikke fra sprogvalget. Vaerdien ligger under config.economic; laest fra toppen, som foerste forsoeg gjorde, faldt den tavst tilbage paa sproget - hvilket saa rigtigt ud i begge de oplagte tilfaelde og ville have vaeret forkert i ethvert blandet.
Annullér i bekraeftelsesdialogen er daempet. Alle knapper i appen baerer samme blaa gradient, saa den sikre udvej laeste som hovedhandlingen.
Badgen ved Fakturaer taeller nu det samme som ordet ved siden af. Den sagde "over forfald", men talte ogsaa fakturaer, der var annulleret i fuld af en kreditnota - de bliver staaende som sendt, naar der aldrig blev betalt noget paa dem - og fakturaer, der forfalder i dag. Kunden faar dagen ud, og en krediteret faktura er et doedt krav. Hovedsiden, betalingspaamindelserne og rykkerplanen gjorde det rigtigt i forvejen; badgen var den sidste.
Faerdiggoer faktura spoerger nu inde i appen i stedet for i browserens egen systemboks. Den kunne ikke styles, baerer vaertsnavnet og ligner paa en telefon en advarsel fra et helt andet sted.
Indstillinger kunne ikke gemmes, naar et paakraevet felt paa en anden fane var tomt. Browseren naegtede at indsende, proevede at saette markoeren i et skjult felt, kunne ikke, og sagde det kun i konsollen. Paa en ny installation gjorde det firmaoplysninger umulige at gemme - og bagefter klagede faerdiggoerelsen over, at de manglede. "Paakraevet" foelger nu den fane, man kan se.
Manglende firmaoplysninger siges nu paa kladden, foer fakturaen skrives, og med en knap til hvert felt der mangler. Felterne ligger paa to forskellige faner, og beskeden pegede ingen steder hen.
Feltet CVR hedder nu Tax ID, naar sproget ikke er dansk. Navnet kom fra den oekonomiske profil i forvejen - fakturaens PDF brugte det - kun indstillingsfeltet havde sit eget, haardkodede ord.
Betalingsoplysninger har faaet en forklaring. Felterne omkring det havde en.
Et klik paa en notifikation aabner nu den post, den handler om. Den sendte til listen, og listen beholder det statusfilter, der sidst blev brugt - saa en besked om en sendt faktura kunne lande paa en liste filtreret til betalt, hvor fakturaen slet ikke stod. Posten har altid baaret sit eget id med; ingen brugte det. Notifikationer om kalender og kvitteringer hoerer til Pro, og uden Pro skete der ingenting ved et klik - nu siges det.

1.37.31

En besked paa pluginnets egne skaermbilleder fortaeller at Pro findes, og linker til produktsiden. Den vises kun dér - ikke paa Kontrolpanelet, Indlaeg eller Plugins - den tier helt naar Pro-tillaegget koerer, og den kan lukkes med X'et. Lukningen gemmes pr. bruger og gaelder derefter.

1.37.30

Appen svarede "No route was found matching the URL and request method." paa naesten alle sider, hvis sitet ikke bruger paene permalinks. REST-roden er saa index.php?rest_route=..., hvor ruten ligger inde i en parameter, og appen haengte sine egne parametre paa med ? i stedet for &. Hele halen blev en del af rutenavnet. Kald uden parametre gik igennem, saa appen virkede halvt.

Nimble Lead to Cash - full changelog readme.txt carries only the most recent entries, because the plugin directory truncates that section at 5000 characters. Everything is here. 1.37.29

Tabellen til udgaaende beskeder bliver nu faktisk oprettet naar en eksisterende installation opdaterer. Tabellen kom med i 1.37.28, men skemaversionen blev staaende paa 0.9.2, og opgraderingen koerer kun skematrinnet naar den vaerdi aendrer sig. En ny installation fik tabellen, en opdateret gjorde ikke - og fejlen kunne kun ses paa et site der havde pluginnet i forvejen.

1.37.28

Henvendelser tælles nu på hvornår de kom ind, ikke på hvornår de blev skrevet ned. En henvendelse fra juli, der først tastes ind i oktober, hørte til oktober i rapporten - så juli mistede den, og oktober fik en for meget. Feltet "Modtaget" på henvendelsen afgør det, og rapporten, ugetællingen og begge lister regner nu på det samme.

1.37.25

Gennemført én regel i rapporten: det realiserede vinder altid. Er der først en faktura på en opgave eller en henvendelse, ER fakturaen værdien, og budgettet eller det aftalte beløb tæller ikke med nogen steder - hverken som rest eller som et højere tal.
Restbeløbet på delvist fakturerede opgaver er fjernet helt.
"Gns. hvor værdien er kendt" tog før det største af det fakturerede og det aftalte. Et budget, ingen nogensinde fakturerede, kunne dermed slå den faktura, der afsluttede sagen. Nu er det fakturaen, når der er en.
"Aftalt, endnu ikke faktureret" dækker nu kun sager helt uden faktura.

1.37.24

Noterne under Samlet opgaveværdi er fjernet. Opdelingen står allerede på siden, og tre linjer under et tal gør kortet sværere at læse, ikke lettere.

1.37.23

Henvendelsesraten talte forud. Med en periode, der løb til 31. december, blev november og december regnet med som stille måneder, og raten blev delt med tid, der ikke var gået: 48 henvendelser blev til 9,1 om måneden i stedet for 18,7. Den regner nu frem til i dag, som ugelisten altid har gjort.

1.37.22

Rapporter målte værdi på henvendelser. En henvendelse er ikke en værdi, og en kunde er det heller ikke - værdien opstår først, når nogen skriver ned, hvad en opgave koster. Kortet hedder nu "Samlet opgaveværdi" og er det fakturerede plus budgettet på de opgaver, der endnu ikke er faktureret.
Er en opgave budgetteret højere, end den er faktureret, står forskellen frem som aftalt, ikke endnu faktureret arbejde. Før forsvandt den helt.
Rapportperioden starter som hele indeværende år, 1. januar til 31. december, i stedet for et vindue, der gled en dag frem hver morgen.

1.37.21

Statusfilteret "Alle" på opgavelisten skjulte de afsluttede. Det modsagde sit eget navn, og en afsluttet opgave kunne kun ses i den separate Afsluttede-visning. "Alle" betyder nu alle.
"Planlagt" er valgt som standard, for det er den liste, man handler på.

1.37.20

Opgaver kunne blive til tvillinger. Gemmestien afgjorde opret-eller-opdatér ud fra et data-attribut på formularen, som blev nulstillet, hver gang dialogen blev lukket. En formular, der havde mistet sit id, oprettede derfor en ny opgave i stedet for at gemme den, der stod på skærmen. Identiteten læses nu af selve posten; attributtet er kun et krydstjek.
Opretter du en opgave på en kunde, der allerede har en åben, viser appen de eksisterende og spørger, før den opretter. Serveren afviser en ubekræftet dublet og sender de åbne opgaver med tilbage, så spørgsmålet kan nævne dem. Det er et spørgsmål, ikke et forbud — to åbne opgaver på samme kunde er ofte rigtigt.
Nøgletallet på opgavelisten var ét tal, der lagde fakturerede beløb sammen med håndtastede budgetter, og som talte alle opgaver med — også de afsluttede, tabellen ikke viser. Samme arbejde kunne derfor tælle to gange: én gang som omsætning på den afsluttede opgave, én gang som forventning på tvillingen. Det er nu to tal — Faktureret og Forventet — og begge følger det, der står i listen, så filter og søgning virker på dem.
Økonomikolonnen blandede momsgrundlag: fakturerede opgaver viste beløb inklusive moms, resten viste budget uden. Alt vises nu ekskl. moms, og det står i kolonneoverskriften.

1.37.19

Appens adresse kan nu vælges. Har sitet allerede en side på /lead-to-cash/ — en produktside, en landingsside — nægtede pluginnet at blive aktiveret, og eneste udvej var at omdøbe den eksisterende side. Det er ikke rimeligt at forlange af et site, der havde adressen først. Sæt define( 'NIMBLE_LTC_APP_SLUG', 'din-slug' ); i wp-config.php før aktivering, så bruger appen den i stedet. Pro henter PWA'ens id, start_url, scope og Service-Worker-Allowed fra samme konstant, så det følger med.
Fejlbeskeden ved adressekonflikt sagde ikke, hvad man skulle gøre, og skrev altid "/lead-to-cash/" selv hvis appen lå et andet sted. Den viser nu den rigtige adresse og nævner konstanten.
Bemærk: ændrer man adressen på en eksisterende installation, skal permalinks gemmes igen, og PWA'en skifter scope, så genveje må tilføjes forfra.

1.37.18

Kundekortets overskrift stacker nu ordentligt på telefon. Henvisningen "Også kunde som …" klemte sig ind ved siden af navnet, wrappede over tre linjer og maste lukkekrydset. Navn og kryds beholder den første række, og henvisningen får en række for sig selv nedenunder. Et langt kundenavn kan ikke længere vokse chippen — den afkortes med ellipse.

1.37.17

Henvisningen "Også kunde som …" flugter nu med kundens navn i kortets overskrift, og den er endelig guld. Farverne gik før gennem en kæde af CSS-variabler inde i color-mix(); brister et led i den kæde, bliver variablen ugyldig, teksten arver hvid og baggrunden falder tilbage til den almindelige knapstil — præcis den blå, den ikke måtte være. Farverne står nu direkte, med en mørk guld til lyst tema og en lys til mørkt.

1.37.16

Henvisningen "Også kunde som …" er flyttet helt op i kortets egen overskrift, ved siden af kundens navn, og er nu guld. Guld bruges ikke andre steder i produktet, så den kan hverken forveksles med de blå handlingsknapper eller med noget andet. På smalle skærme falder den ned på sin egen linje.

1.37.15

Henvisningen "Også kunde som …" er flyttet op i toppen af kundekortet, lige under "Kontakt oprettet …", og har fået sin egen farve. Den lignede før en primær handlingsknap ved siden af "Opret tilbud" — temaet giver en bar den primære knapstil, og .link-button fandtes ikke i Free. Den er nu en chip i accentfarven, så den ikke forveksles med kortets handlinger.

1.37.14

Retter en fejl i 1.37.13, der gjorde alle kundekort ubrugelige med "Cannot set properties of null (setting 'hidden')". Henvisningslinjen "Også kunde som …" blev sat ind i skabelonen med forkert elementtype, så et </div> kom til at lukke et <section>. Resten af kortet endte dermed uden for DOM'en, og opslaget på det første element derefter gav null.

1.37.13

Privat og erhverv holdes nu adskilt på kundekortet. De samme mennesker er ofte kunde to gange med vilje — privat og gennem deres selskab — og det er to kunder med hver sine henvendelser og hvert sit regnskab. Henvendelser, handlinger og aktivitetslog blev slået sammen på tværs af kontakter med samme mail eller telefonnummer, så det private kort viste selskabets henvendelser og omvendt. Det gør de ikke længere.
I stedet står der øverst på kortet "Også kunde som …" med et klik over til den anden. Det er den ene linje, hvor de to kender hinanden.
1.37.12 slog fakturaerne sammen samme vej. Det er rullet tilbage: et kort viser sine egne fakturaer og sit eget udestående, så selskabets gæld ikke lander på privatpersonen.

1.37.12

Kundekortet viser nu fakturaerne for alle kontakter, der hører til samme person. En kunde kan ligge på mere end én kontaktrække — en privat og det selskab, der faktureres igennem, koblet på samme mail eller telefon — og henvendelserne og aktivitetsloggen har hele tiden vist dem alle. Kun fakturalisten gjorde det ikke, så kortet modsagde sig selv: loggen fortalte at en faktura var sendt, mens listen nedenunder sagde ingen fakturaer.
Værdikolonnen på henvendelserne viser det fakturerede beløb, når der er faktureret på opgaven, og ellers estimatet. Kladder tæller ikke med — der er intet faktureret, før dokumentet er udstedt — og kreditnotaer trækkes fra, så en krediteret opgave ikke står med penge, der er givet tilbage.

1.37.11

A credit note can be issued again. It has no due date - it is immediate, and the VAT rules ask a credit note for the same ten things they ask an invoice for, a due date among none of them - so the one the plugin creates correctly leaves that field empty. Finalising it then refused the note as its own work: "The due date is invalid." Three more places would have refused it next, and the dialog's date field was marked required, so the browser stopped the save before any of it. All four now make the exception for a credit note, and only for a credit note: an invoice without a due date is still refused.
The contact person can be set on an invoice. It is the "Att." line the document prints, and until now it was whatever stood on the customer when the invoice was made, with no way to change it. The invoice keeps its own copy of the customer, so a different att. here changes this one document and leaves the customer record, and every other invoice, alone - which is what is wanted when the work was agreed with one person and the invoice goes to another. Shown for business customers, because a contact person is not stored on a private one.

1.37.10

Luft mellem vilkårene og underskriften i tilbudsbrevet. Afstanden var mindre end mellem to linjer i afsnittet selv, så "Med venlig hilsen" lagde sig op ad den sidste betingelse og lignede en linje mere i vilkårene. The full history from 1.0.0 onwards is in changelog.txt, which ships with the plugin.

1.37.9

The payment QR code reaches the invoice the customer receives. A payment add-on fills the QR slot, and to build a code for one particular invoice it has to know which invoice it is - but the filter was called without it, leaving the add-on to work it out from the web address. That only matched the preview and download links, so the code appeared where the business looks and was missing from the PDF sent by email and from the archived copy. The invoice is now handed to the filter, and the same code appears wherever the invoice is rendered.

1.37.8

Signing in lasts. The session had a flat eight-hour life from the moment of signing in and was never extended - so a working day that began at eight ended with being signed out at four, mid-task, with a two-factor code to find. It now slides: an authenticated request pushes the expiry forward, throttled to the same five-minute write that already recorded activity, and a session in regular use stays valid. Fourteen days without use ends it, and a ceiling of ninety days from the sign-in applies however much it is used, so a session cannot live indefinitely.
A device can be remembered, so the two-factor code is not demanded on every sign-in. The choice appears beside the code field, and only when Nimble Security is installed and the site has turned remembered devices on. The password is still required on a remembered device - only the code is skipped - and the device can be removed again from Nimble Security at any time.

1.37.7

The enquiry, customer and job screens are usable on a phone again. Their two columns never stacked: the activity sidebar held its 280px floor while the form column gave up everything, leaving it 114px wide on a 412px screen, with every field clipped to a few letters. The stacking rule existed, but a media query carries no specificity, so the general rule lost to the narrower one these dialogs brought with them. It is now stated at that scope. Measured at 412, 390 and 360px; the desktop layout is unchanged to the pixel.
Settings, documents had the same fault one screen over - the side panel's second column came out ten pixels wide on a phone. Fixed in the same place.
The frontend now reads its translations from WordPress. Its JavaScript asked for a text domain the plugin does not declare, and script translations were never registered, so every translation of the 486 frontend strings was decorative. The domain is aligned and the script registered, which means an approved translation on translate.wordpress.org now arrives without a release.
137 strings that the bundled dictionary did not cover appeared in English inside a translated interface. They are filled in, and the build now refuses to package a frontend where that is true again.

1.37.6

A status you choose now survives an update. A one-off repair that aligned every enquiry with its newest action sat in the schema installer, which runs on every activation and every schema change - so each update quietly rolled back any status a person had set since, with nothing written to the timeline to say it had happened. It now runs once: an installation that already has a schema version is marked as done rather than repaired again, and only a fresh install, which has no enquiries to touch, reaches the query at all.
The same repair left only Won and Lost alone, while the two live rules also protect Quote sent. A sent quote could therefore be rolled back to "Meeting" by an update. The three are now treated the same in all three places.
An invoice notification arrives on the due date, not three days early. The query asked for everything due within three days; it now asks for what is due. Quotes keep their three days' notice - a quote expires by itself and there is something to do before it does, while an invoice needs nothing until it is actually due.

1.37.5

The readme now documents every external service the plugin can reach, with what is sent, when, and links to each service's terms and privacy policy.
Corrected the readme and a code comment that said the code for off-site backup destinations ships with the Pro add-on. The Dropbox client class ships here; Pro builds on it. Without Pro it is never reached.
The Danish translation files are no longer bundled. Translations now come from translate.wordpress.org, which keeps them current without a release.

1.37.4

The report CSV export was written in Danish throughout, even when the app was set to English, so an English user got a Danish file from an English screen. Every row label is now translated; the Danish wording is unchanged.
Two dashboard tiles counted invoices with the Danish word "fakturaer" in the English interface. They now say "invoice" or "invoices".

1.37.3

Two labels were written in Danish directly in the template, so they stayed Danish whatever language the app was set to: the "Create credit note" button on an invoice, and the default quote introduction field in settings. Both are English now, with the Danish kept in the translation dictionary, so a Danish user sees no change.

1.37.2

The Easy Setup screen drew its mark as the letter N in a coloured box rather than using the plugin's own icon. It now shows the icon itself.

1.37.1

The app icon was the family's blue, which belongs to Nimble Security. Lead to Cash is indigo. The icon in the browser tab, on the sign-in screen, in the sidebar and on the installed app now matches the plugin's own colour, and so does the mark on the Easy Setup screen, which had the old blue written into the stylesheet rather than taking it from the icon.

1.37.0

The enquiry, customer and job screens are now laid out the same way. Activity sits in a column on the right in all three, so nothing moves when an enquiry becomes a customer, and the save bar stays at the foot of the window however long the record is.
The same screens are considerably shorter. Fields are tighter, a postcode, city and country share one line, and a billing address that matches the work address is a single line instead of a repeated form. A customer record that needed 2,944 pixels of scrolling now needs 1,645.
Every section is a card with its own heading, so the seams between contact details, actions, documents, invoices and activity are visible at a glance.
Documents on an enquiry were nested inside the actions panel and looked like part of it. It is its own section now.

1.36.3

Renamed TermsAttachment::prepare() to attachment(). Plugin Check treats every call named prepare() as $wpdb->prepare() and reads its first parameter, which a method without parameters does not have; the check crashed on the file rather than reporting anything about it. Behaviour is unchanged.

1.36.2

Five repository files were missing the note that explains their access-scope clauses, so the report still listed them. No code changed.

Nimble Lead to Cash

标签

下载

详情介绍:

安装:

屏幕截图:

升级注意事项:

常见问题:

更新日志: