Use-case: Centralized client portal for ticket submission

[hfloyd]

Hi! This looks really cool.

I understand the main use-case is that this is installed inside the Umbraco sites that are being supported (aka the client sites), which I can see working really well for developers/agencies with a maintenance service business model. I have been thinking of setting up a client portal on my own site which would operate a little differently - rather than have clients create tickets from inside their own Umbraco sites, I'd like to have the clients login as "members" on my site, and submit a ticket there (I would be providing some other client-specific information/links to billing, etc. which I'd rather manage on my side), but the back-office management interface you have created looks really nice, and it would be great if I could use that to respond to the tickets.

I peeked through the code a bit, but it wasn't immediately clear to me if it would currently be possible (using existing Models/APIs) to create/read the ticket data from a "front-end" request, if I were to build a submission form on a member-accessible website. The other requirement would be linking tickets to a Member rather than a back-office User, which might also be difficult with the current architecture.

Anyway, this might be a use-case way outside of your intentions or plans, but I'd be curious to hear your thoughts about it.

[Lantzify]

Hi!

It's a really cool idea! As of right now I don't have a public API controller. But you should be able to do a DI of the uSupportTicketService and from there you would get access to Get, Create & GetPagedActiveTickets.

I am very open to adding the capability to have members as the authors! Right now, I only store the author id which could be the member id. But then there is the mapping a author to a user/member. I am a bit unsure of how we could tell if a author is a user or member. Do you have any suggestions?

Right now I am taking a break of further developing right now. Since I have been working on this nonstop for so long now. But I will probably continue in the near future 😅

[hfloyd]

Thanks for the quick reply😁

Thanks for the info about the services, creating a controller sounds like it wouldn't be any issue, then.

If you store the author data using the guid, rather than the integer, then perhaps if we added an interface...
Like ITicketPerson, with properties : guid, username, display name, email, type (User or Member)....

The model code could check the stored guid against all users, and if not found, against all members... Or if you were also concerned about persistent storage of that basic person info (in the event of a user/member getting deleted), it could be all stored together in is own "cache" table and looked up from there.

What do you think?

(PS. It's totally fine that you are taking a break from programming on this project, this conversation isn't meant to pressure you back into doing that, maybe I can dip in and help out if we have a plan to move forward 🙂)