makgab képe

A commerce_billy folytonos számlasorszámot csinál. Ahogy elnéztem átírja rendelés számát a számlasorszámra. (A rendelésszámok nem számlaszámok.)

Értem mire gondolsz, de a felhasználó nem tudja módosítani a számlaszámokat (elvileg). Persze az adatbázisba mindig bele lehet nyúlni (aki ért hozzá). A nem webes számlázóprogramokba is bele lehet nyúlni - aki tudja hova kell nyúlni az adatbázisban.
De jogos amiket írsz.

Az apeh-nál egyszer anno valahogy így magyarázták el ezt:
Tehát ha a kézikönyv szerinti használat esetén nincs lehetőség "adathamisításra", akkor az a szoftver rendben van. Az más kérdés, ha ezt megkerülve a felhasználó átír adatokat - ilyenkor a felhasználó a felelős érte, mert nem "szabályosan" használta a szoftvert.
Pl. sok régi DOS-os számlázó szoftvert láttam, amit hivatalosan lehet használni. De mégis aki ért hozzá, az adatbázisban (pl. a dbf állományokban) simán át tudja írni az adatokat utólag.

0
0
szantog képe

Ez sucks.
Sajnos most nincs előttem commerce install, de ebben az esetben jó eséllyel fel kell menned egy olyan entitásig, amihez van nyelv rendelve. Gondolom a payment transactionnek tutira nincs, de az ordernek már esetleg lehet. Line item/node-oknál nem tudom, van-e értelme keresgélni, mert mi van, hogyha a cart-on különböző nyelvű line_item-ek vannak.

Ha nincs az ordernek nyelve, akkor csinálj neki! :)

Adj egy mezőt az orderhez, pl field_language. Keress egy olyan rules eventet (most ezeket sem vágom hirtelen, hogy mi lehet (pl egy status váltás az orderen: after updating existing order; conditionben meg megadod, hogy az unchanged order status = valami and order status = ujvalami) Na akkor beállítod a field_language-t a [site:current-page:language]

Így a Data to compare az order field_language mezője lehet.

2
0

----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.

taltos képe

Hasonló a kérdésem, de egy kicsit más.

Hogyan lehet (gondolom 1000 féle képpen, de hogyan szokták...) megoldalni az olyan 2 szintű menüt, mint ami a weblabor.hu -n is van? Azaz hogy a második sor attol függ, hogy az elsőn hova kattintottam.

Mivel az én esetemben nem kell általánosra megcsinálni, vagy ilyesmi, ezért arra gondoltam, hogy talán smarty-val if-ekkel. Azért gondoltam erre, mert az oldalam több aldomain-ből állna, amik az site egy-egy komolyabb funkcióját valósítaná meg. Mivel ennek nem kellene látszódnia (az url -en kívül) a felhasználóknak, ezért arra gondoltam, hogy beilleszteném ezt a header-t minden index tetejére. Így esetleg meg tudom oldani, hogy a drupal headerjének egy linkjéből eléressem pl. a mediawiki felett futó wiki-met, aminek ugyanaz a header lenne a tetején, és az alatta lévő skint is egy kicsit hozzá igazítanám.

Ezzel az egyetlen egy gond, hogy nem értek a smarty-hoz, és azt sem tudom, hogy ezeket hogyan kell összefűzni egybe.

Summázva: a weblabor ezt hogy csinálja? Ti ezt hogy csináltnátok?

Köszönöm!

0
0
tamoca képe

"vagy fogsz egy máshol szokványosan használt külső képet megjelenítő számlálót, és berakod a page.tpl.php oldalba, mint ahogy különben az index.html-be szoktad tenni más oldalaidon."
Igen Igen
Valóban szeretnék egy olyan látogató számlálót ami azt számolja amikor valaki ezt a webcímet bejrja a böngészőjébe és entert üt aztán ha bejött az oldal akkor eggyel nőjjön a számláló és akárhova lépeget az oldalon belűl akkro se nőjjön tovább.Csak új belépéskor.Van mégegy gond a node/1 számolásával az egy megoldás amit irt egy kedves segjtő de nem az 1-es az örök címoldal hanem naponta változik ezért alkalmatlan . 2 megoldás érkezett eddig amit írtál az lehet a jó de mivel nem áll rendelkezésre amit be kellene szúrnom nem tudom megoldani. A kérésem a következő ha tudsz küldj légyszi egy működő beszúrandó kódsort és azt is hogy hova. Ne homályosan hanemkonkrétan szerintem nem vagyok egyedűl aki ilyet szeretne, ha nem ellentétes az üzleti filozófiáddal légyszíves tedd közzé. Köszönöm
tamoca

0
0

tamoca

pp képe

Ez a változat már funkcionalitását tekintve nem fog változni, de számos hibajavítást még fog tartalmazni, ezért változik a forráskód.

Én személy szerint nem javasolnám, bár van 2-3 oldal amit már én is az 5-össel üzemletetek, de ezek éles indulása január vége, február közepe.
Gondot jelenthet még, hogy spec modulok (amik 4.7 alatt tök jól működtek) nem érhetőek el, vagy nem túl stabilan működnek ezzel téve az egész rendszert instabillá.

Amit át kell gondolnod
- szükségesek-e az 5-ös plusz szolgáltatásai.
- milyen plusz modulokra van szükség az oldal működéséhez.
- a kezdeti bizonytalan időszak, vagy a későbbi átállás lesz a munkásabb. (ugyanis a 4.7-et az 5-ös kijövetele után csak egy bizonyos ideig fogják javítani, mint ahogyan 4.6-hoz sem jelnik meg túl sok hibajavítás ;))
Ez utóbbinál segít az, hogy a szerződésben az előállítás, vagy a később nyújtandó support költségéi közé számolod ezt be. (esetleg már az ajánlat adásánál gondoltál egy jelentős verzió cserére)

