Audit Log
Objective
The Audit Log is where the Venture’s admin users can monitor changes made either by a Seller on their products/orders or by a backend user to different settings.
- In case of disputes, for instance, it is therefore possible to monitor recent changes.
- Furthermore, this shows how often and via what channel (e.g API, CSV, or directly on the Seller Center website) changes occur.
Content
The Audit Log can be found under Administration > System > System Status > Audit Log
If changes are triggered by a user, the Audit Log will list their email and whether it is possible to detect their IP address.
The overview below lists all available triggers and their purposes:
| Event name | Trigger | Content |
| account_status_change |
Admin or system changes status to “active,” “inactive,” or “deleted” via UI or CSV. For instance, when order limit has been reached or is reset. |
Seller name, Seller short code, current status |
| acl_role_info | ACL manager creates or updates role information. | Role name, role description, other roles who can assign this role, description of whether it is a Seller or backend role. For updates, the previous settings are listed |
| acl_role_ressource | ACL manager changes assigned resources to role. | Resource added or removed, to which role they were added or removed, previously-enabled resources |
| acl_role_change | ||
| attribute_change | Backend user edits an attribute. | Attribute name (if set) and the current settings for an attribute (e.g., name, quality control enabled, fixed value set) |
| attribute_type_migration_finish | ||
| attribute_type_migration_run | ||
| attribute_visibility_change | Backend user edits visibility of an attribute. | Attribute name, current status |
| cancellation_fee_editon | Backend user edits cancellation fee. | |
| category_to_attr_set_mapping | Backend user assigns a category to an attribute set. | Category name, currently mapped attribute set, previous attribute set. |
| commission_change | Backend user edits commission on global or Seller-level. | Seller name +ID (only if change did not happen on global-level), category, category ID, current commission value, previous commission value |
| commission_tax_rate_edition | Backend user edits the tax rate (VAT / WHT) for commissions. | General and Seller-level, previous and current value for VAT and WHT |
| counterfeit_brand_restriction | Backend user activates or deactivates a brand for brand restriction. | Brand name, restriction status (restricted or permitted) |
| counterfeit_seller_brand_approval | Backend user approves certain brands for a specific Seller. | Seller name, Seller ID, brand (name) |
| csv_seller_setting_changed | Backend user uploads Seller settings. | All settings that have been uploaded with their value |
| fee_change | Backend user updates global or Seller-level fee settings. | Seller name, Seller ID, fee name, fee ID, changed value, previous value or current and previous status |
| fee_deleted | Backend user removes fee on Seller-level. | Seller name, Seller ID, fee name, fee ID |
| finance_qc_reject | ||
| mail_template_id_change | Backend user updates email template ID. | Template type and transition from previous value to current value |
| mail_template_status_change | Backend user updates email template status. | Template type and status transitions |
| master_create | Backend user creates a master template for products. | |
| master_linked_product | A product is linked to an existing master product template. | |
| master_price_competition | ||
| master_updated | Major update on a master template is detected. | Template name, PID, changed values and attributes |
| password_change | Any user triggers password change within Seller Center under User icon > Change password | Email and user ID |
| payment_method_change | Backend user creates or updates the setting for a payment method. | Creation and update of payment method, name, display name, and charge money flag (active or inactive) |
| payment_provider_event | ||
| price_change | Any user updates a price. This is triggered for the regular price via Seller Center website, CSV, or API import. | Seller SKU, Shop SKU (if the product exists in Shop), old price, and new price |
| product_attribute_updated | ||
| product_create | Product is created via either Seller Center UI or CSV/API import. | Creation source (API, CSV, UI => nothing special listed), Seller SKU, product name |
| product_deleted | Product status is changed to “deleted” | Source (API, CSV, UI => nothing special listed), Seller SKU, product name, previous and current status |
| product_description_updated | Product description is updated. | Shop Sku, Seller SKU, ID, truncated description |
| product_status_change | Status change is triggered via either Seller Center website, or via CSV/API import. | Seller SKU, Shop SKU (if product exists in Shop), previous status, current status, source (API, CSV, or UI=> nothing special listed) |
| promotion_created | Creation of a promotion | Promotion name, start/end date |
| promotion_delete | Deletion of a promotion | Promotion name, ID |
| promotion_updated | Update of a promotion | Promotion name, ID, start/end date |
| qc_approve | Backend user approves a pending product. | Seller short code, product SKU, Shop SKU (if product exists in Shop), whether individual approval or CSV-triggered |
| qc_approve_without_images | Product is approved, even if no image is uploaded; works only in combination with this feature. | Seller short code, product SKU, Shop SKU (if product exists in Shop), rejection reason, whether individual rejection or CSV-triggered |
| qc_reject | Product is rejected via UI/CSV. | Seller short code, product SKU, Shop SKU (if product exists in Shop), rejection reason, whether individual rejection or CSV-triggered |
| qc_setting_attribute | Attribute setting for automatic quality control | Attribute name, ID, current quality control status |
| qc_setting_category |
Backend user updates:
|
|
| return_request_create | ||
| return_request_dispose | ||
| seller field change | Seller status changed, due to system delisting, admin delisting, seller self delisting (holiday mode activation) | seller name, seller id, current status, status change source |
| seller_profile_field_config_change | Seller profile field configuration is updated. | Field name, ID, value (e.g. “Enabled,” “Mandatory,” “Editable,” “Quality control required”) |
| seller_profile_qc_approval | Profile of a Seller is approved after Seller registration. | Seller name, ID, approval status |
| seller_profile_update_qc_approval | Profile of a Seller is approved after Seller has updated profile. | Seller name, ID, approval status |
| seller_profile_update_qc_rejected | Profile of a Seller is rejected after they have updated profile. | Seller name, ID, rejection status |
| seller_verify | ||
| settings_change | Any change on global settings or Seller settings that are done via Seller Center website | Seller name, ID, all settings with their configured value |
| shipment_provider_change | Update on a global shipment provider setting | Shipment provider name, ID, configured values |
| shopial_event_raised | Tracking activation/ deactivation of Shopial feature (Facebook shop) | Seller name, ID and activation status, previous status |
| shop_api | ||
| special_price_change | Any user updates a special price; this is triggered for the special price via Seller Center website, CSV, or API import. | Seller SKU, Shop SKU (if the product exists in Shop) old price and new price, old date and new date |
| statement_payout_approved | ||
| stock_change | Any user updates a stock value via website, CSV, API, or OMS (due to order processing). | Seller SKU, Shop SKU (for a synced product), current stock value, previous stock value |
| transaction_approved | ||
| transaction_rule_change |
|
|
| transaction_rule_deleted | ||
| user_change | Modification of user under “Manage user” | User data like role, email, name, and language |
Audit Log in Kibana
Currently all before mentioned events get stored in the Audit Log within Seller Center and are available for 3 month. As this time period is for most ventures to short for being compliant, there happened additonal development to have a more modern solution in place. From now on it is possible to have the Audit Log available within Kibana, which uses Elasticsearch. That way it is possible to store and search (almost) unlimited amount of data.
The switch to Kibana is fully optional, but highly recommended, in order to have access to logged data for longer than 3 month, to use a better search (including filtering) and to stay compliant.
If you need more information or have further questions, or want to have the external Audit Log setup, please contact Ulf Kirsten