SubM in SubG mit zugeordneter BCD kann diese nicht bearbeiten

{
 "ta": [
  {
   "name": "nd.bcd.update",
   "old": {
    "name": "ap-cn-0100-0199"
   },
   "new": {
    "description": "Anbindung WLAN APs im Bereich KIT CN, Gebäude 0100 bis 0199 (inklusive 0144 / Campus)TEST"
   },
   "idx": "a1b0a460-e396-450b-8d4d-8100e2570f4f"
  }
 ],
 "result": {
  "exception": {
   "error": {
    "code": 2,
    "description": "[cntl] Zugriff auf Datensatz für Benutzerkonto nicht erlaubt",
    "details": "Für den angegebenen Datensatz hat der angegebene Benutzer keine Zugriffsberechtigung."
   },
   "error_type": {
    "code": -20010,
    "name": "access_violation",
    "description": "Zugriffsüberschreitung"
   },
   "constraint": {
    "name": null,
    "description": null
   },
   "stacked_diag_params": {
    "sqlstate": "P0001",
    "message": "raise_exception",
    "detail": "",
    "hint": "",
    "context": "PL/pgSQL function eh.set_err(eh.stacked_diag_params_rec_type,name,name,eh.userparams_kv_rec_type[],eh.typecode_rec_type) line 22 at RAISE\\nSQL statement \"SELECT eh.set_err(sd_rec, fpkg, fname, up_kv_rec_list, et_rec)\"\\nPL/pgSQL function wapi_4_1.exec_ta_handler(bigint,jsonb,text,boolean,boolean,boolean,boolean,text) line 1285 at PERFORM\\nSQL statement \"select tah.out_stmt_pos, tah.out_stmt_idx, tah.out_obj_dict from wapi_4_1.exec_ta_handler(\\n    in_ta_id => ta_id,\\n    in_ta_osr_jsonb => ta_osr_jsonb,\\n    in_keep_tmp_ta => in_keep_tmp_ta,\\n    in_report_stmt_pos => in_report_stmt_pos,\\n    in_is_dry_mode => in_is_dry_mode,\\n    in_ignore_maint_state => in_ignore_maint_state,\\n    in_su_login_name => in_su_login_name,\\n    in_language_tag => lang_rec.tag\\n  ) AS tah\"\\nPL/pgSQL function wapi_4_1.ta_handler(text,text,text,boolean,boolean,boolean,boolean,text,text) line 46 at RETURN QUERY",
    "dml_src_table": null,
    "schema": "",
    "table": "",
    "column": "",
    "datatype": "",
    "constraint": ""
   },
   "others": {},
   "traceback": [
    {
     "function": "nd_wapi_4_1.chk_bcd_owner",
     "param": {
      "cntl.mgr.login_name": [
       {
        "state": null,
        "value": "Sijp9jIxODE2OQ==[SUBM]"
       }
      ],
      "nd.bcd.name": [
       {
        "state": "ALT",
        "value": "ap-cn-0100-0199"
       },
       {
        "state": "NEU",
        "value": "ap-cn-0100-0199"
       }
      ]
     }
    },
    {
     "function": "wapi_4_1.exec_ta_handler",
     "param": {
      "wapi.transaction_stmt.pos": [
       {
        "state": null,
        "value": 0
       }
      ],
      "wapi.transaction_stmt.idx": [
       {
        "state": null,
        "value": "a1b0a460-e396-450b-8d4d-8100e2570f4f"
       }
      ]
     }
    }
   ],
   "hint": null
  }
 }
}

added API Bug labels

changed the description

changed the description

auszug ausm code https://gitlab.net.scc.kit.edu/scc-net/net-suite/db-pgsql-app/-/blob/v4_1/wapi_4_1/_create_nd.pgsql?ref_type=heads#L614 -- als owner (oe-betreuer) darf nur die descr. und dhcp-params incl. dns_search_list geaendert werden; alles andere nur mit globalen rechten.

anm.: owner ist nicht erfuellt, dh. er muss oe-betreuer sein.

Dann hab ich den Code so beim Debugging richtig gelesen. Wäre hier noch ein aussagekräftigerer Fehler möglich?

moeglich schon, es ist wie immer eine frage der fehlermeldungs-datenpflege, also des eintragungsaufwands. es gibt sicher hunderte spezialfaelle, warum irgendwo eine berechtigung fehlt (nicht nur hier, sondern generell). dort jedesmal einen spezialtext fuer genau diese kombination der fehlerbedingungen zu formulieren, ist mir ehrlich gesagt zu aufwendig. konsequenterweise muesste man hier pro OT (ca. > 100) und funktion (3, also create, update, delete) eine fehlermeldung verfassen. aber das reicht nicht, denn selbst bei gegebenem OT und funktion kann es noch verschiedene faelle geben.

man kann vllt. umgekehrt verbal formulieren, was erforderlich ist (so wie oben im code-kommentar), aber wehe es aendert sich irgendwo was. dann stimmt der ganze krempel wieder nicht und erzeugt nur neue widersprueche und verwirrungen.

ich habs bisher nicht geschafft, eine (wie auch immer gemachte) wirksame bindung zw. der fehleraufrufstelle im code (exception handler) und dem hinterlegten fehlermeldungsdatensatz zu bauen. aktuell haben wir nur die beiden parameter fehlertyp und fehlercode, ueber die der anker zw. code und fehlermeldungsdatensatz hergestellt ist, also rein manuell.

das thema ist schon mehrmals und seit laengerem anhaengig.

Ja, das alte Thema.... An der stelle war es dann selber für mich nicht 100% transparent, warumd er Hauptaccount es durfte und der Sub nicht.

removed Bug label

closed