Feature discussion: customer accounts that span multiple events?

[Luca-Timo]

What I'm trying to do

I work with recurring clients, same company, multiple shoots over time. Today each event has its own URL + password, so a client who books me three times ends up juggling three links and three passwords, and there's no place they can go to see "all my galleries."

I'd like to give those clients a single login that takes them to a small portal listing every gallery they have access to.

How I imagine it working

• A new customer account entity, separate from admin users. Email + password, with password reset via email (like the admin flow).
• Customers can be associated with one or more events from the admin UI when creating or editing an event.
• A new customer login form. After login, the customer sees a dashboard of their galleries and can click through to any of them.
• Existing per-event password access stays exactly as it is today. Customer accounts are an additional path, not a replacement. A guest with just the link and password should still work for one-off recipients.

What I think this preserves

• The "send a link to a one-time guest" workflow stays the default.
• Existing events keep working. Customers are opt-in per event.
• Admin remains the source of truth for who sees what. Customers can't self-register or claim galleries.

Open questions I don't have good answers to yet

• Password precedence. If an event has both a password and an associated customer account, does the customer skip the password prompt, or do they still need it? My gut says "customer login is enough," but that changes the security model.
• Guest vs. customer email collision. Today the same email can show up as a guest on many events without any account. What happens when that email is later promoted to a customer account, do past events retroactively show up in their portal?
• Multiple customers per event. A wedding has the bride and the groom. Both want access. One event, two customer accounts? Or just the same One Time Link?
• Migration of existing events. Current events don't have customer linkage. Is this purely opt-in for new events, or is there a way to bulk-associate customers with their old galleries?
• Per-customer download limits / watermarks. Today these are per-event settings. Do they stay per-event, or does the customer concept change anything?

Why I'm asking before building

This is a real database + auth + UI change, and I don't want to fork. If it's something the maintainer would consider taking upstream, I'd rather we agree on the shape before I write code. If it's out of scope for PicPeak's design philosophy, I'd appreciate hearing that too. Fully respect the decision either way.

I'm willing to help build it

If this gets a "yes, with these constraints," I'm happy to take on the implementation. Comfortable with the existing stack (Node/Express + React/TypeScript + Postgres) and willing to take direction on the auth parts since that's the most sensitive area. Happy to start with a small design doc / sketch before any code.

Open to alternative shapes too. If there's a simpler path that gets 80% of the value (e.g. a "client view" link that lists multiple galleries without a real account), I'd love to hear it.

[the-luap]

@Luca-Timo thanks for brining up that Idea. I never yet thought about because my use cases that I had solved already a while ago was much simpler but I think that it is an interesting idea and I would be happy to support you with a design and integration.

[Luca-Timo]

maybe the multiple events per customer account would also be interesting in combination with #172 wedding planers would have access to multiple events, while customers only got their event.

a smaller selection of images which are public would then be the 3. level of access.

any thoughts on this?

[the-luap]

yes, I am thinking that it is like an lightway application admin but without access to the admin pages but just the galleries in a different view.

[Luca-Timo]

@the-luap dev preview of the customer login for multiple projects

[the-luap]

that looks very good to me

[Luca-Timo]

@the-luap the current status of the customer page is in commit #403.

Current Page:

Future expansion ideas:

[the-luap]

nice job! when seeing the suggested menu, do you have such use cases for quoting, creating invoices and such?

[Luca-Timo]

Hey @the-luap, thanks again for the customer-accounts foundation we
built towards in this thread. PR #403 has been a great experience and
I've been testing the result on my own dev deployment.

I wanted to come back here and ask a bigger question before I either
keep contributing or stop pushing the scope further:
how far do you want picpeak to go in the photographer-workflow direction?

For context, my own use case is steadily creeping towards "central
hub for everything I do with a client." The customer portal #403
ships is already letting me consolidate gallery delivery, but the
adjacent pieces (booking, quotes, invoicing, day-before reminders,
threaded comms) still happen in scattered tools, and the
customer-portal sidebar with Calendar/Quotes/Bills stubs could make a great addition to the existing scope

