netvs-core issueshttps://git.scc.kit.edu/scc-net/netvs/netvs-core/-/issues2023-12-11T12:06:49+01:00https://git.scc.kit.edu/scc-net/netvs/netvs-core/-/issues/624MacFinder: Netcompund-Awarenes2023-12-11T12:06:49+01:00xe4704janis.streib@kit.eduMacFinder: Netcompund-AwarenesDerzeit nicht vorhanden und sucht dann einfach auf allen Switches in allen Compounds.Derzeit nicht vorhanden und sucht dann einfach auf allen Switches in allen Compounds.https://git.scc.kit.edu/scc-net/netvs/netvs-core/-/issues/619Ansicht um Mgr zu bearbeiten (Abstraktion Account-Karte)2023-12-11T18:54:02+01:00ov5916julian.keck9@kit.eduAnsicht um Mgr zu bearbeiten (Abstraktion Account-Karte)NetVS kann aktuell nicht alle Features des Perl-Interfaces bzgl. Mgr-Objekten insbes. Rollen abbilden.
Es fehlt:
- [ ] Ansicht von beliebigem Mgr
- [ ] mgr2group: Gruppen (inkl. hinzufügen/löschen)
- [ ] mgr2ou: OE (inkl. hinzufügen/...NetVS kann aktuell nicht alle Features des Perl-Interfaces bzgl. Mgr-Objekten insbes. Rollen abbilden.
Es fehlt:
- [ ] Ansicht von beliebigem Mgr
- [ ] mgr2group: Gruppen (inkl. hinzufügen/löschen)
- [ ] mgr2ou: OE (inkl. hinzufügen/löschen)
- [ ] mgr2role: Globale Rollen (vergeben/löschen)
- [ ] Tokens auflisten (löschen wäre cool; das gibt die API aber leider gerade nicht her)
- [ ] (Permissions Rollen zuordnen)https://git.scc.kit.edu/scc-net/netvs/netvs-core/-/issues/606OE-Typen Postion löschen und bearbeiten Knopf inkonsistent zum Rest2023-12-08T17:42:19+01:00ov5916julian.keck9@kit.eduOE-Typen Postion löschen und bearbeiten Knopf inkonsistent zum RestAuf der Seite OE-Typen ist der löschen-Knopf links und bearbeiten rechts. Das ist soweit ich das sehe genau anders, wie überall anders.Auf der Seite OE-Typen ist der löschen-Knopf links und bearbeiten rechts. Das ist soweit ich das sehe genau anders, wie überall anders.https://git.scc.kit.edu/scc-net/netvs/netvs-core/-/issues/600Service-Account erstellen: leerer Gruppenname wird als "" übergeben (wirft Fo...2023-12-28T13:19:15+01:00gq3345rainer.steinmueller@kit.eduService-Account erstellen: leerer Gruppenname wird als "" übergeben (wirft Format-Fehler, weil lt. Datentyp-Constraint nicht erlaubt)Will man ein Servicekonto anlegen, dem keine Gruppe zugeordnet sein soll, wird `""` als Gruppenname an die API-Fkt. übergeben, was zu einem (relativ unverständlichen) Format-Fehler führt, da der Datentyp f.d. Gruppennamen keine Leerstrin...Will man ein Servicekonto anlegen, dem keine Gruppe zugeordnet sein soll, wird `""` als Gruppenname an die API-Fkt. übergeben, was zu einem (relativ unverständlichen) Format-Fehler führt, da der Datentyp f.d. Gruppennamen keine Leerstrings erlaubt.
Das gleiche passiert analog, wenn keine OU angegeben wird.
Vorschlag zur Umgehung:
- alle OUs des Users einschließlich deren Unter-OUs als Auswahl-Menü anbieten. Damit ist für die OU der Leerstring ausgeschlossen.
- alle Gruppen des Users zzgl. sowas wie '--- keine Gruppe zuordnen ---' als Auswahl-Menü anbieten.
- die zugehörige API-Fkt. `cntl.mgr2group.create` darf nur in die TA gesetzt werden, wenn eine Gruppe ausgewählt wurde.
- alternativ: `cntl.mgr2group.create` per when-Anweisung steuern; in diesem Fall muss aber (wg. des Datentyp-Checks) sichergestellt sein, dass der Gruppenname bei '--- keine Gruppe zuordnen ---' `null` ist. Dh. der Datentyp-Check wird vor Evaluierung der when-Anweisung durchlaufen, da das when-result und der NN-Check erst zur TA-Laufzeit gewertet werden.
Beispiel-Statement mit `<GROUP>` als übergebener Gruppenname (`"string"` oder `null`):
```
{
"idx": "449fe198-f983-465c-81eb-b58538744a82_add_svc_to_group",
"name": "cntl.mgr2group.create",
"new": {
"group_name": <GROUP>
},
"new_ref_params": [
{
"idx": "449fe198-f983-465c-81eb-b58538744a82",
"params": {
"mgr_login_name": "login_name"
}
}
],
"when": {"compare": ["ne", <GROUP>, null]}
}
```https://git.scc.kit.edu/scc-net/netvs/netvs-core/-/issues/599Dark Mode2023-11-21T12:07:11+01:00rx2495alexander.kaschta9@kit.eduDark ModeIn der NETVS-Community wurde sich ein Dark-Mode für das NETVS gewünscht.In der NETVS-Community wurde sich ein Dark-Mode für das NETVS gewünscht.https://git.scc.kit.edu/scc-net/netvs/netvs-core/-/issues/598"Umpatchen"-Knopf im Macfinder anbieten2023-12-14T21:20:01+01:00ov5916julian.keck9@kit.edu"Umpatchen"-Knopf im Macfinder anbietenAn jedem Ergebnis im Macfinder sollte es einen Knopf geben, der den User zu einem vorausgefüllten Patch-Request-Formular bringt, bei dem man nur noch Patch/Unpatch bzw. BCD auswählen muss.An jedem Ergebnis im Macfinder sollte es einen Knopf geben, der den User zu einem vorausgefüllten Patch-Request-Formular bringt, bei dem man nur noch Patch/Unpatch bzw. BCD auswählen muss.https://git.scc.kit.edu/scc-net/netvs/netvs-core/-/issues/597Show Roles of SVC-Accounts2023-12-08T17:42:45+01:00xe4704janis.streib@kit.eduShow Roles of SVC-Accountshttps://git.scc.kit.edu/scc-net/netvs/netvs-core/-/issues/588Generic Requests-Tracking in NETDB?2024-01-31T17:28:08+01:00xe4704janis.streib@kit.eduGeneric Requests-Tracking in NETDB?Man könnte sich Gedanken über ein generisches Requests-Tracking in der NETDB machen.
Im NETVS-Devel-Chat gab es dazu schon einige Überlegungen.
Die grundidee wäre, dass man als Nutzender seine Requests auch im Nachhinen einsehen kann un...Man könnte sich Gedanken über ein generisches Requests-Tracking in der NETDB machen.
Im NETVS-Devel-Chat gab es dazu schon einige Überlegungen.
Die grundidee wäre, dass man als Nutzender seine Requests auch im Nachhinen einsehen kann und den Zustand von denen einsehen kann.
Modellierung ggf. relativ abstrakt mit generischen Objektattributen für den "Inhalt" der Anfragen.
Es soll kein zweites Ticket-System werden, sondern ausschließlich Requests/Anträge abbilden,
die einen direkten Bezug zur NetDB haben. Konkreter: ein Antrag kann sich nur auf Objekttypen beziehen,
die in der WebAPI abgebildet/modelliert sind. Aktuelle Kandidaten wären:
- Patch Request (KIT-weit)
- BCDs (Neueinträge)
- Subnetze (Änderungen)
- DHCP, BCD-basiert (Neu, Ändern)
- vpn2vlan (noch prüfen)
- wifi2vlan (noch prüfen)
- KNN-Domainantrag (SLD: neu, alt, Providerwechsel. Aber keine Mailadressen - nicht in NetDB)
Basisansatz f.d Modellierung:
- `request_type`, `request`, `request_item` als Objekttypen.
- Schema evlt. `cntl`.
- Relation zu den inhaltlichen Objekttypen via global join.
Aus momentaner Sicht könnte es folgende Vorteile geben:
- Antragstellung und Bearbeitung erfolgen direkt im NETVS; zusätzliche Status-Infos per Mail analog gitlab-issues sollten machbar sein.
- Antragsdaten direkt in NetDB integrierbar
- der Bearbeitungsverlauf eines Antrags ist (ohne entwicklungsseitigen Mehraufwand) im evlog sichtbar
- Antragsteller können den Status/Verlauf ihres Antrags jederzeit einsehen, ggf. auch nachträglich Antragsdaten korrigieren (falls es Fehler gab) oder anpassen.
- Antragsteller sehen alle ihre eingereichten Anträge (aktuelle und frühere, sofern sie aufgehoben werden)
Zeitfenster: aus heutiger Sicht nicht vor 2025https://git.scc.kit.edu/scc-net/netvs/netvs-core/-/issues/586RR-create-Funktion (generische Fkt. mit gruenem '+') nimmt keinen user-bestim...2023-11-09T16:30:35+01:00gq3345rainer.steinmueller@kit.eduRR-create-Funktion (generische Fkt. mit gruenem '+') nimmt keinen user-bestimmbaren FQDN-TypBei der generischen RR-create-Fkt. muss davon ausgegangen werden, dass der FQDN noch nicht existiert. Es reicht deshalb nicht, nur den FQDN-Typ-Default aus der RR-Typ-Definition zu nehmen. Wenn es keine weitere Vorauswahl gibt, muessen h...Bei der generischen RR-create-Fkt. muss davon ausgegangen werden, dass der FQDN noch nicht existiert. Es reicht deshalb nicht, nur den FQDN-Typ-Default aus der RR-Typ-Definition zu nehmen. Wenn es keine weitere Vorauswahl gibt, muessen hier alle FQDN-Typen angeboten werden; auch die, die evtl. fuer den vorgesehenen RR-Typ nicht in Frage kommen (weil nicht als DBRT definiert). Die korrekte Auswahl liegt dann im Ermessen des Users.
Waere der RR-Typ aber bereits bekannt, duerften nur die FQDN-Typen angeboten werden, fuer die es eine DBRT-Definition des RR-Typs gibt.https://git.scc.kit.edu/scc-net/netvs/netvs-core/-/issues/585Patch Requests Change Insert info/check2023-12-14T21:57:16+01:00gj4210robert.kossessa9@kit.eduPatch Requests Change Insert info/check"Wenn man einen Change Inserts beantragt, wäre es sinnvoll, dem Kunden
vorzugeben, was es für Inserts gibt und generell prüft, ob da ein
Cable-Sharing-System verbaut ist und somit überhaupt machbar." -Manfred"Wenn man einen Change Inserts beantragt, wäre es sinnvoll, dem Kunden
vorzugeben, was es für Inserts gibt und generell prüft, ob da ein
Cable-Sharing-System verbaut ist und somit überhaupt machbar." -Manfredgj4210robert.kossessa9@kit.edugj4210robert.kossessa9@kit.eduhttps://git.scc.kit.edu/scc-net/netvs/netvs-core/-/issues/582Patch Request: Formular als eigenen View statt als Modal darstellen2024-01-31T17:28:08+01:00pe3533benjamin.aydt@kit.eduPatch Request: Formular als eigenen View statt als Modal darstellenDas Patch-Request Formular sollte als eigene Unterseite bzw. eigenen View (mit direkter URL -\> /requests/patch-request und Breadcrumb) statt als "Modal" dargestellt werden. \
Dies ist übersichtlicher und und es können auch Direktlinks a...Das Patch-Request Formular sollte als eigene Unterseite bzw. eigenen View (mit direkter URL -\> /requests/patch-request und Breadcrumb) statt als "Modal" dargestellt werden. \
Dies ist übersichtlicher und und es können auch Direktlinks an die Nutzer verteilt bzw. in unserer Doku/auf der Webseite verlinkt werden. \
(Die Patch-Request-Actions, sind als "Modal" gut dargestellt)https://git.scc.kit.edu/scc-net/netvs/netvs-core/-/issues/581Patch Request: Eintrag im Eventlog beim jeweiligen Modul.2023-11-06T17:28:37+01:00pe3533benjamin.aydt@kit.eduPatch Request: Eintrag im Eventlog beim jeweiligen Modul.Zur Archivierung und Nachvollziehbarkeit, sollte jeder Patch-Request zu einem Eintrag im Event-Log für das in der jeweiligen "Patch-Request-Action" ausgewählte Modul führen.Zur Archivierung und Nachvollziehbarkeit, sollte jeder Patch-Request zu einem Eintrag im Event-Log für das in der jeweiligen "Patch-Request-Action" ausgewählte Modul führen.https://git.scc.kit.edu/scc-net/netvs/netvs-core/-/issues/580Patch Request: Actions erweitern (BCD(s) <-> Port)2023-12-14T21:09:18+01:00pe3533benjamin.aydt@kit.eduPatch Request: Actions erweitern (BCD(s) <-> Port)Um auch Patch-Requests für Trunk-Ports mit dem Formular abwickeln zu können, werden noch folgende Actions zur Auswahl benötigt:
1) Add BCD
2) Change/Replace BCD
3) Remove BCD
Eventuell können aber auch vorhandene Actions (Patch, Unpatc...Um auch Patch-Requests für Trunk-Ports mit dem Formular abwickeln zu können, werden noch folgende Actions zur Auswahl benötigt:
1) Add BCD
2) Change/Replace BCD
3) Remove BCD
Eventuell können aber auch vorhandene Actions (Patch, Unpatch) teilweise umbenannt werden.gj4210robert.kossessa9@kit.edugj4210robert.kossessa9@kit.eduhttps://git.scc.kit.edu/scc-net/netvs/netvs-core/-/issues/579Patch Request: CSV-Import für Patch-Request-Actions2023-11-06T18:34:13+01:00pe3533benjamin.aydt@kit.eduPatch Request: CSV-Import für Patch-Request-ActionsDie Möglichkeit auf einen CSV-Import der "Request-Actions" wurde nun schon mehrfach gewünscht. \
Dies ist vor allem dann sinnvoll, wenn viele Dosen auf einmal umgeschaltet werden sollen, welche auch nicht zwingend im selben Gebäude sind.Die Möglichkeit auf einen CSV-Import der "Request-Actions" wurde nun schon mehrfach gewünscht. \
Dies ist vor allem dann sinnvoll, wenn viele Dosen auf einmal umgeschaltet werden sollen, welche auch nicht zwingend im selben Gebäude sind.https://git.scc.kit.edu/scc-net/netvs/netvs-core/-/issues/575Automatic bug reporter2023-11-06T18:15:22+01:00rx2495alexander.kaschta9@kit.eduAutomatic bug reporterImplement a method to be able to automatically post NETVS error (in the frontend) to the NETVS team. This should not automatically create GitLab issues but rather send mails to the dev team to prevent from sensitive information from leak...Implement a method to be able to automatically post NETVS error (in the frontend) to the NETVS team. This should not automatically create GitLab issues but rather send mails to the dev team to prevent from sensitive information from leaking. Open for further suggestionshttps://git.scc.kit.edu/scc-net/netvs/netvs-core/-/issues/572Animation issues in navigation sidebar2023-12-08T15:33:46+01:00rx2495alexander.kaschta9@kit.eduAnimation issues in navigation sidebarWenn das NETVS auf einem Mobilgerät (z.B. Handy) verwendet wird, so funktionieren die Animationen nur so halt. Es ist Glückssache, ob das Icon des neu ausgewählten Eintrags blau ist, ob die Animation dann vollständig durchläuft, da der T...Wenn das NETVS auf einem Mobilgerät (z.B. Handy) verwendet wird, so funktionieren die Animationen nur so halt. Es ist Glückssache, ob das Icon des neu ausgewählten Eintrags blau ist, ob die Animation dann vollständig durchläuft, da der Text dann mit erhöhtem Padding links steht und so weiter.https://git.scc.kit.edu/scc-net/netvs/netvs-core/-/issues/553Transactionlist verschwindet / Cannot read properties of undefined (reading '...2024-02-05T20:53:33+01:00rx2495alexander.kaschta9@kit.eduTransactionlist verschwindet / Cannot read properties of undefined (reading 'startsWith')```
TypeError: Cannot read properties of undefined (reading 'startsWith')
at a.visible_results (TransactionList.vue:429:1)
at t.get (vue.runtime.esm.js:3446:33)
at t.evaluate (vue.runtime.esm.js:3547:27)
at a.visible_resu...```
TypeError: Cannot read properties of undefined (reading 'startsWith')
at a.visible_results (TransactionList.vue:429:1)
at t.get (vue.runtime.esm.js:3446:33)
at t.evaluate (vue.runtime.esm.js:3547:27)
at a.visible_results (vue.runtime.esm.js:5537:25)
at a.Q (TransactionList.vue:1:11262)
at t._render (vue.runtime.esm.js:2684:28)
at a.r (vue.runtime.esm.js:3875:27)
at t.get (vue.runtime.esm.js:3446:33)
at new t (vue.runtime.esm.js:3436:51)
at Mr (vue.runtime.esm.js:3892:5) 'render'
```
Siehe Foto:![Bildschirmfoto_vom_2023-10-09_17-21-17](/uploads/afdc1ee4b3c68ee09a6d48ddb344b044/Bildschirmfoto_vom_2023-10-09_17-21-17.png)https://git.scc.kit.edu/scc-net/netvs/netvs-core/-/issues/537Feature Request - EUI-64 automatisch generieren2023-12-20T16:26:32+01:00kw3675Feature Request - EUI-64 automatisch generierenÄhnliches Anliegen wie #480, beim Klick auf "Kein AAAA-Record!" wäre es super, wenn automatisch die zum Subnetz der IPv4 passende EUI-64 IPv6 generiert und eingetragen würde. Benötigen wir so oft, dass wir da intern sogar schon ein Tool ...Ähnliches Anliegen wie #480, beim Klick auf "Kein AAAA-Record!" wäre es super, wenn automatisch die zum Subnetz der IPv4 passende EUI-64 IPv6 generiert und eingetragen würde. Benötigen wir so oft, dass wir da intern sogar schon ein Tool für geschrieben haben. (Kennt nur unsere Subnetze, bringt also anderen Instituten aktuell leider nichts.)ov5916julian.keck9@kit.eduov5916julian.keck9@kit.eduhttps://git.scc.kit.edu/scc-net/netvs/netvs-core/-/issues/499MACauth: temporäre Sperre2023-08-29T13:40:27+02:00iv4011benedikt.neuffer@kit.eduMACauth: temporäre SperreDerzeit gibt es keine Möglichkeit eine MAC-Adresse beim MACauth temporär zu sperren.
Anwendungsfälle:
* MAC soll nur zu bestimmten Momenten Zugang bekommen
* MAC ist nicht zuortbar, temporäre Sperre, bis sich jemand meldetDerzeit gibt es keine Möglichkeit eine MAC-Adresse beim MACauth temporär zu sperren.
Anwendungsfälle:
* MAC soll nur zu bestimmten Momenten Zugang bekommen
* MAC ist nicht zuortbar, temporäre Sperre, bis sich jemand meldethttps://git.scc.kit.edu/scc-net/netvs/netvs-core/-/issues/487DNS searchlist überarbeiten2023-07-18T12:24:36+02:00iv4011benedikt.neuffer@kit.eduDNS searchlist überarbeitenAktuell gibt es DNS searchlist als DHCPv4-Option und die hängen an Subnetzen. Diese Info braucht man aber auch für RA und möchte man eigentlich für alle subnets einer BCD identisch haben. Zudem könnte es sein, dass man die Information au...Aktuell gibt es DNS searchlist als DHCPv4-Option und die hängen an Subnetzen. Diese Info braucht man aber auch für RA und möchte man eigentlich für alle subnets einer BCD identisch haben. Zudem könnte es sein, dass man die Information auch irgendwann via DHCPv6 verteilen möchte.
Hier muss man diskutieren, wie man damit umgehen möchte.xe4704janis.streib@kit.eduiv4011benedikt.neuffer@kit.eduha2931dominik.rimpf@kit.eduxe4704janis.streib@kit.edu