Tartalomtípus létrehozás blokkolása másik tartalom alapján

Zsoltf képe

Sziasztok! Segítségre lenne szükségem a következőkben. Adott két tartalomtípus A és B. Azt szeretném megcsinálni, hogy a felhasználó ne küldhessen be addig B típust amíg legalább egy A típusú tartalma nincsen.

Nem vagyok biztos benne de azt hiszem a rules modul ami nekem kellene de lövésem sincsen, hogy hogyan tudnám megoldani a rules és az entity jelenleg még nem az én szintem.

Melyik modulhoz, modulokhoz kapcsolódik a téma?: 
Drupal verzió: 
csakiistvan képe

Ki tudnád fejteni az üzleti igény a funkcióra? Csak hogy kontextusba tudjuk helyezni hogy miről is van szó, mert lehet hogy nem csak egy megoldás van rá.

0
0

Drupal full-stack developer at Wunderman Thompson Budapest

Zsoltf képe

Hát üzleti igényre nem mert éppen egy non-profit, meghívásos amolyan mester ajánló lenne. Az A tartalomtípus egy bemutatkozás a B pedig, hogy milyen szolgáltatást nyújt.

0
0
Geva képe

B szolgaltatashoz keszitenek egy mezot, amelybe levalogatnam views-zal a user A bemutatkozas tartalmait. Kotelezoen megadando, tehat ha ures eredmenyt ad a views - nincs bemutatkozasa -, akkor nem tud szolgaltatast bekuldeni.
:-)

1
-1
csakiistvan képe

Igen, ez viszonylag konnyen megvalosithato es konstruktiv megolas

0
0

Drupal full-stack developer at Wunderman Thompson Budapest

aboros képe

kézenfekvőnek tűnik, de amellett, hogy lesz egy felesleges referencia meződ is, ez a megoldás szörnyű felhasználói élményt eredményez, soha, semmiképpen nem csinálnám ezt.

az ilyeneknél felhasználóként általában az én érdekem, hogy legyen bemutatkozásom, úgyhogy azt se nagyon tartom fontosnak, hogy addig ne lehessen szolgáltatásom, amíg nincs bemutatkozásom. akárhogyis, inkább egy rulet tudok elképzelni ami vagy átirányít vagy üzenetet jelenít meg. vagy olyat is el tudok képzelni, hogy van egy külön role, a "mezei" usernek nincs joga szolgáltatást létrehozni, viszont miután létrehoz bemutatkozást, egy rule átrakja a megfelelő role -ba.

vagy bármi, csak az ne legyen, hogy kitöltök egy űrlapot és a végén "jövök rá" hogy be se tudom küldeni.

1
-1

-
clear: both;

Geva képe

- szerintem nem árt, ha a szolgáltatás oldaláról elérni a szolgáltató bemutatkozását, mert a netező nem a bemutatkozás alapján, hanem a szolgáltatás alapján választ, majd ezt követően nézi meg ki is a szolgáltató.
Mért a végén kellene rájönnöd, hogy nem tudod beküldeni??????
A piros csillag szerinted mi célt szolgál a beviteli mezőnél, ha nem figyelmeztetést?

0
0
szantog képe

Több gond is van vele.
"szerintem nem árt, ha a szolgáltatás oldaláról elérni a szolgáltató bemutatkozását"
Ez megjelenítési logika, pusztán megjelenés nem indokol két plusz db táblát.

UX: Két lehetőség van, vagy egy darab adatot rendelhet hozzá, vagy invalid az egész form, egy olyan esemény kapcsán, aminek a user beavatkozása nélkül kellene, hogy történjék. Vagyis felhasználói iterakcióhoz kötsz egy egyértelműen meghatározható inputot.

Konzisztencia: Egészen addig, amíg bárki is szerkesztheti a node author mezőt, fennáll a veszélye, hogy a referenciád inkonzisztens lesz. Z user beküld B contentet, Z usernek van A contentje is. Y user átállíthatja X userre a B content authorját, X usernek meg nincs A contentje. Ezt minimum validálni kellene.
Arról nem is beszélve, hogy egyáltalán nem biztos, hogy egy views contextual filter lekezeli a node/add oldalon node author default value-t, szóval lehet, hogy csak logged in user-t tudsz használni. Ha ez így van, akkor viszont egyáltalán nem lehet szerkeszteni más által a node-ot, mivel a node author != logged in user, tehát a logged in user lehetséges A tartalma különbözik a node author A tartalmától.

1
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.

Geva képe

igen, lehet ragozni, tudom és belátom, nem olyan egyszerű a probléma, amit két sorban meg lehet oldani, egyetértek a leírtakkal, segítő szándékom ellenére szörnyűűűűűűűűűűűűűűűűűűűűűűűűű egy tipp volt, kukába vele!!!!!!!

0
0
nevergone képe

Ne reagáld túl, csak mindenki kíváncsi a jó megoldásra. Jó dolgokat írtatok itt össze, tanulságosak. :)

0
0
pp képe

"Egészen addig, amíg bárki is szerkesztheti a node author mezőt, fennáll a veszélye, hogy a referenciád inkonzisztens lesz."

De nem csak a referenciás megoldás lesz inkonzisztens, hanem a Te megoldásod sem véd ez ellen, ha módosítják utólag a beküldőt. Sőt az ellen se, ha valaki az A típusú tartalmát utólag letörli. (és még egyéb furmányos trükkök ellen se, pl. eleve más nevében hozza létre a tartalmat, ha van joga hozzá, meg ilyenek.)