Concretely, I'd love to evolve picpeak into:

1. Reminder emails — N days before an upcoming event, the
   photographer-configured template is sent to the customer.
   Smallest surface, biggest perceived professionalism win.
2. Booking / calendar / scheduled Event — (customer sees the photographer's
   availability and requests a slot; admin confirms.) Customers also see the scheduled Events including notes.
3. Quotes / offers — admin builds a quote, customer reviews
   and accepts/declines from the portal.
4. Billing / invoices — invoice from accepted quote, send,
   track payment state (manual marking is fine, Stripe etc. as
   later integrations). Bills visible in customer Dashboard and sent via email
5. Customer messaging — threaded admin ↔ customer comms tied
   to an event, so the conversation history doesn't live in
   email. No Prio at all

I'm not asking for a yes on any of this, and I'm aware this is
a meaningful step beyond "secure photo gallery delivery." I'm
genuinely just trying to figure out:

• Is this direction one you'd want picpeak to grow into, or do
  you see it staying focused on gallery delivery + the
  customer-accounts layer feat: customer accounts (#354) — recurring logins, profile, password reset, branded customer surface #403 lands?
• If the direction is fine but the scope feels too big to live
  inside core, would you be open to plugin/module-style
  extensions (the customer-surface tabs are already gated by
  per-feature flags, so the architecture is friendly to that)?
• If neither, that's a totally legitimate answer;
• Of the five items above, is there a subset you'd consider
  in scope? Reminder emails feel the most obviously "still
  picpeak"; messaging the most disputable.

Whatever you decide, the customer-accounts groundwork has already
been worth shipping. Just want to make sure I'm pointing my
contribution time where it's welcome rather than building parallel
features in a fork that drift away from upstream.

Thanks 🙏

[the-luap]

@Luca-Timo let say for my use cases the application is way overdue already but it does not mean that I am not open to help and bring the application further. If you want to implement that I will support you as I am happy if we can grow something that will help more people and at least for me it sounds reasonable.

The only thing I would prefer when implementing all those items, that we do it in a way that we can let users enable those functionalities, so the users or even I can decide to just use the app for simple picture sharing with clients or they want to have the full feature for the full client handling process.

If you want we can also chat about it more in private via email/discord or other channel.

[Luca-Timo]

@the-luap thanks, exactly the answer I was hoping for. Letting users choose how much of the app they actually use is the right framing.

Three options I see:

1. Feature flags in core (my preference). Each pillar (reminders, calendar, quotes, bills, messaging) is a togglable feature, maybe even existing features which are deamed "advanced". feat: customer accounts (#354) — recurring logins, profile, password reset, branded customer surface #403 already establishes the pattern with per-customer flags + global master toggles, so the architecture is there. Pair with a setup wizard on first login asking which features to enable, defaults to all-off, so existing installs and gallery-only users see no change unless they opt in.

2. Plugin/module system. Cleanest separation but a lot of plumbing. Probably overkill for this scope; more relevant if we ever add third-party integrations (Stripe, QuickBooks, etc.).

3. Separate fork ("picpeak pro"). Worst option IMO, splits the user base, doubles maintenance, drifts over time.

My pitch: option 1 with the setup wizard. Keeps "simple picture
sharing" as the default, opts users in feature-by-feature, reuses #403
groundwork. Suggested rollout order:

1. Reminder emails (small, self-contained, immediate value)
2. Calendar — read-only first, then booking
3. Quotes (admin sends, customer accepts/declines, manual)
4. Bills (generated from accepted quotes, manual payment state)
5. Messaging — lowest priority, would genuinely consider leaving to email

Happy to take this off-thread, feel free to reach out via my GitHub profile and we can pick whichever channel works for you. I am open to anything but discord.

Thank you

[Luca-Timo]

@the-luap you can find a email-address on the website linked in my github profile.

[the-luap]

I also would prefer option 1 as the other once I don't really like. For option one instead of a setup wizard I would prefer having a "Features" page within the settings menu to enable and disable the advanced features and having a short description for each advance feature to describe what it does. How do you see that?

[Luca-Timo]

@the-luap are there other features you would like to add to the advanced features? per gallery styling, analytics, css, api tokens in addition to the customer page?

[Luca-Timo]

I think we could simplify the admin pannel main menu, by moving the following items into the settings tab:

• Email settings
• Branding
• Event types
• CMS Page

This would declutter the main page and sort the settings to other related features / settings

[the-luap]

I would prefer doing it like this:

so we put most of the items that you already mentioned under the settings, adding a feature setting page for your additional items like quoting, calendar and so on and if you enable those, they will get visible in the menu bar

[Luca-Timo]

This looks realy good, lets build it with a feature tab.

Do you want me to build it or do you have a beta, where you got the screenshot from?

[the-luap]

I have dropped the framework now into the beta, so we have the redesigned menu bar and the feature settings. I did not yet implement the new features, just added it to the features for short design items.

[Luca-Timo]

@the-luap have a look at my beta branch https://github.com/Luca-Timo/picpeak/tree/beta if you have time.

Any feedback? I would be pleased to hear it.

[the-luap]

you are right, but still I would prefer to put then the picpeak logo and put the collaps icon on the bottom

[Luca-Timo]

should the logo hide if the menue is compacted or just display the icon?
found a feew options:

or as "menu item" above dashboard

which is your favorit?

sidebar bottom is already quite crowded:

[the-luap]

that is how I would prefer it:

[Luca-Timo]

we can most certainly do it like this, it is a bit strange, that the position of the button moves, but that is fine for me, do you have a working prototype, which i can implement?

[the-luap]

you are right, I tested it again, with right align on bottom and that would be best option for me. I just have those mockups, no real prototype of it:

[Luca-Timo]

Hi @the-luap,

I implemented most of the crm features in Luca-Timo/feat/crm branch (PDF pipeline, quotes, invoices, tax report, Storno, business profile, customer accounts, branding…).

Before we go further, a few things I want to align on:

Reconciliation strategy — at this featureset, how should we handle the implementation into your upstream repo?
Testing — how should we handle the testing of such an extensive feature set? I think Bugs are to be expected, but how can we mitigate risks?
Next features — still got a bit of work to do (monthly billing per customer, per-customer doc language, contracts).
Cheers
Luca

[the-luap]

I am ok to push it to beta and it would be good if you can test at least the basic items and if we run into any bugs, I am ok as it's a beta and I also create bugs time to time. Maybe we will create one stable update before but lets see.

[Luca-Timo]

@the-luap long time no see, I hope you are doing well!

I am currently implementing the last features / starting to test. And I plan to have the crm features done this weekend.

If it is okey for you, I would ping you, when I am ready. I would also appreciate some feedback on the current implementation.

Have you received my email from the 12.05. (It was sent from another address)

[the-luap]

@Luca-Timo sure I will have a look over the weekend and yes, just replied you.

[the-luap]

here some items:

• i8n is missing german translations on account details,
• the hourly rate field on the account is only in CHF but we might need a currency setting
• the hourly rate field does not allow normal inserting of a number
• on /admin/clients/hours there is space missing between the white boxes of selecting a customer and the customer/hour details
• when putting in hours, currently it only allows from to time but at least on sevdesk which I am using you can also just put the time like 1 hour or 1,5 by a field with 00:00 h
• on invoice the buttons does not fit to the text size
• /invoice - import historical - missing i8n translation of the button text
• on the time tracking there is a normal selection field for the customer and on invoice there is a mixed selection field - I think we should just use one type
• when having tracked hours there is a button to say "abrechnen" but it should be create invoice or just create draft invoice to not misslead
• for the pdf invoice it currently adds a skonto automatically
• on the tax settings we need the tax id field which has to be put into the pdf (at least in germany)
• maybe we should anyway put some more items on the settings like the whole "briefkopf" with address, company name and so on
• it would be good to have the logo within the pdf and maybe we can use also colors from the branding settings within the pdf

overall a very nice job and I know that it is already very much that you have done and even if that looks like much to do

[Luca-Timo]

• rename customers to crm, or other more intuitive name