rr create / fqdn create: vorbelegung im auswahlmenue fuer inttype

das auswahlmenue der jeweiligen typen (record_inttype bzw. fqdn_inttype) in den entsprechenden create-funktionen muss ohne vorbelegung angeboten werden (initialzustand des menues z.b. 'bitte waehlen'), um die user an dieser stelle zu einer auswahl zu zwingen. (verhalten analog dnsvs-admin-intf.)

eine vorbelegung ist nur dann sinnvoll, wenn es genau einen in frage kommenden inttype gibt und dieser sich aus den funktionsparametern ergibt (z.b. trage mir einen neuen cname-rr zu diesem host-fqdn ein).

ich hatte gerade eine rueckfrage mit fehlermeldung, deren ursache ein falscher record_inttype fuer einen neuen cname-rr-eintrag war. dieser haette durch die korrekte benutzerauswahl vermieden werden koennen.

• neue sql-sortierung zuerst nur in devel aktivieren
• aktivierung in prod zum webapi-versionswechsel (termin steht noch nicht fest)

Sehe ich total anders. Ich hatte auch schon ein paar Nutzer, die es nicht kapiert haben, waren aber nur zwei oder drei. Dann habe ich es erklärt. Wenn wir nichts vorbelegen, wirst du IMHO ein Vielfaches an Anfragen kriegen. Es ist meines Erachtens der falsche Ansatz, alle zwingen zu wollen, sich damit zu beschäftigen. Wir sollten lieber überlegen, dass wir eine bestimmte Reihenfolge im Menü bzw. Vorauswahl sicherstellen, damit das Häufigste vorausgewählt ist. Wir haben einen Haufen Nutzer, die niemals was anderes als "A-Record für Host" brauchen werden.

Ich denke auch, dass wir lieber schauen sollten, dass wir da sinnvolle Defaults haben.

nochmal zum hergang: bei meiner anfrage, die von roland laifer kam, hat er entsprechend der menue-vorgabe 'CNAME-RR (Ziel: Domain)' eingegeben (dh. so stehengelassen). er haette aber 'CNAME-RR (Ziel: Host)' waehlen muessen. er rief 5 min. spaeter nochmal bei mir an und sagte, dass er den fehler selber gefunden hat. wir sind aber bei diesem gespraech beide zu der meinung gekommen, dass ein 'bitte waehlen' im menue besser gewesen waere. (den gleichen fall hatten wir glaub ich schonmal bei frau doktorin w.?).

aus diesem grund und unter der annahme, dass die sortierung der inttypes bereits stimmt, habe ich diese(n,s,?) issue aufgemacht. meine sichtweise ist nicht die eines "zwanges, sich damit zu beschaeftigen", sondern ich denke, dass die leute eher ein verstaendnis entwickeln werden, wenn sie in solchen faellen sehen, was ueberhaupt im menue angeboten wird. (zumindest fuer die namensbasierten, wo die voreinstellung nicht passt)

da aber die sortierung bei den namensbasierten typen noch nicht stimmt, sieht die sache etwas anders aus. wir brauchen also ein weiteres sortierargument im sql-view (s.u.).

was den bedienaufwand betrifft, spricht natuerlich 'bitte waehlen' klar dagegen, weil es einen klick mehr erfordert. ebenso die deutlich ueberwiegende zahl bei adressbasierten eintraegen mit standardwert. ich hoffe, dass es mit der richtigstellung der sortierung besser funktioniert.

zur sortierung (fuer janis): momentan gibt es zwar im sql-view 'v_dns_rr_def' das attribut 'nt_name_sortby', das bezieht sich aber auf den linken namen. wir brauchen auch noch die sortierung fuer den rechten. die dafuer erforderliche neue view-definition wird ab der webapi-versionsumstellung auf 2.1 aktiv. das bisherige attribut 'nt_name_sortby' heisst dann 'l_nt_name_sortby', und neu hinzu kommt 'r_nt_name_sortby'. die generelle order-by-klausel muss dann lauten (bezogen auf 'v_dns_rr_def'):

order by dns_rr_type_name, l_nt_name_sortby, r_nt_name_sortby, r_at, l_unq desc, r_unq desc

in devel ist es schon vorher aktiviert.

changed milestone to %WebAPI-Versionswechsel 2.0 -> 2.1

changed the description

noch eine weitere where-condition muss dazu (fuer 'v_dns_rr_def'):

not dns_rr_type_force_auto_dml

geht weiter:

dns.list_rr() gibt dns.gen_dns_rr_list_rec_type zurueck. dieser aendert sich auch: statt rrt_name gibt es rrt_rec. wir brauchen zusaetzlich zum rrt-namen auch das attribut 'force_auto_dml'. wenn true, sollen fuer rr's dieses typs keine aenderungsfunktionen angeboten werden (eintragen, aendern, loeschen).

z.b.:

select rr.fqdn, (rr.rrt_rec).name, (rr.rrt_rec).force_auto_dml, ... from dns.list_rr(...) as rr;

mentioned in commit 2176389b

marked the checklist item aktivierung in prod zum webapi-versionswechsel (termin steht noch nicht fest) as completed

marked the checklist item aktivierung in prod zum webapi-versionswechsel (termin steht noch nicht fest) as incomplete

marked the checklist item neue sql-sortierung zuerst nur in devel aktivieren as completed

Bitte einmal auf devel durchtesten.

sql scheint ok. zu sein, seitenaufrufe werfen keine fehler. nur die aenderungssperre greift noch nicht komplett, z.b. bereich 'srv-fs1-s2/1', unter NS oder SOA: 'create' ist zwar ausgeblendet, aber update und delete werden noch angeboten. die muessten noch weg.

Argh, de morgan... Jetzt sollte das passen

noch nicht auf https://netvs-devel.scc.kit.edu/dnsvs/ranges/srv-fs1-s2/1#secNS. wieder nur lokal bei dir?

Ups, ein git submodule update vergessen. Jetzt sollte es richtig sein.

marked the checklist item aktivierung in prod zum webapi-versionswechsel (termin steht noch nicht fest) as completed

closed