De ezek nem az általatok vázolt megoldások hibái, hanem az eredeti felvetés sem foglalkozik ezekkel az esetekkel. És itt most nem azt írom, hogy ne kén foglalkozni ezekkel a problémákkal, hanem pusztán azt, hogy az eredeti felvetésnek a megoldásaitok ténylegesen megfelelnek, tehát jó és építő jellegű hozzászólás mindkettő megoldás.

pp

1
0
pp képe

Tehát, ha jól értem a javaslatod az, hogy a kapcsolódó field-et a legelejére kell rakni az űrlapnak, így nem csorbul a felhasználói élmény és Geva nagyszerű megoldása még jobb lesz?

Csak csendben jegyezném meg, hogy a kérdésben felvetett probléma, nem probléma, hanem egy megoldás megvalósításának kérése:

"Azt szeretném megcsinálni, hogy a felhasználó ne küldhessen be addig B típust amíg legalább egy A típusú tartalma nincsen."

Tehát neked nem Geva megoldásával van problémád, hanem az eredeti kérdésfelvetésben taglalt problémára kitalált megoldással.

Egyedül Geva adott eddig működő, korrekt megoldást, ráadásul rém egyszerűt és minden körülmények között működőt, vagyis ebből a két szempontból nagyszerűt, sőt, ha a megvalósításának egyszerűségét nézzük (csak pár kattintás), akkor zseniálisat. Ha a te javaslatodat is hozzávesszük, tehát a felhasználói élmény is elfogadható lesz, vagyis egy újabb szempontból is jó lesz a megoldás, akkor pedig űberzseniális.

pp

1
0
szantog képe

nem lehet klikk-klikk olyan nézetet készíteni, ami ezt a feladatot kiszolgálná. Vagy úgy gondolod, hogy egy honlap egész életében meg lehet kockáztatni azt, hogy egy node-ot az authorján kívül _soha_ és _senki_ más ne tudja szerkeszteni?

0
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.

szantog képe

hook_node_access-be egy EFQ, aminek ha nincs eredménye FALSE-t ad + lehet egy drupal_set_message, hogy figyi, előbb küldj be A tartalomtípust.

Ha csak másra nem kell, ezért role-t nem tartanék fenn, így is elég katyvasz tud lenni permission tábla.

2
-1

----
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.

szantog képe

Íme a hook_node_access mutatvány:

---

  1. /**
  2.  * Implements hook_node_access().
  3.  */
  4. function MYMODULE_node_access($node, $op, $account) {
  5. if ($op == 'create' && $node->type == 'NODE_TYPE_B') {
  6. $query = new EntityFieldQuery();
  7. $query->entityCondition('entity_type', 'node')
  8. ->entityCondition('bundle', '[NODE_TYPE_A]')
  9. ->propertyCondition('status', 1)
  10. ->propertyCondition('uid', $account->uid);
  11.  
  12. $result = $query->execute();
  13.  
  14. if (empty($result['node'])) {
  15. drupal_set_message(t('Hello, @post a node before', array('@post', l('post', 'node/add/[NODE_TYPE_A]'))));
  16. return NODE_ACCESS_DENY;
  17. }
  18. }
  19. return NODE_ACCESS_IGNORE;
  20. }
1
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.

pp képe

wow, király!

0
0
pp képe

Rules modullal nem sikerült megoldanom egy óra alatt. :) Valaki?

Addig sikerült eljutni, hogy a node létrehozását és szerkesztését totál külön kell kezelni. A létrehozásnál pedig (mivel erre esemény alapból nincs) szükség lesz a Rules Form modulra.

A számoláshoz pedig talán a Views Rules modul adhat megoldást, de nem sikerült rájönnöm hogyan. Próbáltam a Rules List Conditions modult is, de azzal se sikerült megoldanom a problémát.

A Rules Bonus Pack első fícsöre pont az ami kell, de azt ki se próbáltam, mivel éles környezetben nem javasolnám a használatát a contributor által leírtak alapján.

Találtam ugyan egy megoldást amit használni lehetne, de az annyiban különbözött szantog megoldásától, hogy pluszban klikkelgetni kellett volna még vagy százat. :)

Szóval valaki, Rules mágus? (ha már az eredeti kérdés úgy szólt, hogy Rules segítségével oldjuk meg)

pp

0
0
szt képe

Kipróbáltam egy másik kattintós megoldást, és működik.
Ha nem okoz gondot plusz szerepkör(ök) (=role) létrehozása, akkor jó lesz.
1. Készítesz egy arole és egy brole szerepkört.
2. arole-nak engedélyezd A tarttípus létrehozását és saját A tarttípus szerkesztését (törlését ne engedd).
3. brole-nak engedélyezd az arole-nak adott jogokat, plusz B tarttípus létrehozását, saját B tarttípus szerkesztését és saját B tarttípus törlését.
4. Utána csinálsz Rules segítségével egy szabályt, ami A tartípus létrehozásakor fut le. Megvizsgálod, hogy a tartalom létrehozója benne van-e arole-ban, és persze ne legyen benne brole-ban. Az akció meg az legyen hogy tartalom létrehozóját hozzáadod brole-hoz.
Itt a beállítási kép.
Ennyi.
Arra gondolok, hogy az új role jól fog jönni később is, nem felesleges.

2
0
Geva képe

továbbfűzve ezt a rém egyszerű megoldást:
ha azt szeretnénk, hogy csak egy bemutatkozást(A tartalomtípust) küldhessen be, akkor a brole csoportnál egyszerűen már nincs joga bemutatkozást beküldeni, csupán a saját A tartalmát szerkeszteni.
...talán a UX sem sérül, főleg ha udvariasan üzenünk is a usernek, a korlátokról/lehetőségeiről :-)

1
0