pp

0
0
eMeLA képe

Szerintem elbeszélünk egymás mellett.

Ha létrehozok egy menüt és feltöltöm menüpontokkal, és megcsinálom a CSS-t hozzá. Akkor az vasalva van (a tpl.php-s változtatást kivéve, ez nekem új). Vagyis a létrehozott menű ID csak akkor változik, ha törlőm és létrehozok egy másikat, de ugyebár akkor már nem az eredeti menüröl van szó, hanem egy másikról. Szerintem aki eljut egy végeredményhez az nem fogja újrakazdeni, tehát vasalva van az ID.

Ó persze, egy adatbázisban minden bármikor változtatható, de ha létrehozol egy új menüt, vagy installálsz egy modult, akkor attól az adott menü ID-je nem fog megváltozni. Márpedig a hozzászólásból nekem úgy tünt, hogy a hozzászóló azért van gondban, mert elképzelhető, hogy a menük ID-je egy kissebb ID számú menü törlésekor átszámozódik. Ez persze lehetséges, nem próbáltam, ha így van akkor pehh ;)

Tegyük hozzá, nem vagyok programozó és az agyam is másként működik, és az "elképzeléseim" is mások... Az biztos, hogy nem vagyok szakszerű... :))

0
0

...mit tudok: http://web.termuves.hu

d.pryke képe

Megnéztem egy másik drupal 5 telepítésen is, és ott sem úgy működik, ahogy írtad, Edit, tehát nem így:

"Igen, csak fordítva működik, tehát megadod az 'administer content' jogosultságot mindenre, és aztán azoknál a tartalomtípusoknál, amelyeket nem akarsz engedni szerkeszteni, azoknál nem adod meg az 'edit tartalomtípus' jogosultságot."

Ha meg van adva az administer content akkor hiába nincs megadva külön a tartalomtípusokra egyenként az edit jog, tudják szerkeszteni.
Tehát az eredeti kérdésem adott, ami pedig így hangzik (lásd témaindító bejegyzés):

"a tartalmak adminisztrációja jog nélkül kellene állítania egy bizonyos felhasználói csoportnak bizonyos tartalomtípusok közzétételi állapotát, van-e erre lehetőség drupal 5 alatt?"

Vagy máshogy megfogalmazva

"az átlag user által beküldött tartalmak ne jelenjenek meg az oldalon addig, amíg valaki jóvá nem hagyta őket egy bizonyos admin jellegű felhasználói csoport tagjai közül, de ezek a bizonyos admin jellegű felhasználók se legyenek korlátlan tartalommódosítási joggal megáldva a siteon"

