[gelöst] FHEMWEB verschiedene Seiten und Ports

[homa]

Hallo Rudolf,

ja jetzt hab ich Dich verstanden. Also das mit dem hidenroom detail klappt. Auch das ich kein Detail in der URL direkt eingebe und somit doch ein Objekt bearbeiten kann - prima!
ABER einen anderen versteckten Raum kann ich immer noch via URL aufrufen - schade.

Ich habe aber gerade FHEMWEB erweitert, damit man Räume aus hiddenroom nicht per modifizierten URL angezeigt bekommt.

Habe ich Dich hier missverstanden?
Sonst wäre es ja genau wie von mir gewünscht. Wobei es sich ja mit dem Wunsch von Virsacer beißt. Daher meine Idee mit dem expliziten forbiddenRoom.

[rudolfkoenig]

ABER einen anderen versteckten Raum kann ich immer noch via URL aufrufen - schade.

Ist das mit dem aktuellen Code auch der Fall ? Aenderungen werden per update erst am naechsten Tag ab 8 verteilt.
Wenn ja, bitte was zum Nachstellen beschreiben.

[homa]

Hallo Rudolf.

Habe heute das Update nach 8:00 Uhr gemacht und es klappt!
Zuerst habe ich den Room all ausprobiert und war schon enttäuscht. Aber ich musste das Schlüsselwort all neben Everything im attr hinzufügen und schon klappte es!
Die anderen Räume gehen jetzt auch nicht via modifizieren der URL.

attr homaticWEB hiddenroom Unsorted,Everything,all,Schlafzimmer,Fritzbox,Logfile,Commandref,Remote doc,Edit files,Event monitor,Save config,Select style,detail

Sieht doch toll aus, so schön einfach ohne Befehlszeile und Details ...
Genauso habe ich mir das vorgestellt.
Danke für Deine Hilfe!

Grüße
Matthias

[Prof. Dr. Peter Henning]

Rudi,

leider hat diese Änderung negative Auswirkungen:

https://forum.fhem.de/index.php/topic,75206.msg851367.html#msg851367
https://forum.fhem.de/index.php/topic,26893.msg851050.html#msg851050

Alle ca. 400 Nutzer der Module

Alarm
YAAHM
Babble

stehen plötzlich vor leeren Räumen.

LG

pah

[rudolfkoenig]

Was ich nicht verstehe: wieso setzen sie alle ein Raum ins hiddenroom, und beschweren sich, wenn sie das nicht mehr sehen?

[Prof. Dr. Peter Henning]

Das machen die Module, nicht die Nutzer. Und nirgendwo steht geschrieben, dass dies "unerwünscht" ist.

Und zwar läuft das so, dass der Raum (z.B. ProfileRoom) zwar "hidden" ist und somit unter den normalen Räumen nicht mehr auftaucht. Aber per Link im oberen Menü eben doch erreichbar ist.

Dadurch, dass Du die Erreichbarkeit von hiddenrooms per modifizierter URL (auf Wunsch eines einzelnen Benutzers...) gesperrt hast, geht der Link auf den vorgeblichen hiddenroom eben nicht mehr.

Allerdings ist Deine Änderung auch nicht ganz konsistent. Denn der Link auf fhem/?room=hidden geht nach wie vor, also warum nicht auf fhem/?room=ProfileRoom

Vorschlag ?

LG

pah

[rudolfkoenig]

Denn der Link auf fhem/?room=hidden geht nach wie vor, also warum nicht auf fhem/?room=ProfileRoom

Mit hidden kann man temporaere Geraete (wie TCP Verbindungen) in allen FHEMWEB Instanzen vom Benutzer verstecken. Ich habe noch kein konkretes Argument gehoert, warum eine Anzeige dieser Daten per URL zu einem Problem fuehrt. Da ich hidden auch nicht dokumentiert habe, sollte der Benutzer es auch nicht als Alternative zu hiddenroom verwenden.

Mit dem dokumentierten hiddenroom verhindert der Benutzer, dass ein bestimmter Raum in einer FHEMWEB Instanz angezeigt wird. Der Wunsch ist mAn verstaendlich, dass wenn man es explizit untersagt, ihn auch nicht per URL aurfrufen kann.

Vorschlag ?

Geraet im Raum "hidden" zu packen, dann muss man auch nicht "global DEFINED" beobachten, um zu wissen, ob eine neue FHEMWEB Instanz angelegt wurde.

[Prof. Dr. Peter Henning]

