Mabenan
Mabenan
Because the easy to use client side. With service module i don't have to build a json string per own coding on the client to request data from the backend.
Ok I solved this for my self my solution can be found in my Fork of the QxORM https://github.com/Mabenan/QxOrm The changes are contained in the commits https://github.com/Mabenan/QxOrm/commit/953ebb16aa8ab3cdc29deff471837d959fd84774 and https://github.com/Mabenan/QxOrm/commit/1bbfd0eab08d5190af9452bb60a9fc17b9b6c575
Problem I see here is with the parameters set in url. Maybe you have noticed that the url is build up like this. `://:/?#/`
`://:/#/?` From my experience if you call the app like this the parameters are ignored If we restructure it to the following `://://?` It gets complicated to detect the parameter...
Maybe i can give some new information on stealing secrets from github actions as i already tried this myself to get a lost key back. First of it is not...
I think i have found the problem for me the following line made the problem: `{"message":{"ok":0,"code":40352,"codeName":"Location40352","name":"MongoError"},"code":1,"level":"error","stack":"Error: MongoError: FieldPath cannot be constructed with empty string\n at C:\\Users\\doene\\Documents\\ServerManagerDocker\\node_modules\\parse-server\\lib\\Controllers\\DatabaseController.js:1170:21\n at runMicrotasks ()\n at...
after looking at the source i think it would be the easiest thing to check the message property and if it is not a string to execute a stringify maybe...
In my opinion the client dev always knows or at least expects if it is a list or a single entity. Thats why all request methods should return Future or...
As I think that a generic OIDC provider will take his time. I would volunteer for the moment to create an Keycloak provider. For sake of clearity i will create...