Sziasztok!
Valaki találkozott már azzal, hogy az "Autocomplete term widget (tagging)" user edit oldalon nem müxik?
Viszont "people/create" oldalon megy rendesen.
Egy taxonomy term reference fieldről van szó.
Köszi!
Taxonomy upgrade extras:
Melyik modulhoz, modulokhoz kapcsolódik a téma?:
Drupal verzió:
Fórum:
Javascript hiba
Szia!
Milyen modulokat használsz? Nem lehet, hogy valami Javascript hiba miatt nem működik az adott oldalon? A böngésződben hozd elő a Javascript konzolt, töltsd be az oldalt majd kezdj el írni az automatikus kiegészítéssel rendelkező mezőbe.
Ha Javascript hiba van, akkor így látni fogod.
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
Page manager
Page manager /user/%user/edit elérésen okozza ezt. Kérdés vajon miért, és hogyan orvosolható?
- ad astra per aspera -
Javascript
Oké, de fent írtam, hogy a Javascript konzolt kellene megnézni, esetleg PHP log kellene a szolgáltatódtól.
Annyi infóból, amit eddig megosztottál, nehéz lesz kitalálni a probléma okát.
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
Elnézést, lehet hogy félre
Elnézést, lehet hogy félre értettem, vagy nem voltam egész világos. A javascript és a az autocomplete működik rendesen az oldalon, az egész szájton.
A probléma kizárólag az adott elérésen jön elő, csak akkor, ha a PM engedélyezve van. Más nincs ami be tudna zavarni. Viszont ha PM-t kilövöm, a hiba is megszűnik.
A konzolon nem látok semmi releváns infót. Persze valszeg én vagyok vak.
- ad astra per aspera -
Ez esetben leírhatnád
Ez esetben leírhatnád bővebben, hogy mire használod a Page Managert, illetve javaslom, hogy nézd át, a Page Manager nem ír-e felül valamilyen olyan blokkot, ami az User Edit oldalon megjelenik.
--
403 Access denied
A PM "403 Access denied" megjelenítésére van beállítva, amennyiben ez szükséges. Az oldalon több role működik, akiknek van "Administer users" joguk, viszont nem szabad, hogy ezt minden role-on használhassák.
Adott panel kiválasztása role alapján, illetve "logged in user" !== "user being viewed" alapján történik.
Blokkokat nem érint a dolog, ha a szabályok alapján megjeleníthető a user edit form, akkor az alap form jön le.
- ad astra per aspera -
ez érdekel
exportáld már ki a variantot. Mintha láttam volna már ilyesmit.
----
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.
nem válasz rá, hogy miért nem működik a megoldásod
de erre a konkrét felhasználói esetre van a user protect modul.
https://www.drupal.org/project/userprotect
ez még annyival is jobb, hogy valóban a user accountot védi, nem az edit formra ad 403 at, hanem mondjuk egy bulk operationsből se tudsz kitörölni egy protected usert, ha a protection szabály nem engedi. így pl egy user akinek van administer users joga, nem tudja elvenni más userek xy roleját a people admin oldalon se meg sehogy se. ha csak annyival véded a usert, hogy bizonyos feltételek esetén 403 -at dobsz az edit formjára, attól még lehet tucat más hely ahol usereket adminisztrálsz, ott is mindenhol gondoskodnod kéne róla, hogy hiába van katikának administer users joga, az igazgatóság roleba lévők emailcímeit ne bánthassa meg a rolejukat se. ésígytovább.
userportect modullal ezt szépen be lehet állítani.
uid1 - mindent csinálhat
admin role - uid1 kivételével mindenkinek mindenét szerkesztheti
HR osztály - admin role és uid1 kivételével mindenkinek mindenét szerkesztheti
vagy ilyesmi. és usereket egyesével is lehet dierkt védeni, meg egy egész rolet is. nagyon hasznos tud lenni szerintem.
-
clear: both;
Jelenleg nem nyújt megoldást
User protect nagy királyság, régen használom. Viszont jelen esetben elég komplex hozzáférési szinteket kell megoldani, amit a user protect sajna nem tud már követni.
Igen, máshol is ki kell küszöbölni a hozzáférést. Gyakorlatilag a user adminiszrtáció egész részét újra kellett gondolni hozzá. Macera, de nem láttam jobb megoldást.
- ad astra per aspera -
Protect User 1
$handler = new stdClass();
$handler->disabled = FALSE; /* Edit this to true to make a default handler disabled initially */
$handler->api_version = 1;
$handler->name = 'user_edit__protect_user_1';
$handler->task = 'user_edit';
$handler->subtask = '';
$handler->handler = 'http_response';
$handler->weight = 0;
$handler->conf = array(
'title' => 'Protect User 1',
'contexts' => array(
0 => array(
'identifier' => 'Admin',
'keyword' => 'uid1',
'name' => 'user',
'type' => 'select',
'uid' => '1',
'id' => 1,
),
),
'relationships' => array(),
'code' => '403',
'destination' => '',
'name' => 'protect_user_1',
'access' => array(
'logic' => 'and',
'plugins' => array(
0 => array(
'name' => 'compare_users',
'settings' => array(
'equality' => '1',
),
'context' => array(
0 => 'argument_user_edit_1',
1 => 'context_user_1',
),
'not' => FALSE,
),
1 => array(
'name' => 'compare_users',
'settings' => array(
'equality' => '0',
),
'context' => array(
0 => 'logged-in-user',
1 => 'context_user_1',
),
'not' => FALSE,
),
),
),
);
- ad astra per aspera -
Protect System Administrator
$handler = new stdClass();
$handler->disabled = FALSE; /* Edit this to true to make a default handler disabled initially */
$handler->api_version = 1;
$handler->name = 'user_edit__protect_system_administrator';
$handler->task = 'user_edit';
$handler->subtask = '';
$handler->handler = 'http_response';
$handler->weight = 2;
$handler->conf = array(
'title' => 'Protect System Administrator',
'contexts' => array(),
'relationships' => array(),
'code' => '403',
'destination' => '',
'name' => 'protect_system_administrator',
'access' => array(
'logic' => 'and',
'plugins' => array(
0 => array(
'name' => 'role',
'settings' => array(
'rids' => array(
0 => 4,
),
),
'context' => 'argument_user_edit_1',
'not' => FALSE,
),
1 => array(
'name' => 'role',
'settings' => array(
'rids' => array(
0 => 4,
1 => 3,
),
),
'context' => 'logged-in-user',
'not' => TRUE,
),
),
),
);
- ad astra per aspera -
És így tovább...
A fentiekhez hasonló variánsok vannak még benne.
- ad astra per aspera -