Feature Request: Custom properties for notes

[xardbaiz]

Hello. I want to re-open an old topic but with additional details

As a Joplin Plugin Developer, I would like to have the possibility to save custom note properties for saving plugin metadata regarding a selected note and have access to this info in the future (i.e.: from Joplin.workspace.selectedNote().properties)

Is it possible and how do other developers save their plugin metadata about notes (except note body) ?

[xardbaiz]

Anybody?

[roman_r_m]

Not quite what you're looking for but you can create a separate sqlite database for your plugin and store properties there.

[xardbaiz]

@roman_r_m interesting suggestion. But it's not plugin properties, it's note properties.
This approach will require creating a table for each note.
Also cleaning staff of non-existed (deleted) notes might be challenging
Other ways?

[roman_r_m]

@xardbaiz

This approach will require creating a table for each note.

It won't, unless I misunderstood what you need.

You can use just one table like so:

noteId	property1	property2
1	value1	value2

Or, if the set of properties is dynamic, you can still do with a single table:

noteId	property_name	property_value
1	note1_property_name	note1_property_value

@xardbaiz

Also cleaning staff of non-existed (deleted) notes might be challenging

I don't see an issue - just run a check at startup and then maybe once every hour to cleanup the properties of notes that have been deleted.

[JackGruber]

I hope the metadata field will be implemented so that the infos are also syncronized.

Feature request/discussion: Custom API metadata

Right, if you need the metadata to be synced you'd need to save it to the note itself. If it was really needed, I guess we could add a "userdata" field to notes which could be set by plugins and external apps, and it would be synced. I don't know if many plugins would need this though.

Let's add the possibility to plan todo?

Yes the thing is that if we add such a field it should have a use within the main app, and I'm not sure what would its purpose be. And of course that would make the change a lot more complex than just adding the field. Or else we add support for arbitrary metadata that can be set by plugins. But it's also not trivial to add.

[xardbaiz]

Last news on those was long time ago

[uroybd]

Sqlite supports the JSON field now. I think no new table will be required now. Only a new properties field (defaults to {}) in the post table. Users can store keys and values there and query on them.

[uroybd]

The API to access the properties must add some added access control. I'm considering a structure like this:

{
    "plugin1.namespace": {...keys & values},
    "plugin2.namespace": {...keys & values}
}

While a plugin can read all properties from all plugins, they shouldn't be able to add/modify/delete any property outside it's namespace. This will allow users to create a multi-plugin workflow while being safe from malicious plugins.