Support Center Bundle Laravel Package

Getting Started

v1.1.3.3 is a drop-in upgrade with no documented breaking changes, but it contains a security fix — treat the bump as mandatory rather than optional. Because it ships a "fixed vulnerability / broken security issue," schedule the upgrade as a patch release, not a bundled-with-feature-work release.

Minimal steps:

1. composer require uvdesk/support-center-bundle:^1.1.3.3 (or bump the constraint in composer.json and composer update uvdesk/support-center-bundle).
2. Clear compiled config and views: php artisan config:clear && php artisan view:clear && php artisan cache:clear. If you front this bundle through a Symfony kernel (it is a Symfony bundle at heart — UVdesk core, not native Laravel), also run bin/console cache:clear and re-publish assets so the updated theme/brand colors and marketing SVG actually land on disk.
3. Read the two places that changed: CHANGELOG-1.1.md (linked in the notes) and the updated README.md. The README is the only place the new public link feature is likely documented end-to-end, since there's no dedicated docs link in the release.
4. Find the new setting first: the "how much time a public link can be accessed" option lives in the bundle's ticket/support-center settings, not in your app config. Look in the admin settings area (or the bundle's DependencyInjection/Configuration.php + settings entity) before assuming you can override it in .env.

First use case: enable guest-accessible ticket links so customers can view a ticket thread without logging in — useful for embedding status in transactional emails, or for a "view your request" link after a webhook-driven ticket creation.

Implementation Patterns

Public links as an email/notification primitive. The high-value pattern is generating the public URL at ticket-creation and ticket-reply time and appending it to your outbound mail. This removes the "create an account to see your ticket" drop-off that support portals usually suffer from. Keep the link generation in one service/helper so expiry changes propagate everywhere at once.

Set expiry globally, not ad hoc. Configure the access window once in settings (e.g. 24h–7d depending on your data sensitivity) and let every generated link inherit it. Shorter windows for tickets containing PII, longer for low-sensitivity status pages. Don't hand-roll per-ticket expiry unless the bundle exposes it — assume the setting is global until you verify otherwise.

Treat the public route as an unauthenticated surface. Since the whole point is "no customer login," the link is effectively a bearer token in a URL. Patterns that hold up:

• Never log full ticket URLs at info level in your app or proxy logs.
• Add Referrer-Policy: no-referrer on pages that render the link.
• Prefer <a href> over third-party embeds that leak the referrer.
• If you mirror the link into your own Laravel app (e.g. a ticket_url column), encrypt it at rest or regenerate on demand.

Announcement section as a config-driven marketing slot. The release reworks the marketing announcement UI and SVG. If you were previously hardcoding a banner partial or CSS override to style it, delete that override and use the shipped section — otherwise the updated default theme and brand colors will fight your custom CSS. Wire it through the admin setting rather than a Blade/Twig override so future releases don't break it.

Attachment zip download. The large-attachment zip fix matters if agents bulk-download ticket attachments. If you proxy that download through your own controller, mirror the fix's intent: stream with readfile/chunked output rather than loading into memory, and raise memory_limit / max_execution_time only where needed. Test with a ticket holding several multi-MB files before you consider the upgrade verified.

Theme/color changes. Update brand colors in the admin settings after upgrading rather than patching CSS — the admin logo color now derives from the dynamic banner background, so a hardcoded logo color will look wrong against a changed banner.

Gotchas and Tips

• It's a Symfony bundle. In a Laravel-first stack you'll usually consume UVdesk via its API or an iframe/redirect rather than mounting the bundle natively. Confirm your integration path before upgrading, and check whether the "security issue" fix applies to the version your proxy layer actually runs.
• The release notes list the public link feature twice (once under Features, once under Misc). That's sloppy copy, not two features — don't go hunting for a second setting.
• Assets are the most common silent failure. New SVG, default theme, brand colors, and form UI won't appear until assets are re-published and browser/CDN caches are busted. If the UI "didn't change," it's almost always this.
• Config cache staleness can hide the new expiry setting entirely — the settings UI may render but the value won't take effect until container/config cache is rebuilt.
• Expiry semantics are ambiguous until tested. Verify whether the window is measured from generation, first access, or last access, and what the user sees on an expired link (404 vs a friendly message). Test with a 1-minute setting so you don't wait hours.
• Security fix = read the changelog diff. The one-line "fixed vulnerability broken security issue" is not enough to judge blast radius. Check the commit range for the 1.1.3.3 tag to see whether it's auth bypass, path traversal in the zip download, or token leakage — it affects your urgency and whether you need to audit logs for exploitation.
• Zip download fix interacts with server limits. If it now streams, reverse-proxy timeouts (nginx proxy_read_timeout, fastcgi_read_timeout) become the new failure mode for very large archives.
• Pin the version and regression-test the guest path. The customer ticket creation and login forms were both reworked; run a smoke test of guest ticket creation, login, and public-link access before rolling to production.
• Extension point: if you need custom branding on the public ticket page, override the bundle's templates via the standard resource-override mechanism rather than editing vendor files — otherwise the next patch release overwrites you.