Secure Customer Documents for Magento 2
SKU: MGD-M2XP-CUS-SECDOCS
12 Months Included Support, with options to extend · 30 Days money-back guarantee · Renewals 40% off
Overview
The quiet risk sitting in your inbox.
Private files, provably private
Every merchant handles documents that were never meant to be public — signed contracts, invoices, wholesale price lists, warranty certificates, compliance datasheets. Yet the usual options leak by design: email attachments live forever in inboxes, and a pub/media link only has to be forwarded, indexed, or guessed once to expose a confidential file to anyone on the internet. None of it has access control, none of it expires, and none of it tells you who actually opened it.
MagedIn Secure Customer Documents replaces that risk with a private "My Documents" area in every logged-in customer's account, and a single admin screen where you decide exactly who sees each file, for how long, and under what conditions — one specific customer, a whole customer group (Wholesale, Dealers…), or any authenticated customer, scoped per store view.
Security that's in the architecture, not the adjectives
- Files live outside the web root (never in
pub/media) — there's no HTTP-reachable URL to leak, guess, or index, and every access is path-traversal sanitized. - Every download is authorized server-side, deny-by-default, through a single trusted point that re-checks authentication, status, store scope, validity, and targeting on each request. Unknown IDs return a generic denial, so nothing can be enumerated.
- POST-only, CSRF-protected downloads; per-document passwords are hashed (never clear-text) and shielded by a brute-force lockout that audits every wrong guess.
- True download caps reserved with an atomic update before streaming ("one download only" really means one), plus per-customer hourly rate limiting.
- A complete audit log of who downloaded what, and when.
Built for how you actually work
Whole-day Valid From / Valid To windows publish and expire documents automatically, with timezone-safe boundaries. Customers are emailed the moment a new document becomes available to them — duplicate-safe, so re-saving never re-spams them. Native Hyvä (Tailwind) and Luma templates run from one access-checked view model. No core rewrites, service-contract architecture, multi-store aware.
Turn "we hope it's private" into "we know it is."
How "private" files really get shared today
Every one of these has no access control. None of it ever expires.
Unprotected email attachments
The signed contract you emailed now lives forever in three inboxes and a shared drive — with no access control.
Guessable media links
A wholesale price list dropped into pub/media only has to leak once — forwarded, indexed or guessed — to be public.
"Private" storage URLs
That S3 link you pasted into a support reply is a bearer token in disguise: anyone who receives it can open the file.
No record of who opened it
You cannot say who actually downloaded a file, or when — so "we think they got it" is the best answer you have.
Why choose this extension
Because "private" should mean private — provably.
Private, provably
Uploaded files never enter the web-accessible tree, external links are never shown to anyone, and every single download passes through one deny-by-default authorization point on the server. There is no back-door URL, because the customer is never given one — only an authorized, POST-based, CSRF-protected response from your own store.
Keep your storage. Keep control.
Already hosting large PDFs and media on S3, SharePoint or a CDN? Point the document at the URL and Magento becomes the gatekeeper in front of it — same password, same validity window, same download limit, same rate limit, same audit log. Because the link never reaches the browser, a customer whose group or window closes simply stops being able to download.
The outbound request is an attack surface, not a convenience
Letting a store fetch a merchant-typed URL is exactly how SSRF happens, so it is hardened deliberately: address validation that rejects a host publishing any private record, connection pinning so DNS rebinding can't swap the target, protocol restriction, manual redirect following with re-validation per hop, a post-connect peer-IP re-check, and a mid-flight size cap. The URL rules run twice — on save and again at delivery.
The details that break in production are handled
A download limit that isn't atomic over-delivers under concurrency; this one reserves the slot before delivery. A list and a server check that drift apart show files that won't download; here both share one "now" and identical rules, with an integration test proving it. A notifier that re-fires on save spams customers; this one is duplicate-safe by design.
It respects your platform
No core rewrites, no preferences overriding core classes, declarative schema with real foreign keys, service contracts with clean Api/ and Api/Data/ DTOs, targeting via dedicated link tables, and a storefront listing that's a single indexed SQL query. Delivery is a strategy pattern wired in di.xml — a new source type is one class and one entry, and an unknown type fails closed.
It fits how you actually work
The storefront pages sit at customer/documents, joined onto Magento's own customer route, so they live where customers expect them. Luma and Hyvä-ready templates come from one view model. The admin is a familiar UI-component grid with fulltext search, filters, mass delete and a filterable Source column — plus granular ACL resources for managing documents, reading the log and changing settings.
Features
Everything you need to keep private files private.
Keep confidential files off the public web
Every uploaded document is stored outside the web root under var/, with traversal sanitization on every access and the real path never exposed. There is no media URL to leak.
Serve files you host elsewhere — without handing over the link
Point a document at an external URL on S3, SharePoint or a CDN. The link is never rendered in the storefront and is acted on only after every access check passes, so your existing storage keeps working while Magento keeps the control.
Make external files download every time
The default Force download through Magento mode fetches the remote file server-side and serves the bytes with a forced application/octet-stream, so it saves to disk instead of opening in a tab — and the customer's browser never touches the origin.
Fetch remote files without opening an SSRF hole
Outbound requests require the host to resolve exclusively to publicly routable addresses, pin the connection to the validated address, restrict protocols to HTTP/HTTPS, follow at most 3 redirects manually with full re-validation per hop, enforce the size cap mid-transfer, and forward no cookies, headers or referrer.
Deliver to exactly the right audience
Target a document to one specific customer, a whole customer group, or any logged-in customer, scoped to a single store view or all stores. Every access type is login-gated — guests are denied up front.
Authorize every download server-side
A single trusted, deny-by-default handler re-checks authentication, status, store scope, validity and targeting on every request, then enforces password, rate limit and download cap before a byte moves. Controllers, blocks and templates contain no authorization logic at all.
Lock sensitive files behind a hashed password
Add a per-document password — hashed via Magento's encryptor, never clear-text, constant-time verified, shown to the admin as a mask and never as a hash. Wrong guesses are throttled at five per rolling 15 minutes and recorded.
Enforce true download caps & rate limits
Cap a document at "N downloads" with a race-free atomic reservation taken before delivery — ideal for one-time licenses or certificates — and apply a rolling hourly rate limit keyed on customer id, so customers behind one office NAT never share a bucket.
Prove who downloaded what, and when
A full download audit log records document, customer, IP and timestamp on every successful download, searchable in a read-only admin grid — and the log survives document deletion.
Publish and expire on schedule, safely
Set whole-day Valid From / Valid To windows: files appear automatically when they go live and disappear when they expire, with inclusive boundaries that keep the storefront list and the download rule perfectly in sync.
Notify customers automatically, no duplicates
Cron-queued "a new document is available" emails go to the targeted customers scoped to the document's website, in batches, with structural duplicate suppression and validity re-checked at send time — so a future-dated document emails exactly when it goes live.
Look native on Luma and Hyvä
A Luma template plus a Hyvä-ready Tailwind template, both driven by one shared, access-checked view model, so the customer experience is consistent and correct on either storefront.
How it works
Add a document, decide who sees it and for how long — save.
One admin screen decides exactly who sees what, for how long, and under what conditions. The intended customer sees it in their My Documents area and downloads it through one trusted, authorized path. Nobody else can reach it.
- Upload the file into Magento's protected storage, or point at a URL you already host.
- Target one specific customer, a customer group, or any logged-in customer — scoped by store view.
- Add an optional hashed password and a whole-day Valid From / Valid To window.
- Cap total downloads for one-time licenses and certificates — enforced atomically.
Where the file lives
Two places to keep the file. One place customers can get it.
The two sources are mutually exclusive and enforced server-side — choosing one clears the other, and an incomplete source is rejected at save time. What does not change is the security path: whatever the source, the customer submits the same POST download form, and it is only acted on after every gate has passed.
Uploaded file
The file is stored in Magento's protected storage under var/, outside the web root, with no HTTP-reachable URL at all. This is the default: existing documents need zero migration and behave exactly as before.
External link
The file stays on S3, SharePoint, a CDN or your DMS. Magento stores only the URL — never rendered in the page, the HTML source, or a data attribute — and validates it on save and again at delivery.
Force download through Magento
Your store fetches the remote file server-side and sends the bytes itself. The file always downloads instead of opening in a tab, and the URL is never disclosed — there is no address bar to copy, nothing to bookmark, nothing to forward.
Trade-off, stated plainly: the bytes traverse your store (bandwidth is used twice) and the transfer is bounded by a maximum size — 100 MB by default, refused rather than truncated — plus connect and transfer timeouts.
Redirect
Costs your store no bandwidth and has no size ceiling, sent with no-cache headers and Referrer-Policy: no-referrer so the third-party host never receives the customer's account URL.
Be aware of what you're choosing: the file's origin decides whether it downloads or opens inline, and the customer ends up holding a URL Magento can no longer revoke — so pair it with a pre-signed, expiring URL. If the setting is ever missing or unrecognized, delivery falls back to force-download, never to redirect.
Every download, checked on the server
One deny-by-default path, in a fixed order. Only at the end does a byte move.
Authenticated
The customer must be logged in. Guests are denied before anything else runs.
Module status
The extension is enabled and the document is active — otherwise, stop.
Store scope
The document is in scope for the current store view.
Validity window
"Now" falls inside the whole-day Valid From / Valid To window.
Targeting
This customer matches the target: specific customer, their group, or any logged-in.
Password
If set, the hashed password verifies in constant time — but the brute-force block is checked first.
Rate limit
The per-customer rolling hourly limit has room for another download.
Download cap
An atomic conditional update reserves the slot before delivery, so the cap always holds.
Deliver & audit
Only now does the file move — streamed from protected storage, or fetched server-side for an external link — and the download is written to the audit log.
Files outside the web root
Uploaded documents live under var/, never in pub/media — so there is no HTTP-reachable URL to leak, guess or index, and every access is traversal-sanitized. External URLs are never rendered at all.
Atomic download-cap reservation
The per-document limit is reserved with a single conditional update before a byte is served, so "one download only" means one — even under a race, with no read-then-write and no TOCTOU window.
Hashed password + full audit log
Passwords are hashed and constant-time verified behind a brute-force block checked before the password is even compared — five attempts per rolling 15 minutes — and every successful download is logged, a record that survives document deletion.
Use cases
Three documents you could secure this afternoon.
One-to-one legal & financial paperwork
A B2B operator needs to send a specific customer their signed contract, monthly statements and invoices — without those files living in email threads forever.
Upload each document, target it to that single customer, and optionally set a password on the most sensitive ones.
The customer downloads from My Documents, and every download is logged with IP and timestamp — a definitive answer to "did they receive it, and when?" The log stays put even if the document is later deleted.
Dealer price lists that already live on S3
A merchant running Wholesale and Dealer channels keeps price lists, manuals and safety datasheets in bucket storage the marketing team already maintains. Migrating the files is a non-starter.
Create each document with External Link as the source, target the relevant customer group, scope it to the correct store view, and set a Valid From date for the new quarter's pricing.
Magento fetches the file and hands it over as a forced download, so it saves straight to disk and nobody ever sees the bucket URL. Older versions expire on schedule, and every dealer is emailed once the moment their new list goes live.
One-time licenses & certificates
A store selling software licenses or issuing warranty and compliance certificates needs each file downloaded once, by the right person, provably.
Set the document's download limit to a single download and target the specific customer, relying on the atomic reservation to guarantee the cap.
The cap holds even if the button is clicked twice at the same instant, and the audit log records exactly who pulled the file and when — turning "we think they got it" into a record they can stand behind.
Compatibility
Confirmed to run where you run.
Driven by this product's real edition and version compatibility attributes. Confirm the exact tested patch range with MagedIn for your environment.
- Magento Open Source (Community)
- Magento Commerce (Enterprise)
- Magento Commerce Cloud
- Magento B2B
- Magento 2.3.x
- Magento 2.4.x
Installation
Four commands. No static deploy on Hyvä.
Require the package with the Composer key you receive by email, enable, upgrade, and flush.
- 01 Require the package via Composer using the key you received by email.
- 02 Enable the module with bin/magento module:enable.
- 03 Run setup:upgrade to apply the module's schema and data.
- 04 Flush the cache and you're done.
$ composer require magedin/module-customer-documents
$ bin/magento module:enable
$ bin/magento setup:upgrade
$ bin/magento cache:flush
✓ No static content deploy needed on Hyvä
Specifications
The kind of extension a developer signs off on.
- Support Period
- 12 Months Included Support, with options to extend
- Refund Period
- 30 Days
- Extension Code
- 100% Open Source Code
- Editions Compatibility
- Magento Open Source (Community), Magento Commerce (Enterprise), Magento Commerce Cloud, Magento B2B
- Versions Compatibility
- Magento 2.3.x, Magento 2.4.x
Changelog
What's changed, release by release.
v1.1.0 Jul 2026
[1.1.0] - 2026-07-22
Added
- External file links: a document is now sourced from either an uploaded file or an
external http(s) URL, chosen per document with a new "Source" field (uploading is
unchanged, and remains the default). Externally hosted documents pass through the identical
access chain — targeting, validity window, password, download limit, rate limit and audit
log — and the URL is never rendered in the storefront: it is only acted on after every gate
has passed.
- New
source_typeandexternal_urlcolumns onmagedin_customer_document, added via
declarative schema. source_type defaults to 1 (Uploaded File), so existing rows are
backfilled automatically.
- New members on
Api\Data\DocumentInterface: theSOURCE_TYPEandEXTERNAL_URLconstants
and the getSourceType(), setSourceType(), getExternalUrl() and setExternalUrl()
methods.
- Forced download for external links (default): Magento fetches the remote file server-side
and serves it as an attachment, so the file always downloads instead of opening in the
browser, and the external URL is never disclosed to the customer — it cannot be copied from
the address bar, bookmarked or forwarded. A redirect mode remains available for very large
media, selectable per store under External Link Delivery.
- SSRF hardening for the server-side fetch (
RemoteAddressValidator,RemoteFileFetcher):
the host must resolve exclusively to publicly routable addresses (loopback, RFC1918,
link-local incl. the 169.254.169.254 cloud metadata endpoint, CGNAT, TEST-NET and
multicast are all refused), the connection is pinned to the validated address to close the
DNS-rebinding window, curl is restricted to HTTP/HTTPS, redirects are followed manually and
re-validated per hop (max 3), and the transfer is bounded by a size cap and connect/total
timeouts. Nothing about the customer — cookies, headers, referrer — is forwarded.
- Delivery strategies (
DeliveryResolver+LocalFileDelivery/ExternalLinkDelivery),
mapped in di.xml by source type, so the download handler no longer knows how bytes are
produced and a new source type needs no change to it.
- System configuration for proxied downloads: maximum forced-download size (default 100 MB),
connection timeout (5s) and transfer timeout (30s).
ExternalUrlValidator, enforcing anhttp/httpsscheme allowlist, a control-character
(header-injection) guard, rejection of embedded credentials, a length cap and an optional
per-store domain allowlist. It runs on save and again at delivery, so a value written
directly to the database still cannot inject a response header.
- System configuration: "Allow External Links" (on by default) and "Allowed External Link
Domains" under Security & Uploads.
- Admin: "Source" selector that switches between the upload and URL fields, plus a "Source"
column and filter on the documents grid.
- Storefront: externally hosted documents show "External" in place of a file size, in both the
Luma and Hyvä listings.
Changed
- BREAKING — storefront URLs moved under the customer account route. "My Documents" is now
customer/documents (was customer_documents) and the download endpoint is
customer/documents/download (was customer_documents/download). The module joins
Magento_Customer's existing customer route instead of declaring a front name of its own,
so the pages sit alongside customer/account and customer/address where they belong.
The account-navigation link, the download form action, the post-download redirect and the
"new document available" email link all follow automatically.
The old URLs now return 404. Upgrade action: add a redirect from customer_documents
to customer/documents at the web-server level, or re-send the affected notifications.
- BREAKING — the storefront layout handle was renamed from
customer_documents_index_index
to customer_documents_index, following the new route. Upgrade action: if a theme or a
project module customized the "My Documents" page through a customer_documents_index_index.xml
layout file, rename it — otherwise the customization silently stops applying, with no error.
- BREAKING — two controller classes were renamed:
Controller\Index\Index→
Controller\Documents\Index and Controller\Download\Index → Controller\Documents\Download.
Upgrade action: update any di.xml plugin, preference or type declaration that referenced
the old class names; leaving them in place fails dependency-injection compilation.
- BREAKING — constructor signatures changed on two services.
SecureDownloadHandlernow
receives a DeliveryResolver where it previously received a FileStreamer, and
DocumentSaveHandler gained two required arguments (ExternalUrlValidator and Config)
ahead of its logger. Upgrade action: update any di.xml that passes arguments to either
class by name, and any subclass calling parent::__construct(). FileStreamer itself is
unchanged and still streams uploaded files, now from within LocalFileDelivery.
- BREAKING —
Api\Data\DocumentInterfacegained four methods. Any class implementing this
interface directly must add getSourceType(), setSourceType(), getExternalUrl() and
setExternalUrl(). Classes that extend Model\Document inherit them and need no change.
- Saving a document now fails with a clear admin message when the selected source is
incomplete — an upload document with no file at all, or a link document with a missing or
invalid URL — instead of allowing a document that cannot be delivered. Note that 1.0.0
permitted saving a document with no file; if any such documents exist, a file must be
attached before they can be saved again.
- Switching a document from an uploaded file to an external link detaches and deletes the
now-orphaned file from protected storage.
Fixed
- Saving a document with a validation error no longer surfaces as an unhandled admin error and
no longer discards the merchant's form input — the error is shown as a normal admin message
and the entered data is restored.
- The admin form no longer renders a phantom "uploaded file" chip for an external-link document
built from a stale file path.
Security
- Proxied downloads force a generic binary content type, so a hostile remote content type
cannot turn a download into an inline render on the store's own origin, and the
Content-Disposition file name is stripped of quotes, path separators and control
characters to prevent response-header injection.
- Fetched copies live in a private temporary directory under
var/and are deleted as soon as
the response has been sent, including when building the response fails.
- In redirect mode, the redirect is sent with
Cache-Controlno-cache headers and
Referrer-Policy: no-referrer, so a (possibly pre-signed, short-lived) URL is not cached by
intermediaries and the third-party host never receives the customer's account URL.
- The external-link delivery mode fails safe: any unrecognised or corrupted configuration value
resolves to forced download (the private behaviour) rather than to redirect.
- Note on redirect mode only: once redirected, the customer's browser holds the final URL and
Magento cannot revoke it. Use the default forced-download mode, or pre-signed/expiring URLs,
for files that must not be re-shared.
- Note on enabling external links: "Allow External Links" is on by default, which means an
admin with document-edit permission can cause the store to make an outbound request to a URL
they type. Setting the "Allowed External Link Domains" allowlist is strongly recommended; turn
the feature off entirely if you do not intend to use it.
v1.0.0 Jul 2026
[1.0.0] - 2026-07-21
Added
- Document entity with full admin CRUD: UI-component grid (search, filters, mass
delete) and add/edit form, backed by declarative schema, service contracts and a
repository.
- Access targeting by public (any logged-in customer), specific customers, or
customer groups, scoped to a store view or all stores. Login-gated for every
access type; guests and the "NOT LOGGED IN" group are never valid targets.
- "My Documents" customer-account section for both Luma and Hyvä (dedicated
Tailwind template), driven by a single access-checked view model.
- Secure download flow through a single trusted, deny-by-default server-side
authorization point: files stored outside the web root (non-web-accessible) with
path-traversal protection, POST-only CSRF-protected downloads, and the raw file
path never exposed.
- Optional per-document password, hashed via Magento's encryptor and verified in
constant time; the admin field shows a masked placeholder when a password is set
and never exposes the stored hash.
- Per-document download limit enforced atomically before streaming, plus a rolling
per-hour download rate limit (keyed by customer id for authenticated customers).
- Whole-day validity window (Valid From / Valid To, date-only): available from the
start of the start day through the end of the end day; empty bounds mean
"available immediately" / "never expires". The storefront listing and the
download decision share one reference so they always agree.
- Download audit log (customer, document, IP, timestamp) with an admin grid; the
log survives document deletion.
- Cron-queued "a new document is available" email notifications to the targeted
audience, with duplicate suppression, website-scoped group expansion, send-time
validity re-check (future-dated documents email when they go live), failure
capture and automatic cleanup of old entries.
- Admin system configuration under the "MagedIn Technology" tab: enable/disable,
allowed file extensions, maximum upload size, download rate limit, and
notification sender/template.
Security
- Every download decision is made server-side, deny-by-default; an unknown document
id returns a generic denial so ids cannot be enumerated.
- Files are stored outside the web root with traversal sanitization — no
HTTP-reachable URL to leak.
- Per-document passwords are hashed (never clear-text), read from the POST body only
(never the query string), and protected by a per-(document + identity)
brute-force throttle with an audit trail.
- Internal exception details are logged rather than shown to the storefront.
FAQ
Questions, answered.
Still unsure whether it fits your setup? Talk to our team before you buy.
Can guests or not-logged-in visitors download these documents?
No — and that's by design. The entire feature is login-gated. Even the "public" access type means any authenticated customer; guests are denied up front and the "NOT LOGGED IN" group is never a valid target. Documents are for customers who have signed in.
Where are uploaded files stored, and can someone reach them by URL?
Uploaded files are stored outside the web root under var/, not in pub/media. There is no HTTP-reachable path to the file. The only way to obtain one is through the authorized, POST-based download flow, and even then the customer's browser only ever sees a friendly filename — never the real storage path.
Can I use files I already host on S3, SharePoint, or a CDN?
Yes. Set the document's Source to External Link and paste the URL. Everything else works identically: the same targeting, validity window, password, download limit, rate limit, and audit log. The URL is never rendered in the storefront — the customer submits the same POST form, and the link is only acted on once every gate has passed. You can also restrict which hosts are allowed via a domain allowlist, or switch external links off entirely with a server-side kill switch.
Will the customer ever see the external URL?
Not in the default "Force download through Magento" mode. There, your store fetches the file server-side and sends the bytes itself, so the customer's browser only ever talks to your storefront — there is nothing to copy from the address bar, bookmark, or forward, and the file always downloads instead of opening in a tab. If you switch to Redirect mode, the customer is sent to the URL and does end up holding it, and the file's origin — not Magento — decides whether it downloads or opens inline. Use redirect only with a pre-signed, expiring URL. If the setting is ever missing or unrecognized, delivery falls back to the safe streaming mode.
Is there a size limit on external files?
Yes, in forced-download mode: the Maximum Forced-Download Size defaults to 100 MB, and a file above it is refused rather than truncated. The transfer is also bounded by connect and transfer timeouts, and the bytes pass through your store, so bandwidth is used twice. Redirect mode exists precisely for very large media — it costs your store no bandwidth and has no size ceiling, with the inline-vs-download and URL-exposure trade-off described above.
Isn't fetching a merchant-supplied URL an SSRF risk?
It would be, which is why the outbound fetch is treated as security code. The host must resolve exclusively to publicly routable addresses — one private record and the host is rejected — and loopback, RFC1918, CGNAT, and link-local ranges including the 169.254.169.254 cloud metadata endpoint are blocked outright. The connection is pinned to the validated address to close the DNS-rebinding window, protocols are restricted to HTTP/HTTPS, at most three redirects are followed manually with full re-validation on each hop, the peer IP is re-checked after connect, the size cap is enforced mid-transfer, and no customer cookies, headers, or referrer are ever forwarded.
I already have documents in the extension. Does the new source setting change them?
No. The source column defaults to Uploaded File, so every existing document keeps its file and behaves exactly as before — no migration, no re-saving. External links are an additional option you opt into per document.
How do I make sure a document is downloaded only once?
Set the document's download limit. The cap is enforced by a single atomic conditional update that reserves the slot before delivery, so it holds even if the button is triggered twice at the same moment — no read-then-write, no race. Leave the limit empty or 0 for unlimited downloads.
Is it compatible with Hyvä?
Yes — a Hyvä-ready Tailwind template ships alongside the Luma one, and both are driven by the same access-checked view model, so behavior and permissions are identical on either storefront. As with any Hyvä-compatible module, the template needs to be wired into your Hyvä theme.
Will it slow my store down or require core hacks?
No core rewrites and no core-overriding preferences. The storefront "My Documents" list is a single indexed SQL query (no N+1), targeting uses dedicated link tables, and the module is built on service contracts to SOLID principles. Notifications run on cron in batches, off the request path. The one cost to be aware of is deliberate and configurable: forced-download delivery of external files moves bytes through your store, bounded by the size cap and timeouts you set.
What can I actually configure — and at what scope?
The enable flag, the hourly download rate limit, and the notification settings (on/off, sender identity, email template) are configurable per website and store view. The upload rules (allowed extensions, maximum file size) and all external-link settings (allow links, domain allowlist, delivery mode, maximum forced-download size, connect and transfer timeouts) are global, set once at default scope. The thresholds that protect you — brute-force lockout, cron batching, cleanup retention — are sensible built-in defaults, so there's nothing to misconfigure.
How does targeting work for a large customer base?
Target by customer group — that's the right tool at scale, and it costs nothing to maintain as customers come and go. The "specific customers" picker is a multiselect capped at 2000 customers, which suits one-to-one and small-list delivery; for anything broader, groups are the answer. Note that documents targeted at all authenticated customers are not emailed — notifications go to specifically targeted customers and groups.
Does it link documents to specific orders, invoices, or B2B companies?
No. Targeting is by specific customer, customer group, or any logged-in customer, scoped by store view. Automatic order/invoice/shipment linking, B2B company-level sharing, GraphQL and REST coverage, CSV import/export, and ZIP bulk download are not part of this module.
What are the requirements?
Magento Open Source or Adobe Commerce 2.4.x, PHP 7.4+, the MagedIn_Core module and the MagedIn\Framework\Magento2 autoloading, and the PHP cURL extension for forced-download delivery of external files. Email notifications use Magento's standard transactional email and cron — no third-party service required.
Write Your Own Review
Only registered users can write reviews. Please Sign in or create an account