Comm Panel Template UI (#2885) — Proposal Scope & Technical Questions #4163
Replies: 1 comment 1 reply
-
|
Thanks for the questions and for thinking about this project. We definitely want to keep the templates within the Django system. Our users don't have access to the sendgrid interface (we manage that for them), so they wouldn't be able to add templates. They also don't have super easy access to the filesystem, so I think a full interface for them to put together email templates would be a nice component for a full proposal. At the very least, they should be able to write template overrides that serve as templates. In terms of proposal scope, it's really up to you, but I'd say it should include the emailbuilder.js implementation as a final product. I think there could still be some templates in addition to that, but letting users build their own emails (and then possibly saving those builds) would be good. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi @willgearty,
Thanks for clarifying — that's really helpful to know the focus should be on the proposal quality rather than PR volume.
I'm currently exploring the codebase around the comm panel to better understand the existing architecture as I work on my proposal for #2885 (Comm panel template UI). A couple of questions:
-For the template system, is there a preferred approach — e.g., database-stored templates with a Django model vs. leveraging SendGrid's built-in template features?
-Should the proposal also cover how templates interact with the existing comm panel workflow, or keep the scope strictly to template creation/management?
I'll follow up over email to discuss the proposal in more detail. Thanks again for the guidance!
Beta Was this translation helpful? Give feedback.
All reactions