Bitte bedenke, dass die ca. 300 Installationen von Alarm sicherheitsrelevant sind. Dass Du alle Betroffenen derzeit von der Oberfläche ihrer Alarmanlage abgekoppelt hast, kann ich deshalb nicht akzeptieren.

Alarm als ältestes dieser drei Module ist seit Jahren so implementiert. Es geht eben _nicht_ darum, Geräte zu verstecken. Sondern darum, einen Raum zu schaffen, in dem die Darstellung ganz anders ist, als in den normalen Räumen - und der darum nicht im zweiten Menü organisiert ist, sondern nur per URL erreichbar ist. Bei FLOORPLAN wird das schließlich auch gemacht, und nach genau diesem Muster agieren die drei genannten Module.

Der Wunsch ist mAn verstaendlich, dass wenn man es explizit untersagt, ihn auch nicht per URL aurfrufen kann.

Dem widerspreche ich: Etwas zu "verstecken" ist etwas Anderes, als etwas zu "untersagen".

Ich bitte Dich deshalb im Namen von 400 FHEM-Benutzern

a.) Deine Änderung vorläufig rückgängig zu machen, damit die Betroffenen wieder in ihre speziellen Räume können
b.) Dir etwas Anderes auszudenken. Im Sinne des oben Gesagten wäre es sinnvoll, ein globales Attribut "forbiddenroom" einzuführen - das kannst Du dann wirklich "hart" ausführen.

Falls Du dem nicht nachkommen willst: Eine so weitgehende Änderung, wie die von Dir durchgeführte bedarf eines Vorlaufs, mindestens drei Wochen halte ich für angemessen.

LG

pah

[rudolfkoenig]

Ich finde die Argumente teilweise merkwuerdig und teilweise falsch, aber ich akzeptiere, dass Du jetzt keine Zeit hast, die Module zu fixen, und habe deswegen den Bugfix temporaer entfernt.

[gamauf]

ich bin so frei und zitiere PAHs Post aus anderen Threads auch hier:

Edit: Rudi König hat die Änderung wieder rückgängig gemacht, möchte sie aber doch wieder einführen. Bitte deshalb hier an der

Abstimmung beteiliigen:

https://forum.fhem.de/index.php/topic,92615.0.html



LG

pah

[homa]

Wow, da ist man 2 Tage wieder arbeiten ...

Hallo Rudolf, hallo Peter.

Ich wollte hier keinen Zwist auslösen. Ich finde einen Kompromiss, wie von Dir Peter vorgeschlagen sinnvoll und finde es auch besser das alter Verhalten bei hidden (=versteckt) zu erhalten. Man gelangt also mit einer URL dahin und würde tatsächlich ein neues globales Attribut "forbiddenroom" einführen. Hier erreicht man die Räume nur wenn diese in anderen Instanzen erlaubt sind und auch nur in dieser!
Dadurch ist auch dem User bei der Nutzung mehr Flexibilität gegeben. Wobei ich zugeben muss genau diese mich momentan noch erschlägt, aber genau das reizt an eurem FHEM! Prima und danke dafür.
Ich finde daher die Abstimmung etwas voreilig aber wenn das hier so demokratisch zu geht auch wieder toll.

Viele Grüße
Matthias

[Prof. Dr. Peter Henning]

Hmmm.

Erstens gibt es keinen "Zwist" - wir haben Argumente ausgetauscht, das ist ein gelehrter Disput. Macht man seit Jahrhunderten so. Dass 300 sicherheitsrelevante Installationen negativ betroffen waren, war ein starkes Argument für eine temporäre Rücknahme der Änderung.

Zweitens gibt es keine "Demokratie". Jeder ist für seine Module verantwortlich, und was Rudi König letztlich aus einer Umfrage für Schlüsse zieht, bleibt seine Angelegenheit.

LG

pah

[dev0]

Bitte bedenke, dass die ca. 300 Installationen von Alarm sicherheitsrelevant sind.

Hmmm, nur so am Rande...
Sicherheitsrelevanten Anwendungen sollte man auch nicht ohne Tests aktualisieren, wenn sie keinem QM unterliegen. Und selbst dann nur mit Vorsicht...

[Prof. Dr. Peter Henning]

Sicherheitsrelevante Anwendungen sollte

Seufz. Wer erklärt den FHEM-Nutzern, dass sie mit dem Update vorsichtig sein sollen ? Wir sind in der Regel verwöhnt durch das gute Testen vor irgendwelchen Commits.

LG

pah