Add unescape to getAllType function

[PTR-inc]

This is used in the recode encrypted fields function

Some db functions have the un/escape in the function, but not all. For some it is done in app after the get.

I would propose to move it to the db functions instead of having to not forget it at the application level. I haven't checked all functions, but the GetAll function also doesn't do the unescaping for you.

@si458 What do you think?

[PTR-inc]

The recode function didn't work properly because of the missing unescape in the getalltype function. That triggered this.

[PTR-inc]

@si458 I think a full check on the mongo/nedb un/escape db functions is necessary to do this properly.

[PTR-inc]

@si458 Checked some of the functions used throughout the application for the different (un)escapes, here for example is the specific acebase db escapes, beside the nedb escapes. The only escape needed for mongo (v3.6 onward) is that a field must not start with a '$'.
Searching for 'unescape' in the source finds f.e. here and others, which, if forgotten in new functions, could lead to the bug fixed with this PR for the recode function. It would at least be safer to put all the (un)escaping in the db functions, I think.

Is it an idea to eliminate the need for escapes at all by generating the identifiers with something like crypto.randomUUID() or the UUID package?

That would remove a lot of overhead, room for mistakes and make it future-proof and more db agnostic.
What are your thoughts?

[DaanSelen]

@si458 Checked some of the functions used throughout the application for the different (un)escapes, here for example is the specific acebase db escapes, beside the nedb escapes. The only escape needed for mongo (v3.6 onward) is that a field must not start with a '$'. Searching for 'unescape' in the source finds f.e. here and others, which, if forgotten in new functions, could lead to the bug fixed with this PR for the recode function. It would at least be safer to put all the (un)escaping in the db functions, I think.

Is it an idea to eliminate the need for escapes at all by generating the identifiers with something like crypto.randomUUID() or the UUID package?

That would remove a lot of overhead, room for mistakes and make it future-proof and more db agnostic. What are your thoughts?

Have you already spoken about it in the Monthly meetings, seems like a good plan!

[PTR-inc]

@DaanSelen Uhm, monthly meetings? Don't know about that.

[DaanSelen]

@DaanSelen Uhm, monthly meetings? Don't know about that.

Every last thursday of the month we meet in a voice/video call and discuss the state of MeshCentral, what's new and what's coming. If you can, join us (I can't make it this thursday). Here for reference: https://github.com/Ylianst/MeshCentral/wiki/Community-Monthly-Meetings

[PTR-inc]

Ah oké, thanks, will check it.

[DaanSelen]

Lets get this PR out of limbo and into the master!

[PTR-inc]

At least fix this indeed. The enhancement to the id generation/field escapes is of a different order of magnitude to implement. And would need the oké from @si458 and @Ylianst before even starting.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions]

This pull request has been automatically closed due to inactivity. If you'd like to continue working on it, please reopen it.

[DaanSelen]

This pull request has been automatically closed due to inactivity. If you'd like to continue working on it, please reopen it.

@si458 is this closing in order? Or a mistake?

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[PTR-inc]

Not stale

[DaanSelen]

Not stale

And what's preventing Merge? @si458