van esetleg valakinek egyéb ötlete?
köszönöm mindenkinek az eddigi segítséget is.

0
0
Webappz képe

Amiről Te és Goba beszél az az, hogy ne kelljen egy tartalmat kétszer postolni és az adott oldalhoz igazodni, meg az hogy minden meglegyen egy helyen.
Akkor miért nem a nyitó oldalon jelennek meg ezek az aggregált hírek? Mert azért valljuk meg ott lenne a helyük.
Nevergone arról beszél és amire például én is használom a trackert, hogy megnézze milyen aktuális probléma (fórum téma) van, illetve milyen a magát a közösséget érintő téma van. Lehet, hogy amiről nevergone és én beszélek megoldható lenne a HUP-hoz hasonló fórum témák legutóbbi válasz alapján rendezve megjelenítéssel - ha már lúd legyen kövér, akkor szerepeljen még, hogy ki volt az utolsó hozzászóló. Talán ez azért is van, mert mindketten ott is megfordulunk :-)
Szóval mindenki mást keres, de ezzel csak azt tudom mondani, hogy az eddig megszokott eszközt másképpen kell használni, vagy érdemes lenne +1 feature: a tartalom típus rendezhető legyen és fordított rendezésnél már ki is esnek az aggregált hírek :-)

Páldi Zoltán

LaM képe

Vagyis igy:

ha van 3 aldomainem aldomain1, aldomain2 es aldomain3 neven a kovetkezoket kell csinalnom:

Belepek a fooldal FTP hozzaferesehet, es megnyitom a Sites mappat.

Letrehozok egy uj mappat aldomain1 neven
Az aldomain1 mappaba bemasolom az eredeti aldomain1 settings.php file-jat az adatbazis hozzaferesekkel. (mast nem masolok az ujonnan letrehozott aldomain1 mappaba)

Az eredeti aldomain1 mappajaban talalhato Files mappa tartalmat atmasolom a fooldal Files mappajaba.

Ezt megcsinalom mindharom esetben.

A kerdes a kovetkezo:

a Design nemileg elter az osszes aldomainen. Hogyan oldom meg?
Milyen modom tudom atiranyitani a regi aldomaineket? Az atiranyitas utan torolni lehet a regi mappakat?

Van oldal amin hasznalom a Notify modult, viszont a fooldalon nem. Ilyenkor mi az eljaras? Eleg ha bemasolom a Notify modult a fooldal Modules mappajaba?

Mert, ha ilyen egyszeru akkor inkabb most fogom csinalni, amig amugy is szet van bombazva a weboldal.

Ennek a megoldasnak elvileg csokkentenie kellene a szerver terheltseget. Jol gondolom?

Koszonom a valaszokat

0
0

B. Zsolt

aboros képe

ráadásul ez is csak félmegoldás, hiszen az űrlapelemeid továbbra is ott vannak a forrásban és kötelezőek is (ezért fel is töltöd értékkel: "személyes átvétel") csak elrejted őket a humán elől.

sminkréteg szinten sima ifekkel nem fogsz tudni egy űrlapot módosítani, ez egyátalán nem így megy, van egy form API annak a szabályai szerint kell az ilyesmit csinálnod, általában a hook_form_alterben. ebben a hurokban ott lesz az egész űrlap. minden űrlapnak van egy idje. azt figyeled rögtön a hurok elején, hogy arról az űrlapról van e szó, amibe ezzel a hurokkal bele akarsz piszkálni és ha igen, akkor megteszed.

ez eddig még ok is, csakhogy ez nem kliens oldalon történik, új oldalletöltés nélkül ezzel a módszerrel nem fog az űrlapod módosulni. plusz még ott van az is, hogy a drupal biztonsági okokból csak egy pont olyan űrlapot fog elfogadni válaszként, mint amit kiküldött, emiatt az űrlapok kliensoldali mahinálásának sajátos módja van a drupalban, ha jól gondolom ez az AHAH.

annak pedig, hogy ez egy kész oldal e vagy sem ehhez semmi köze nincs. :)

0
0

-
clear: both;