Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reconsider or make clearer behaviour of personal fields for new notes #219

Open
aplaice opened this issue Jan 26, 2025 · 0 comments
Open

Comments

@aplaice
Copy link
Collaborator

aplaice commented Jan 26, 2025

Currently, when one imports a new deck (or (I presume — haven't explicitly tested this) new notes into an existing deck) and sets a field as "personal", then that field is set to empty for the new notes. This is completely logical (personal fields mean that we keep the current value of the field, and since the note is non-existent, the current value is (arguably) the empty string), but possibly also confusing.

I see three-ish options:

  1. Keep the current behaviour (it's logical, in many cases expected and people may rely on it).
  2. Change the behaviour so that new imports keep the imported/"upstream" value (and only ignore the field (keep the "personal" value) for reimports).
  3. Make the explanatory text clearer that for new notes, setting a field to personal will mean that that field will be empty.
  4. Add an extra toggle that will determine which behaviour (keeping new fields empty or using the "upstream" value as the default) will apply for new fields. Possibly this should be a) "global" (for all fields) or b) per-field. (i.e. either have one extra toggle overall or one extra toggle per-field).

AFAICT both behaviours can make sense depending on circumstances (either the personal fields should never use the upstream values or their value should default to the upstream value, but should then be personalised).


(I'm mainly writing this down for my own future reference.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant