Closed eliandoran closed 2 years ago
Hi, you're right that this would fit into the concept of workspaces, and several other features are already implemented like this. My main reason to hesitate with "workspace-scoped" features is that I don't know how much would these be used and if they are bringing net benefit. Even though on the implementation side it's not very complicated, it does become somewhat complex on the product side, needing to explain all this in the documentation.
There are also some corner cases, e.g. web clipper sends notes to the calendar, but there's no way to choose to which one. Adding support for that would increase implementation work and web clipper complexity. Another possibility is to keep the limitation that webclipper (and Trilium Sender) can send only to the "primary" calendar.
Having said that, I'm not against the idea.
Hello, @zadam .
I've just checked the beta version with this feature implemented. It works great, I have already started to move my notes into the dedicated work calendar root.
Thank you for your time and taking the initiative to implement it!
Describe feature
I am currently using Trilium Notes for both personal and professional purposes. In order to better separate the two, I have split the notes into multiple workspaces and this has been working out great for a few months now.
The only improvement I could see in my process at the moment is to find a way to have the "day notes” functionality ("Today" button, “Calendar” button) in both workspaces. Currently the daily notes are only in the Personal workspace, but they would be more than useful in the Work workspace as well. From what I saw in the implementation, this feature looks for
#calendarRoot
which does not take into consideration workspaces.It makes sense that the calendar root has to be unique, as it is also specified in the documentation, but I believe it is a very good use case to add support for multiple calendar roots in order to accommodate the user's personal and work environments.
I would attempt to implement such a solution, as it would greatly benefit me and I would gladly share with you, however I would have two main questions:
Possible solutions
calendarRoot
label or directly for the day's attribute (dateNote
).#calendarRoot
per workspace would involve changing both the client and the server (ETAPI) to optionally pass the user's current workspace. In doing so, we can limit the search for thecalendarRoot
ordateNote
by the workspace.calendarRoot
anddateNote
attributes would remain. Same with thegetTodayNote()
implementation.#calendarRoot
, such asworkCalendarRoot
,personalCalendarRoot
. The switching between them would be achieved by adding new, optional parameters which allow changing the desired root label. This would also involve the day note searches to be done under the root element, so it might introduce some additional complexity.Thank you for your time, @zadam .
Additional Information
No response