Skip to content

Requirements and install

Returns Portal installs like every other extension sold here. Follow the shared procedure rather than a Returns Portal-specific one:

What is specific to Returns Portal

A fresh install is inert. Uploading the archive puts the files on the server and nothing else: no portal is reachable, OpenCart's own return form is untouched, and the queue is not in your menu.

Enabling the module is what creates everything. Under Extensions → Extensions → Modules → Returns Portal, the extension list's own + button creates the nine tables, the settings, the photo directory, the menu entry and the events that repoint your store's return links. Then open the module itself, switch Status on and save. The switch is on the Default store's tab only; a second store's tab does not show it.

Four permission entries of its own, not one. Under System → Users → User Groups, for every group that should be allowed to use Returns Portal:

extension/returns_portal/sale/request
extension/returns_portal/customer/erasure
extension/returns_portal/customer/personal_data
extension/returns_portal/customer/purge

They are separate from the module's own permission on purpose.

  • The first is Sales → Return Requests, the queue, which needs Access to read and Modify to decide anything.
  • The second is Customers → Erase Returns Data and the third is Customers → Personal Data. Each needs Access on its own route, and both also need Modify on OpenCart's own customer/customer before they will act: erasing or reading out what is held about a named person is at least as privileged as editing their account. Without that, the erasure entry is not in the menu at all.
  • The fourth is the screen that removes what the extension holds about everybody, reached from the settings screen. It needs Access and Modify on its own route, and deliberately does not ride on customer/customer, so you can give somebody the per-person screens and withhold this one.

So a warehouse user can be given the returns queue without being given every module in the store, and without being given the erasure screens.

A user without the queue permission sees no menu entry at all, not an error. That is OpenCart's behaviour rather than ours, and it is why the module's own settings screen states the situation in words: if somebody says the returns queue has disappeared, this is where to look, and its Give my user group the queue button grants the first three to your own group. The group that installed the extension is granted all four automatically; every other group is granted them here.

Issuing store credit needs one more permission, and it is OpenCart's own. Modify on customer/customer is what OpenCart itself demands before any transaction may be added to a balance. Somebody with the returns queue but not that permission can decide returns and cannot move money.

A store below OpenCart 4.0.2.0 is refused and says so on the screen rather than half-installing: no tables, no settings, nothing. Returns Portal rides seams that release has and older ones do not, including the one that lets it close OpenCart's own return form. A portal whose rules can be walked around from a link in the footer is worse than one that says no.

There is no scheduled task. Returns Portal registers no cron row of any kind, so nothing has to be set up outside OpenCart and nothing stops working on a host that will not run one. Housekeeping happens as a side effect of the writes that create the work.

What Returns Portal stores

Nine tables of its own, all prefixed with your store's table prefix and the extension's code: the requests, their lines, their decision history, the photo records, the store credit records, the stock put back on close, the refunds you recorded, the guest-lookup counters, and one small table it uses to remember your settings across an update.

Photos are files, kept outside the web root, under your store's storage/returns_portal/photos/ directory. That is deliberately not under the directory Tools → Uploads sweeps, which would empty a request whose record you still hold.

No OpenCart table's structure is changed and no core file is edited. It does write rows into three of OpenCart's tables. Every line of a submitted request gets a row in oc_return, with its history in oc_return_history, so that Sales → Returns keeps working. Store credit is a row in oc_customer_transaction, written directly rather than through OpenCart's customer model; see store credit for why. Erasure blanks the first name, last name, email and telephone on the oc_return rows the portal wrote, and on no others.

With the restock setting on, closing a request also adds the returned quantity back to the stock counters OpenCart's own checkout took it off (oc_product and oc_product_option_value), with the same statements OpenCart uses, run the other way; see Putting stock back. With it off, which is how it ships, no stock is written.

Updating to a newer version

Follow updating to a newer version in the order it gives. An update is an uninstall followed by an install as far as OpenCart is concerned, and Returns Portal is built for that:

  • No request, line, decision, photo, credit, restock or recorded refund is lost. Uninstalling drops no table and deletes no row or file, so the uninstall half of an update has nothing to take.
  • Your settings come back, per store, including the enabled flag, which the other extensions sold here deliberately do not remember. Here it matters: while the portal is on, OpenCart's own unverified return form is closed, so an update that silently reset that flag would silently reopen it. The one exception is Detailed logging, which comes back off; see what an update keeps.
  • RMA numbers keep meaning what they meant. They are derived from the request number, so a slip a customer is holding still names their return afterwards.
  • The permissions stay granted, so a group that had the queue or the erasure screens keeps them.