partkeepr / partkeeprmobile

PartKeepr is an inventory management software, primarily designed for electronic components.

PartKeepr is written in PHP and using the Symfony2 framework.

Demo Sites

To test everything which has been written so far, there are two demo pages prepared.

The latest release from github is available at http://demo.partkeepr.org. The most up-to-date version of the GitHub master branch is published at https://demo-git.partkeepr.org. Both demo pages are built from the git sources and reset to a demo state once an hour.

Requirements

PartKeepr needs:

• PHP between 7.0 and 7.1 - migration to newer symfony is needed before we support current php 7.x
• A MySQL or PostgreSQL database

Installation

Please read our setup guide

Thanks

A very big "thank you" goes out to Georgyo of NYC resistor - although he claimed that he isn't creative, he invented the name "PartKeepr" which eventually became the project's name.

partkeeprmobile's Issues

Updates?

Hi,

Is this ever gonna be updated and functioning like the website itself?

Timeout functionality

23:30:39 < sECuRE> Felicitus: was für ein timeout genau?
23:31:19 < Felicitus> sECuRE: wenn ich nen request auf nen server mache (in meinem falle sind das nur http requests)
23:31:43 < sECuRE> naja, request != request und server != server
23:31:50 < Felicitus> ja
23:31:59 < sECuRE> ich würde mal konservativ mit 15 s anfangen
23:32:17 < sECuRE> und dann immer erhöhen, bis zu einem gewissen grad
23:32:24 < Felicitus> ich mache vom PartKeeprMobile aus JSONP-requests auf den server. das ist nix anderes wie ein HTTP GET
23:32:28 < Felicitus> du meinst verringern?
23:32:28 < sECuRE> also beim zweiten mal 30s, dann 45s, dann 60s und bei 90s deckeln
23:32:39 < Felicitus> hmm
23:32:40 < sECuRE> nein, tatsächlich erhöhen. evtl ist das netz einfach echt schlecht gerade
23:32:45 < sECuRE> lieber funktioniert es sehr langsam als garnicht
23:34:16 < Felicitus> ich hab da nur ein problem: mittels JSONP kann man nicht erfragen, ob ein request erfolgreich war oder nicht, da
der server ein entsprechend präpariertes JS zurückgibt mit nem callback (cross domain XMLHttpRequest geht ja
nicht). wenn jetzt der server nen fehler wirft und daher kein gültiges JSONP zurückgibt, würde er den timeout für
98+60+45+30+15s erhöhen, obwohl ein fehler aufgetreten ist (welches mit "timeout" vielleicht schlecht bekannt ist)
23:34:52 < sECuRE> kannst du nicht eine globale variable setzen, die angibt, ob $request erfolgreich war
23:34:57 < Felicitus> nein
23:34:57 < sECuRE> und im callback wird die dann gesetzt
23:35:27 < Felicitus> weißt du wie JSONP funktioniert?
23:36:15 < sECuRE> nur so rudimentär. ich fand das sehr hackish ;)
23:36:24 < sECuRE> ich les mal gerade nach, mom
23:36:33 < Felicitus> also um das abzukürzen: ich kann feststellen, ob ein request erfolgreich ist. ich kann aber nicht feststellen, ob
ein fehler aufgetreten ist, ob die verbindung nen abbruch hatte etc :(
23:36:45 < Felicitus> ja es ist sehr hackish, gibt aber leider im moment keine andere alternative :(
23:37:47 < RaumZeitS> Neuer Status: Kann nicht ermittelt werden
23:39:01 < sECuRE> ich seh das problem noch nicht. warum lässt du nicht den server markSuccessAndCall({…}) aufrufen und in
markSuccessAndCall setzt du zuerst den request auf erfolgreich und rufst danach deinen code auf? dann machste bei
request-anfang nen timer, der nach n sekunden checkt, ob das erfolgreich war. wenn nicht, gabs halt nen fehler, und
es wird x mal erneut probiert (mit höher werdendem n). ja, ich sehe, dass man da z.B. HTTP 404 nicht richtig mit
hand
23:39:58 < Felicitus> das problem ist, wenn ein PHP-fehler auftritt oder eine verstümmelte response ankommt, dann wartet der user ewig.
das will ich nicht. lieber gebe ich erstmal ne fehlermeldung aus
23:40:28 < Felicitus> konkret hab ich das problem schon beim prüfen, wenn der user nen server anlegt - wenn er ne falsche serverurl
angibt, würde er sich zu tode laden
23:41:04 < Felicitus> hmm ich könnte natürlich beim server überprüfen die erhöhung überspringen
23:42:10 < sECuRE> joa
23:42:11 < Felicitus> naja ich lass den timeout erstmal fix auf 10s, die touch app ist ja erstmal nur für die senchacon relevant, die
werden das schon nicht über schlechte verbindung testen (sonst bin ich in ner woche nicht fertig)
23:42:31 < Felicitus> und nach der senchacon gibt's sencha touch 2.0, evtl haben die ja da ne alternative zu JSONP-gefrickel
23:42:33 < sECuRE> du könntest auch folgendes tun als zwischenschritt:
23:42:49 < sECuRE> bei fehler nach 10s ein overlay einblenden (think of gmail) mit retry-button und fehlermeldung
23:42:56 < Felicitus> hehe ok das ist ne gute idee
23:42:57 < sECuRE> bei retry dann timeout erhöhen und nochmal neu anfangen
23:43:29 < sECuRE> und denk auch immer schön an progress indicator. nichts ist nerviger als nicht zu wissen was $programm tut ;)
23:43:31 < Felicitus> sECuRE: ist es ok für dich wenn ich den chatauszug als bug auf github stelle?