Skript löschen geht nicht - permissionError

[bergjet]

@thomas-braun sagte in Skript löschen geht nicht - permissionError:

Nein, die package.json spült sie kaputte Version an.

Obwohl in der package.json drinnen steht "@iobroker/socket-classes": "^0.5.3"

[Thomas Braun]

@bergjet

https://github.com/ioBroker/ioBroker.admin/blob/master/package.json

[bergjet]

@thomas-braun Ja, danke. Jetzt sehe ich auch die 0.5.4 dort stehen.
Also werde ich warten.

[haus-automatisierung]

@bergjet sagte in Skript löschen geht nicht - permissionError:

Obwohl in der package.json drinnen steht "@iobroker/socket-classes": "^0.5.3"

• In der package.json der 6.2.22 steht ^0.5.3, richtig (Thomas hat die package.json vom master branch verlinkt, da ist die dependency schon angehoben, aber dazu gibts ja noch keine Version).
• Das caret ^ in der Angabe bringt dir aktuell halt trotzdem 0.5.4. Siehe semver docs.. Aber ein manuelles Downgrade ist weiterhin möglich (Weil Admin 6.2.22 will ja ^0.5.3.

Und deswegen betrifft das Problem auch nicht alle. Wenn Du den Admin 6.2.22 installierst hast, bevor es 0.5.4 der Socket-Classes gab (also vor dem 23.09.), hast Du halt den 0.5.3 Stand bekommen. Alle danach den neueren - und damit auch den Bug.

[Shepherd]

Habe jetzt nett alles durchgelesen, aber hatte auch dieses Problem.
Komischerweise spielt aber auch der ganze script adapter mit dieser Version verückt.
habe dies nach demdowngrade erst bemerkt dass scripte ordentlich funktionieren mit der 6.2.12 und mir der 6.2.22 nicht.

6.2.22:
zb. umschalten Baustein geht nicht da schaltet er licht an einem shelly RGBW2 aus und wieder gleich an.
Oder z.B. das Relais am Shelly Plug2 schaltet er an und gleich wieder aus.
Bindings von Objekten funktioniert auch nicht.

Mit 6.2.12 funktionieren diese scripte.

Dachte schon was los ist.
Typisch ---- Nix gemacht geändert und geht nicht mehr -----Spruch.

Hat noch jemand von euch so Veränderungen festgestellt?

[haus-automatisierung]

@shepherd sagte in Skript löschen geht nicht - permissionError:

Hat noch jemand von euch so Veränderungen festgestellt?

Und Du bist sicher, dass die Admin-Version dafür verantwortlich ist? Das wäre ziemlich unlogisch, da bei einem "Umschalten" JavaScript der Admin-Adapter ja gar nix zu melden hat. Das läuft ja nur zwischen JavaScript-Adapter und js-controller.

[Shepherd]

@haus-automatisierung
Mir ist dies gestern Abend aufgefallen,
Heute nochmals ein script als neu angelegt und nochmals zusammen geblocklyt.
Ging nicht.
Da ist mir auch aufgefallen coppy von einem block in ein neues script macht er auch nicht konnte nicht speichern drücken.
Also komplett neu erstellt und ging nicht.
Nach downgrade auf die version 6.2.12 ging wieder das original script und das neu angelegte.
Sonst habe ich nichts geändert ausser natürlich den Container neugestartet nach dem admin downgrade.

Kann mir es anderst nicht erklären.

[Glasfaser]

@shepherd sagte in Skript löschen geht nicht - permissionError:

Heute nochmals ein script als neu angelegt und nochmals zusammen geblocklyt.
Ging nicht.
Da ist mir auch aufgefallen coppy von einem block in ein neues script macht er auch nicht konnte nicht speichern drücken.
Also komplett neu erstellt und ging nicht.
Nach downgrade auf die version 6.2.12 ging wieder das original script und das neu angelegte.

Jetzt schreibst du , was auch hier im Thread ist
Skript löschen geht nicht - permissionError

Oben hast du aber etwas anderes geschrieben , was ich mir auch nicht vorstellen kann

Komischerweise spielt aber auch der ganze script adapter mit dieser Version verückt.
zb. umschalten Baustein geht nicht da schaltet er licht an einem shelly RGBW2 aus und wieder gleich an.
Oder z.B. das Relais am Shelly Plug2 schaltet er an und gleich wieder aus.
Bindings von Objekten funktioniert auch nicht.

kannst du es reproduzieren.

[Shepherd]

Schrieb ja unten dass die Problematik mir erst gestern aufgefallen ist.
Beim rumprobieren mit auch noch zusätzlich Dinge wie z.b copy blockly Bausteine von scripte in ein anderes nicht geht aber neu erstellen geht.

1 Post und 2 Post sind mir beides aufgefallen.
Habe im 1. und 2. Post meine Probleme oder Erfahrung geschrieben.

Reproduzieren habe ich noch nett getestet.
Werde ich die Tage aber noch tun.
Muss ja nur den Admin wieder updaten und schauen.

Aber habe nix geändert außer Admin downgrade und die Probleme die ich hatte waren weg.

[Hakemann]

@heinz53 said in Skript löschen geht nicht - permissionError:

Nach der Änderung der admin Version auf 6.2.12 (nach folgender Anleitung) ist das Löschen nun wieder möglich.

iob stop admin
iob upgrade admin@6.2.12
iob start admin

Vielleicht hilft das bei der weiteren Fehleranalyse

Hat geholfen, danke. Bin neu und habe schon gedacht ich mach was falsch beim Löschen von Objekten (Berechtigungen oder so).

[Hakemann]

@hakemann Funktioniert hiernach bei euch der History Adapter noch normal? Also bei mir werden die Daten noch gelogt, aber sobald ich einen State zur HIstory hinzufüge oder die Adapter Einstellung öffne geht nichts mehr.

[Glasfaser]

@hakemann

Hat geholfen, danke.
Funktioniert hiernach bei euch der History Adapter noch normal?

Mache mal ein

sudo reboot

[Hakemann]

@glasfaser Werde ich heute Abend probieren. Bin aktuell auf Arbeit.

[Hakemann]

@hakemann
Das war es. Klappt wieder. Hatte es immer auf andere Weise gemacht und gedache, dass selbe zu tun. War wohl ein Trugschluss. Zukünftig weiß ich bescheid.

[Thomas Braun]

Funktioniert die 6.2.23 eigentlich wieder?

[mrjeschke]

@thomas-braun

Sieht erst mal gut aus. States und Scripte lassen sich wieder löschen.
Mehr hab ich noch nicht getestet.

[Lönne]

Es ist schön zu hören, dass das Problem anscheinend schon gefixt wurde, bin heute auch darüber gestolpert - Danke vielmals an alle Beteiligten

@thomas-braun sagte in Skript löschen geht nicht - permissionError:

Funktioniert die 6.2.23 eigentlich wieder?

Ist zwar nicht spezifisch für dieses Thema bzw. den Admin, aber

• wer entscheidet eigentlich, wann eine neue GIT-Version auch als reguläre Installation in der Adapterübersicht im Admin angeboten wird, also "stable" wird?
• hat eine manuelle Installation von GIT eine Auswirkung darauf, dass nachfolgende Updates evtl. nicht angezeigt werden?

Bsp.: fiktiver Adapter X

• aktuelle "stable" in Adapterübersicht: 4.3.21
• Installation von GIT: 4.3.22
• nun erscheint eine neue stable Version, die "über die Adapterübersicht" verteilt werden würde: 4.3.24 --> bietet mir Admin diese nun zur Installation an, oder wird die automatische Überprüfung durch die manuelle GIT-Installation irgendwie ausgehebelt

[Thomas Braun]

@lönne

Zwischen git und stable gibt's noch das beta-Repository.

Zu den Versionen: Wenn die Versionsnummer aus deinem gerade aktiven Repo die Nummer aus git übersteigt wird die höhere Version installiert.

[Lönne]

@thomas-braun

okay stimmt, jetzt habe ich es (glaube ich) verstanden. Installation von GIT kann unterschiedlich sein zu beta-Repository, das erklärt auch, warum man nur in Ausnahmefällen von GIT installieren sollte. Grundsätzlich kann man also sagen

GIT-Version >= beta-Repository-Version >= stable-Repository-Version

• Geben die Entwickler die neuen Versionen dann immer manuell für die einzelnen repos frei?
• Warum kommt es dazu, dass das beta-repo manchmal schon 6 Versionen weiter ist als stable, müsste es dann nicht schon höhere stable-Versionen geben?

[Thomas Braun]

@lönne sagte in Skript löschen geht nicht - permissionError:

Geben die Entwickler die neuen Versionen dann immer manuell für die einzelnen repos frei?

Ja, die Versionen müssen im entsprechenden Repo hoch geladen werden.

Warum kommt es dazu, dass das beta-repo manchmal schon 6 Versionen weiter ist als stable, müsste es dann nicht schon höhere stable-Versionen geben?

Dann hat der Maintainer noch nicht das Gefühl, das der Code reif für Stable ist. Gibt da verschiedene Philosophien. Generell sollte man mMn den Abstand nicht zu groß werden lassen.