Open bustinbung opened 1 year ago
Thanks, maybe an easy way we can handle this is adding a "Display Name" field that users can customize, and then we display that if its set, and fallback to our internal name if its not set. The one sort of tricky issue I see is we also allow searching by subscription name, so we might have to fallback there too.
It makes a lot of sense to do this though, the Subscriptions view is a bit of a jumbled mess right now.
/cc-ing @sywhb as it goes along with some data improvements we are working on.
@jacksonh Yeah, we actually have the API to update the name of the subscription but the UI is not ready yet.
Previously we used the author's name as unique ID for the subscription but we are now using the author's email address for that so changing the name of the subscription is totally fine.
I will add another field author
to the subscription db table to hold the internal name too
@jacksonh Yeah, we actually have the API to update the name of the subscription but the UI is not ready yet.
Previously we used the author's name as unique ID for the subscription but we are now using the author's email address for that so changing the name of the subscription is totally fine.
I will add another field
author
to the subscription db table to hold the internal name too
Oh so querying for a subscription should use subscription:<author name>
right now it uses subscription:\"${item.name}\"
on the web.
@jacksonh Yeah, we actually have the API to update the name of the subscription but the UI is not ready yet. Previously we used the author's name as unique ID for the subscription but we are now using the author's email address for that so changing the name of the subscription is totally fine. I will add another field
author
to the subscription db table to hold the internal name tooOh so querying for a subscription should use
subscription:<author name>
right now it usessubscription:\"${item.name}\"
on the web.
I think both make sense. Should we support both subscription_author:<author name>
and subscription:<display name>
?
@jacksonh Yeah, we actually have the API to update the name of the subscription but the UI is not ready yet. Previously we used the author's name as unique ID for the subscription but we are now using the author's email address for that so changing the name of the subscription is totally fine. I will add another field
author
to the subscription db table to hold the internal name tooOh so querying for a subscription should use
subscription:<author name>
right now it usessubscription:\"${item.name}\"
on the web.I think both make sense. Should we support both
subscription_author:<author name>
andsubscription:<display name>
?
yeah ideally both would be nice
Have there been any updates on this? I actually just ran into this exact same issue (with the same newsletter!) and found this thread. Obviously not a huge deal but it would be nice to change the display name.
I need this! Any probability of getting this on the UI soon?
@sywhb anyone actively working on this ? I can give it a shot
New user here. I've been migrating some of my email newsletters to Omnivore, and noticed that some of my newsletters aren't named properly. I know that pulling the newsletter name from the email sender's name works most of the time, but in this case, I wish I was able to rename a newsletter within Omnivore. For example, The Verge's Installer newsletter is named "David Pierce," the author of the newsletter. While this isn't a big deal for now, I can see this becoming confusing in the future.