eRAD PACS Kiszolgáló
eRAD PACS Kiszolgáló
A feldolgozott adattárat nem tartalmazó vizsgálat újrafeldolgozásakor a jit feldolgozási rutin tévesen örökölt miniatűr képeket hozott létre.
A Korrigált állapot (p0000) és a Meglévő lelet állapot (p0002) gyárilag alapértelmezett számított mezői nem jelentek meg a konfigurációs oldalon, nem voltak módosíthatók és nem voltak elérhetők munkalista oszlopként. Az adatmezők típusai megváltoztak, de az új típusokat az adatbázis nem kezelte.
Míg néhány értesítési e-mail konfigurációban megfelelő az üres e-mail cím, erre szükség van, ha a lista tulajdonosa a rendszerfiók. Ezekben az esetekben a felhasználók nem tudják aktiválni a műveletet, amíg nem adnak meg egy e-mail címet.
Ügyféloldali kivétel lépett fel, amikor a felhasználó a bejelentkezés után azonnal kijelentkezett, mielőtt a munkalistát megjelenítette volna.
Ha munkalista frissítés történik (kézi vagy automatikus) a betegmappában egy lelet szerkesztése közben, olyan munkalistában amelyből egy vizsgálat eltűnik, a munkalista sorainak újrarendezése a leletszerkesztő oldalt is frissítette, törölve az esetleg beírt leletadatokat.
A felhasználói fiók zárolási állapota és a bejelentkezési adatok hibás információkat jelentettek, amikor a felhasználó a sor elején lévő kiválasztási jelölőnégyzet bejelölésével választotta ki a fiókot. Az információk akkor sem voltak következetesek, ha több fiókot jelöltek ki.
Egy kezelőpult betöltésekor a bejelentkezés után kivétel léphetett fel egy inicializált változó ellenőrzésének sikertelensége miatt.
Amikor egy felhasználó által kezdeményezett, feladattal kapcsolatos művelet, például egy ütemezett feladat prioritásának megváltoztatása hibát okozott, a visszatérési kód értelmezése helytelen volt, így a zárolás érvényben maradt. Ennek eredményeképpen az új feladatok nem futottak.
A vizsgálatok automatikus kéréshez igazításakor, amikor a beteg neve a megfeleltetési kritérium, ha a beteg neve aposztrófot tartalmazott, keresési kivételt és az automatikus helyesbítés sikertelenségét eredményezte.
A részlegesen hozzáférhetetlen jelző a munkalistán téves státuszt jelenthetett, ha a felhasználó a Bővebben gombra kattintott további vizsgálatok megjelenítéséhez, miközben a rendszer még mindig gyűjtötte azokat. A státusz beállítására irányuló hívás sikertelen volt, mert az oldal nem kezelte a kérést.
Az indító szkript a helyi eredményváltozó helyett a globális eredményváltozót adta vissza, miután egy kiszolgálófarm minden egyes kiszolgálóján elindította az egyes szolgáltatásokat, ami akkor is sikeres állapotkódot eredményezett, ha egy vagy több kiszolgáló nem tudott elindulni.
A globális korlátozások véletlenül blokkolták a nem vizsgálat vonatkozású adatokat a Naplók oldalról.
A v7.2-ről a v9-re történő frissítéskor az olyan munkalista szűrő listák, amelyek neve túl hosszú ahhoz, hogy beleférjen az adatbázisba, kimaradnak, és a konzol ablakban figyelmeztetés jelenik meg. Egy probléma ilyen kezelése azt okozta, hogy a következő listát figyelmen kívül hagyta a rendszer, így a frissítés azt is kihagyta, minden figyelmeztetés nélkül.
Az értesítési e-mailben lévő hiperhivatkozásból, amely elindítja a képeket a webes nézegetőben, hiányzott a bejelentkezési kérés. Ha egy böngészőben nem volt már érvényes munkamenet-süti, a webes nézegető nem tudta betölteni a képeket.
VISSZAFORDÍTHATÓSÁGI ÉRTESÍTÉS: Ez a változás szükségessé teszi az összes feldolgozott és gyorsítótárazott adat újbóli létrehozását egy olyan formátumban, amely nem kompatibilis a korábbi szoftververziókkal.
RENDSZERKÖVETELMÉNYEK: Ehhez a módosításhoz 9.0.4.4 vagy újabb nézegető szükséges.
Nagyon speciális és valószínűtlen körülmények között a tömörítési algoritmus olyan mátrix-határfeltételekkel találkozhatott, amelyek miatt a tömörítési próbálkozás sikertelen volt, és így nem volt feldolgozott kép.
A képek átméretezésére szolgáló algoritmus, azért hogy illeszkedjen a rendelkezésre álló webnézegető keretbe, idő előtt befejeződhetett olyan képek esetében, amelyek mérete nem a kettő hatványa. Ennek eredményeképpen a kép átméretezése rosszul sikerült és elmosódott lett.
A technikus nézet oldal nem tiltotta le a több kapcsolódási ponton megtalálható részleges vizsgálatok továbbítását, szerkesztését és törlését.
A feldolgozott adattároló eltávolítása nem változtatta meg a feldolgozás státuszát befagyasztottra, mivel az állapotváltozást nem alkalmazták a visszahívás során.
A felhasználónév szűrő legördülő menüje a felhasználónevet és a felhasználó azonosítót felcserélhető módon használta mind a megjelenítésben, mind az adatbázis-lekérdezésben, ami zavaros eredményekhez vezetett. A mező lehetővé teszi a felhasználók számára a felhasználónevek megadását, és mind a felhasználónév, mind a felhasználó azonosító megjelenik, de a parancs meghívásakor az alkalmazott érték a felhasználó azonosító.
Amikor néhány nem látható karaktert, például bal és jobb nyilat írtak be a felhasználónév mező legördülő paneljébe, mondjuk a felhasználónévre szűréskor, a weboldal szükségtelen keresést kezdeményezett az adatbázisban.
A felhasználónév legördülő menükben néhány alapértelmezett elemnek meg kellene maradnia, még akkor is, ha a típus-előjelző karakterláncot alkalmaznak, de ezek is kiszűrődtek.
Amikor a web szolgáltatások eszközszerkesztő lapján az alapértelmezett felhasználó konfigurálásakor egy szövegbeviteli mezőből kikattintottak, a stílustábla törlődött, majd a visszakattintáskor a szövegmezőbe, a felhasználó egyéni színbeállítása nem került alkalmazásra.
A manuális továbbítás beállítása oldalon a felhasználónév mezőt (mappába történő továbbításkor) blokkolhatta a felugró menü.
A munkalista betegmappában lévő lelet nézetben a lelet kiválasztó eszközök nem működtek megfelelően: a színséma hardveresen sötét témára volt programozva; a lelet komponens ikonok nem jelölték ki a megfelelő lelet komponenst; és a lelet komponens ikonja helyett a törlés gomb volt kiemelve. E problémák megoldása mellett egy új gombot, az Összes lelet megnyitása gombot adtunk hozzá, amellyel az összes lelet komponens egyetlen nézetbe tölthető.
VISSZAFORDÍTHATÓSÁGI ÉRTESÍTÉS: A lefele váltáshoz a bővítmény licenc(ek)et újra kell generálni.
A mammográfia, a 3D térbeli és a fúziós bővítmények rövid neve megváltozott a v7-ben használtakhoz képest, így a frissítés után a bővítmény licencét nem ismerte fel a rendszer.
A kiszámított mezők konfigurálásakor elérhető címkék listája nem volt rendezett, ami megnehezítette egy adott címke megtalálását.
A rövid időformátum kezelőjének módosítása nem kezelte a negált keresési feltételekre vonatkozó kéréseket.
Az 1:1-től eltérő képarányú képek miatt a technikus nézet oldal képlapozója részleges képeket mutatott, és a görgető eszközök nem működtek. Emellett az oldal miniatűr képméret beállításait is használhatatlanná tették.
Egy vizsgálat megnyitására tett kísérlet, miközben még több regisztrációs szerveren keresztül zajlott a rögzítése, olyan versenyfeltételt eredményezett, hogy a nagy bináris objektumban (blobban) lévő herpa adatok több képre hivatkoztak, mint amennyit feldolgoztak.
A PbR objektumban lévő információk összegyűjtésének kísérlete az alkalmazás kiszolgálóról sikertelen volt, mivel a herelod csak a regisztrációs kiszolgálón fut. Ez hatással van néhány webszolgáltatás-parancsra és más funkcióra, például a vizsgálat szerkesztésére a munkalistából. Egy új intracom szolgáltatás került bevezetésre a PbR objektum tartalmának regisztrációs kiszolgálóról történő lekérdezésére.
A felhasználó kezelő egy javításával a technikus nézet oldal vagy a webnézegető oldal betöltésekor szükségtelen bejelentkezés kérő hívás került beillesztésre.
A vizsgálatokhoz vagy megrendelésekhez csatolt mellékletek feltöltése hiba nélkül befejeződött, de a mellékletet nem mentette el a rendszer. Ennek oka egy hibás környezeti változó volt, az MCS komponens vezérlőszkriptjével kiterjesztve.
Amikor a vizsgálati adatok gyűjtése sikertelen volt, az eredmény nem tartalmazott olyan hibát, ami kivételt eredményezett.
Bár a hivatkozott adattárak használata nem javasolt - a csatlakoztatási pontokat kell linkelni, nem az adattárakat - a konfiguráció megengedett. Ha jelen volt, a rendszer nem mindig próbálta feloldani a linket, ami hibákat eredményezett a vizsgálat státuszának ellenőrzésénél.
A GUI által kezdeményezett kéréseket egy vizsgálat újrafeldolgozására vagy újraaktiválására, mindig egyetlen regisztrációs kiszolgáló hajtotta végre. Most a rendszer ezeket a feladatokat körkörös elrendezésben osztja ki a terhelés elosztása érdekében.
A helyi gyorsítótár adattárolót és annak alapértelmezett konfigurációs fájljait a cases ctrl (esetszabályozás) szkript hozza létre az indítás során, de a cases ctrl szkriptet nem a regisztrációs vagy a stream kiszolgálók hívják be. Ez a funkció átkerült a dcviewer ctrl szkriptbe.
A Biztonsági beállítások oldal és más kiszolgáló konfigurációs oldalak közötti váltáskor a biztonsági oldal tartalma frissülhet és felülírhatja a másik oldal adatait, mivel egy aszinkron hívás túl sokáig tarthatott.
A cw3 támogatás hozzáadásakor a webnézegető és a technikus nézet oldalaihoz, néhány új javascript oldal nem került be a hibakeresési módban futtatásakor.
A felhasználói fiókok oldalán a bejelentkezett felhasználót jelző mutató azért nem szerepel, mert az adatbázisban megváltozott az időbélyegző mező típusa, de a pipa nem frissült ennek megfelelően.
A lelet kezelésekor, például a lelet véglegesítésének feloldásakor vagy a függelék eltávolításakor behívott visszavont funkció kivételt eredményezett. A visszavont funkciót a v9 által támogatott funkció váltotta fel.
Amikor egy DICOM AE a DICOM visszakeresés kéréssel kér egy vizsgálatot, a továbbítási feladatok nem alkalmazzák a lágy szerkesztési módosításokat, így az adatok a legfrissebb frissítések nélkül kerülnek elküldésre.
Amikor a helyi MCS szolgáltatást egy munkalista kiszolgálóról két vagy több különböző hub kiszolgálóról származó vizsgálatokat tartalmazó DICOM média létrehozására használták, a hub kiszolgálókon létrehozott ideiglenes könyvtárnevek nem mindig egyeztek meg a munkalista kiszolgáló könyvtárneveivel. Ha a nevek nem voltak egyediek, a konfliktus miatt hiányoztak a fájlok. Ezenkívül az MCS a DICOMDIR fájl létrehozását az első hub kiszolgálóról történő átvitel befejezése után elkezdte, és nem várta meg az összes hub kiszolgálóról történő átvitel befejezését.
Az adatbázisban a Boole mezők kezelésének módosítása nem terjedt ki a felhasználói fiók zárolási állapotának mezejére, ami a zárolt felhasználói fiók feloldására tett kísérletek sikertelenségét okozta.
Bár a felhasználók valószínűleg nem nyitnának meg kéréseket vagy nulla képet tartalmazó vizsgálatokat, az erre irányuló kérések előfordulhatnak, és azokat a rendszer kezeli is. A folyamkiszolgáló azonban nem tudta feldolgozni ezeket a vizsgálatokat, ami fennakadást eredményezett a nézegető megnyitására tett próbálkozáskornál.
Amikor a jövőbeli várólista legfelső eleme egy aktív dcregupdate (dc regisztráció frissítés) feladathoz tartozó prepstudy (vizsgálat előkészítés) feladat volt, a feladatot a rendszer elhalasztotta, de a rendszer nem távolította el a várólista tetejéről. Mivel a feladatkezelő csak a várólista legfelső elemét nézte, a feladat-feldolgozás holtpontra jutott.
Amikor a stream (adatfolyam) kapcsolat kivételbe ütközik, például egy váratlan SSL kivételbe, a megjelenítő megpróbálja újra létrehozni a kapcsolatot egy gyors kapcsolat token kibocsátásával, de a kiszolgáló érvénytelen választ küld vissza, így a nézegető akadozik, miközben a megfelelő válaszra várva határozatlan ideig várakozik.
A stream (adatfolyam) információs naplófájlt nem forgatták, és tovább nőtt. A fájl bekerült az örökös naplóforgatási ütemtervbe.
A stream (adatfolyam) csatornára történő egyidejű írások, amelyeket a metrikus streaming adatok adatfolyamba való felvétele okozott, adatsérülést eredményeztek a csatornán. Ennek enyhítésére a bejövő parancsokra adott szinkron válaszokat egy dedikált kimenő várólistára küldi a rendszer. Emellett egy mechanizmus is működik az adatcsomagok méretének korlátozására. Ezt a vezérlési beállítást, a nézegető rendeli hozzá, szükség szerint.
Ha egy hub szerverről biztonsági mentés készült, utána nem érkezett parancs a dotcomon keresztül, a képkorrekciós kérés törlésére, miután azt végrehajtották a képen. Ennek eredményeként a vizsgálatot nem lehetett megnyitni a RIS-ből, mivel a vizsgálat keresése több elemet eredményezett (a vizsgálatot és a visszamaradt kéréseket).
A névmezőkre, a vizsgálat méretére és a több értéket tartalmazó mezőkre vonatkozó munkalista-szűrők frissítésre kerültek, hogy támogassák a korábbi verziókban elérhető funkciókat, beleértve az egyes névkomponensekre való keresés lehetőségét.
Az adatbázis-mezőhöz rendelt felsorolásos értékek hossza nem volt ellenőrzött, ami váratlan értékeket és eredményeket okozott. A hossz a konfigurációs oldalon kerül meghatározásra, és az értékek hosszának érvényesítése a mentés előtt történik.
Az Internet Explorerből érkező váratlan kivételeket nem kezelték megfelelően, ami egy weboldali kivételt eredményezett.
A súgóoldalak új ablakban történő megnyitásához használt módszer alapértelmezés szerint blokkolta a felugró ablakokat. A beállítást úgy módosítottuk, hogy az új lap a felhasználó nyugtázása nélkül is megnyílhasson.
Egy olyan dotcomban, ahol a gyermekkiszolgáló a szülő, előfordulhat, hogy egy szerkesztett lelet a gyermekkiszolgálón kerül feldolgozásra, és átkerül a szülőhöz, mielőtt a szülő regisztrálta volna az eredeti leletet. Ha egy leletértesítési esemény a lelet regisztrálása előtt érkezett a szülőhöz, a rendszer nem váltotta ki az eseményértesítést az összes mező frissítése előtt.
A statikus felhasználói fiókok, például a rendszerfiók speciális kezelése miatt a felhasználói fiókok exportáló szkriptje nem tudott semmilyen információt exportálni. A szkript mostantól figyelmen kívül hagyja a statikus fiókokat.
A „Vizsgálat módosítva” mező nem ismerte fel a leletobjektumok mentését. Ennek eredményeként a vizsgálat ujjlenyomata nem frissült, és a módosítás státusza érintetlen maradt.
Amikor egy DICOM eszköz bejegyzést hoz létre vagy módosít egy duplikált AE címet használva, és a felhasználó úgy dönt, hogy figyelmen kívül hagyja a figyelmeztetést, és mégis elmenti, a szoftver nem alkalmazta a módosítást, mert a felülbírálat jelzőt figyelmen kívül hagyta.
Ha a vizsgálatfrissítés és a vizsgálatfelvétel eseménye ugyanazon időszakon belül történik, a vizsgálatfelvételről szóló értesítő üzenet az üzenetszám csökkentési folyamat miatt kioltásra kerülhet. Mostantól a vizsgálat felvételi események nem záródnak össze a vizsgálatfrissítési eseményekkel együtt.
A tartós adatbázis-kapcsolat helyreállítására használt mechanizmus nem volt implementálva, ami adatbázis-hozzáférési hibákat eredményezett.
Az 1 MB-nál nagyobb tömörített képeket tartalmazó vizsgálatok sérült (zajos) képeket jelenítettek meg, mivel a feldolgozás nem pufferelte megfelelően az oldalakat.
A feladatkezelő leállíthatta a kérésről szóló értesítések elküldését a webszolgáltatás eszközeinek, ha a webszolgáltató eszköz elérhetetlen, és újabb próbálkozásként küldött egy üzenetfeladatot, de aztán törölte vagy felfüggesztette azt. Amikor a webszolgáltató eszköz ismét elérhetővé válik, a jövőbeni üzenetek összeomlanának a törölt újrapróbálkozási feladat mögött.
Az egyéni munkalista elrendezések importálásának javítása után a v7.2-ről v8-ra történő frissítéskor a műveletgombok és a zárjelző kiesett, mivel a v7.2 nem tárolja azokat a munkalista konfigurációjában. A frissítések alapértelmezés szerint tartalmazzák az alapértelmezett v8-as munkalista akciógombokat.
Ha egy mentett munkalista feltételes színezést tartalmaz egy rejtett oszlopon, hiba lép fel, mert a színező eszköz nem találja meg az oszlopot, és a munkalista üres listaként jelenik meg.
Egy felhasználói fiók jelszóbeállításai a fiók LDAP beállításainak ideiglenes módosítása után is alkalmazhatók voltak, még akkor is, ha a fiókot úgy konfigurálták, hogy LDAP hitelesítési ügynököt használjon.
A Bővebben sáv megnyomása a munkalista bejegyzések következő oldalának megjelenítéséhez duplikált sorokat eredményezhet, ha a felhasználónak nincs definiált alapértelmezett munkalistája, és olyan csoportban van, ahol egy nem rendezett, nem szűrt munkalista van alapértelmezettként definiálva.
Egy későn érkező objektum feldolgozása a meglévő objektumok kezdeti minőségi blob (miniatűr) adatainak újrafeldolgozását eredményezte, mivel a herba készítő még nem ellenőrizte a meglévő adatokat.
A webnézegető nem indult el egy olyan Hyper+ farmrendszerben, amelyben a stream kiszolgáló nem ugyanaz, mint az alkalmazás/webkiszolgáló, mert a webnézegető csak a webszolgáltatás portjait kapta meg, a kiszolgáló teljes URL-címét nem.
A nagy objektumok blobokká alakítása téves zárolás miatt sérült adatokat eredményezhet.
A Hyper+-ban alkalmazott java komponensfrissítés, amely a régi unix csatlakozó elrendezést váltja fel, nem támogatja ugyanazokat a csatlakozó opciókat. Amikor bizonyos körülmények között történt kísérlet vizsgálatok továbbítására, egy nem támogatott opció kivételt okozott, és a kérés sikertelen volt.
Az SI VR típusú mezőit, például az Értelmezési státusz azonosító mezőt használó leletnézet-sablonok hibákat naplóztak és nyers adatokat jelenítettek meg, mivel a VR típus támogatása megszűnt.
Egy vizsgálat másolása a munkalista mappába azért nem sikerült, mert az adatkönyvtár nem jött létre, amit a storestate.rec fájl DICOM adattárból metaadat-tárba történő áthelyezése okozott.
FRISSÍTÉSI ÉRTESÍTÉS: Ez a módosítás érvényteleníti a gyorsítótárban lévő összes (feldolgozott) blobot (bináris nagy objektumot). A blob fejlécében adatérték-túlcsordulás állt fenn, amikor a blob mérete meghaladta a 2 GB-ot, ami miatt a blob létrehozása (feldolgozása) során néhány kép kimaradt.
A taskd kliens a kapcsolat megszüntetésekor törölte a kapcsolatfenntartó időzítőt, ami megakadályozta az újraindítást, így az újrafeldolgozási és újraindexelési kérések sikertelenek voltak.
Ha a Technikus nézet oldalról a weboldal betöltése után nagyon gyorsan kérik a gyorsítótár törlését, előfordulhat, hogy a karbantartási eljárás nem fejeződik be a gyorsítótár törlésének megkezdése előtt, ami hibát eredményez, és a gyorsítótár adatai az adattárban maradnak.
Amennyiben a PbR regisztrációja a képobjektumokat megelőzően történik, a Dátum mezőben a PbR létrehozásának időpontja jelenik meg a képobjektum vizsgálati dátuma helyett, mivel a Dátum mező számítása a minimális SOP példányból nem történt meg.
Egy alacsony szintű zárolás időzítő olyan feltételt hozott létre, amely korlátozta a rendszer próbálkozásainak számát egy referenciaszámláló feloldására, azonban egyes valós forgatókönyvek esetén több próbálkozásra van szükség. Ennek eredményeképpen a referenciaszámlálók feloldása nem történt meg, ami következetlen állapotot eredményezett az adatokban.
Néhány dokumentált MySQL kivétel lépett fel, de az ajánlott megoldást - a lekérdezés/frissítés újbóli megkísérlése - nem alkalmazták.
Több összecsukott prepStudy (Vizsgálat előkészítés) feladat is előfordulhatott egyszerre a feladatsorban egy, a feladatok létrehozásakor fennálló versenyfeltétel miatt.
Az újrapróbálási sorban lévő vizsgálat előkészítési feladatokat nem sikerült befejeznie az összecsukást követő tisztítási funkciónak.
A Chromium (a Chrome, Edge, Safari és más böngészők által használt) 106.0.5249.103 vagy újabb verzióra történő frissítése után a böngésző néhány megfogás/leejtés funkciója, például a munkalista szűrő alkalmazása egy oszlopfejlécből vagy oszlopértékből megsértette a weboldal tartalmát, ami megbomlott elrendezést eredményezett.
A DCMKT eszköztárban történt változás miatt a meglévőnél korábbi kapcsolat időkorlátot kellett hozzárendelni. Ennek eredményeképpen az első küldési kérés kivételével minden küldési kérés és az összes fogadási kérés a beépített időkorlát értéket használta.
Egyes műveletek másolhatók a böngésző hálózati paneljéről, és egy másik böngészőből más jogosultságú felhasználók által behívhatók, így a felhasználók nem engedélyezett műveleteket hajthatnak végre. A hiányzó jogosultságok ellenőrzése megtörtént.
Ha az Intézmény neve érték aposztrófot tartalmaz, és a mezőt a munkalistán alkalmazott szűrési feltételekkel használják, a következő/előző vizsgálat megnyitása parancs egy nem megfelelően formázott lekérdezés miatt kivételt eredményez.
Egyes műveletek másolhatók a böngésző hálózati paneljéről, és egy másik böngészőből más jogosultságú felhasználók által behívhatók, így a felhasználók nem engedélyezett műveleteket hajthatnak végre. A hiányzó jogosultságok ellenőrzése megtörtént.
A rendszer figyelmen kívül hagyta a globális korlátozásokat a következő/előző vizsgálat kiválasztásakor. Ha a felhasználónak nincs jogosultsága a kiválasztott vizsgálat megtekintésére, akkor érvénytelen vizsgálat hibaüzenetet kap.
Egyes műveletek másolhatók a böngésző hálózati paneljéről, és egy másik böngészőből más jogosultságú felhasználók által behívhatók, így a felhasználók nem engedélyezett műveleteket hajthatnak végre. A hiányzó jogosultságok ellenőrzése megtörtént.
A "ForwardStudy" (Vizsgálat továbbítás) kifejezés el volt írva a webszolgáltatások vizsgálat továbbítási eseménynapló bejegyzéseiben.
Az újonnan létrehozott dokumentumtípusok nem jelentek meg a addig dokumentumtípus-konfigurációs oldalon, amíg a böngésző oldal nem frissült.
A feltöltött nézegető naplókban a nézegető verziószám helytelen volt, mert az adatokat rossz objektumból vették át.
Amikor egy regisztrált nézegető eszköz gyorsítótár-állapot kérést küld a kiszolgálónak, és a kiszolgálón nincs kifejezetten meghatározott előzetes vizsgálat gyorsítótár-állapot beállítás, az elemző algoritmus félreértelmezi az elemzési eredményeket, és egy felesleges kivételt regisztrál a naplófájlban.
Egyes műveletek másolhatók a böngésző hálózati paneljéről, és egy másik böngészőből más jogosultságú felhasználók által behívhatók, így a felhasználók nem engedélyezett műveleteket hajthatnak végre. A hiányzó jogosultságok ellenőrzése megtörtént.
A dotcom kezdeti beállítása során nem sikerült a kiszolgáló önazonosító beállítását felvenni az alapértelmezett konfigurációs fájlba. Ennek eredményeként a támogatói fiókot nem ismerte fel a rendszer.
A komponensek indító szkriptjeinek átszervezése megszakította az alapértelmezett pb-scp konfigurációs fájl beállítását, aminek következtében a konfigurált beállítások végére rossz alapértelmezett értékeket csatoltak, amelyeket azután a rendszer a konfigurált értéknek vett.
A műveletek nem tudtak lefutni, mert a curl szkript azonosítására használt elérési útvonal az eltávolított egyéni komponenst használta. Az elérési útvonal frissítésre került, hogy az operációs rendszer által biztosított curl eszközöket használatához.
A tartós adatbázis-kapcsolatok nem kapcsolódtak újra, ha a kapcsolat elveszett vagy időzített, ami az objektumok regisztrálására tett újbóli próbálkozásokhoz vezetett, egyéb befejezetlen adatbázis-kérések mellett.
Amikor rövid idő alatt nagyszámú objektumot próbáltak felvenni és regisztrálni, a herelod folyamatok nem tudtak tisztán befejeződni, és feleslegesen vártak a feltételes változók feloldására, ami sikertelen regisztrációs feladatokat és elhagyott objektumokat eredményezett.
A java frissítése után egy nem kompatibilis JAX-WS fájl miatt minden webszolgáltatás-parancs sikertelen volt. A JAX-WS frissült a 2.3.5 verzióra.
A java helye megváltozott, de több szkriptben, köztük a felhasználói fiókok importálására és exportálására szolgáló eszközökben használt útvonalváltozó továbbra is a korábbi helyre mutatott.
Az állandó és nem állandó adatbázis kapcsolatok a befejezéskor felszabadították az SQL könyvtár objektumát, érvénytelenítve az állandó kapcsolatot, instabil viselkedést okozva más szálakban.
A MySQL frissített verziója az átviteli beállítások használatával hibaként kezeli a csonkítást, szemben az érték automatikus csonkításával. A beállításokat frissítettük, hogy visszaálljanak a korábbi csonkítási viselkedésre.
A gyorsítótár vagy feldolgozott adatkönyvtárak nélküli vizsgálat, például amelyikhez csak egy PbR objektum tartozik, a metaadatok előkészítésekor kivétel lép fel a visszatérési kódérték sikertelen vizsgálata miatt.
Ha a felhasználó kezelő egy független kiszolgálón fut, a bejelentkezési kísérletek sikertelenek, mert a szoftver nem volt megfelelően előkészítve a különálló objektumok közötti helyes adattovábbításra.
A gyorsítótár törlése törölte az adatokat a Technikus nézet oldalról, de nem frissítette a feldolgozási státusz belső értékét, mivel a feldolgozási státuszt több kiszolgálón keresztül követő funkció még nem volt bevezetve.
Egy vizsgálat újraindexelése nem sikerül, ha a beviteli és az alkalmazás komponensek külön szervereken futnak, mert az alkalmazás kiszolgálónak nincsenek regisztrációs képességei. A regisztrációs kérelmet az egyik regisztrációs kiszolgálóhoz kell benyújtani.
A nézegető adatletöltésre használt stream szervere a herpa adatokban van definiálva van, de a korai v9-es nézegető még nem használja az értéket. Amíg ez nem áll rendelkezésre, a szerver üresen hagyja a beállítást, ha megállapítja, hogy a stream szolgáltatás és a webszolgáltatás ugyanazon a szerveren fut, így a nézegető kénytelen feltételezni, hogy a kettő ugyanaz. Vegye figyelembe, hogy ez a megoldás csak akkor működik, ha a streaming és a webszolgáltatás ugyanazon a kiszolgálón fut. Ha a szolgáltatások külön vannak, frissített megjelenítőre van szükség.
A statikus felhasználói jelszavak nem vették figyelembe a frissített hash formátumot.
A jelszó hash formátumának frissítése néhány helyen kimaradt, többek között a Jelszó módosítása oldalon.
A visszatérési kód helytelen kezelése az művelet előzmények fájljának törléséhez vezetett, amikor egy adatbázis-lekérdezés rendellenességet észlelt, vagy egyszerűen nem sikerült befejezni.
A betegmappák jegyzeteiben szereplő dátum-idő értékek elemzése 12 órás óraformátumot feltételezett, nem pedig 24 órásat.
Egy vizsgálat javítása egy kérésnek megfelelően nem sikerült, mivel a kéréseknek nincs tulajdonos hubja, ami szükséges az egyesített vizsgálat tárolási helyének meghatározásához. Ennek eredményeképpen a grafikus felhasználói felületről végzett manuális javítások hibát jeleztek a felhasználónak.
Egy hiányzó RMI-hívás miatt egy vizsgálatra vonatkozó későn érkező kérést a javító kiszolgáló nem frissítette a vizsgálat adatait a kérés adataival, ha a javító kiszolgáló nem a vizsgálat tulajdonosa volt.
Ha a leállítási folyamat kivételbe ütközött, ami az időzítéstől/szekvenciától függően jogos lehetett, akkor a hermes befejezése előtt kiléphetett.
A vizsgálatok betegmappából történő továbbításának back-end támogatása nem volt teljes, így a gombra kattintáskor nem történt semmilyen művelet.
Egy lassú lekérdezési naplóbejegyzésben a lekérdezési idő másodpercben volt megadva, de ezredmásodpercben volt megjelölve.
A felhasználói fiókokat, amelyek jelszómezeje üres, ami érvénytelen státusz, nem lehetett javítani, mert a hiányzó jelszót nem volt kezelték, és hibát okozott a szerkesztéskor.
A kinyitva maradt duplikált feladatok nem kerültek vissza a duplikált feladattérképre, ezért végrehajtásukig az újrapróbálási sorban maradtak. Bizonyos körülmények között az újrapróbálkozás várólista megnőhetett a felesleges duplikált feladatokkal.
A bővítmény licencfájlok keresése során a rendszer nem ismerte fel a nem DLL fájlkiterjesztésű bővítményeket.
Az Értesítési művelet konfigurálásakor alapértelmezettként felajánlott e-mail cím azonosítása nem sikerült a belsőleg definiált fiókok, például a rendszerfiók esetében. Ebben az esetben az alapértelmezett cím üresen jelenik meg, így a felhasználónak kifejezetten meg kell adnia az e-mail címzettjét.
Ha a Feladatok oldal szűrőablaka nyitva volt, amikor a felhasználó egy másik weboldalt hívott be, a szűrőablak nem záródott be, hanem a képernyőn maradt.
Az Apache újraindítása után a nézegető munkamenetek nem voltak felismerhetők, ami azt okozta, hogy a gyorsítótárba került adatmezők (pl. Betöltési százalék) nem jeleztek adatokat, amíg a felhasználó ki nem lépett, majd vissza.
A gyorsszűrő mezőben dátumértéket használó munkalista keresése, amely lekérdezési minősítő kivételt eredményezne, hibaüzenetet adott vissza, nem pedig adatot, mivel a dátumszűrő nem volt megfelelően kódolva az adatbázis-kereső kérésben.
Az adattömörítés művelet statikus elérési utat használt a vizsgálathoz a tároló helykeresője helyett. Ha a vizsgálatot áthelyezték az eredeti helyéről, a tömörítési művelet nem találta meg, ezért nem tudta feldolgozni az adatokat.
Egy hiányzó konstruktor miatt nem sikerült feloldani egy rendszerzárat. A konstruktor hozzá lett adva a beragadó zárolás elkerülése érdekében. Továbbá, amikor egy felhasználó megpróbálta feltörni a rendszerzárat, ami nem megengedett, a felhasználó nem kapott magyarázatot arra, hogy miért maradt fenn a zár. Most a felhasználó tájékoztatást kap arról, hogy nincs jogosultsága a rendszerzár feltörésére.
Ha egyéni portot használtak a webnézegető elindításához, a kiszolgáló rosszul kezelte az URL elemzését az állomásnév megkereséséhez, ami a kérés sikertelenségét okozta.
A bővítmény licenc frissítései nem ismerték fel az egyéni bővítménymodulokat, mivel az új elnevezési szabályokat helytelenül alkalmazták az egyéni bővítményfájlok nevére.
Ha a webszolgáltatási parancsokat használják fel felhasználó létrehozására, és az tartalmazta a jelszó opciós címkét, de nem adott meg semmilyen opciót, a kérés sikertelen volt, mert a kiszolgáló nem tudta elemezni a kérés üres karakterláncát.
A törlés gomb nem volt elérhető a betegmappából, ha a vizsgálat egynél több leletobjektumot tartalmazott (például a fő leletnek volt egy kiegészítése).