|
|
|
Front-End Actions
Introduction | Security | Disabling Actions
Cart Actions | Item Actions | Schedule Actions | Event Actions
Introduction
There are a number of things that O3 will do, provided with the right parameters. You can pass these values in as POST or GET (i.e. in a form, or in the query-string)... The easiest way to use these actions is to define a form in O3's Forms Manager.
Permissions are always checked before actions are performed to ensure the user is allowed to perform the requested action. See the page on Access for more info.
When things are created/updated - their Creator/Updator field is set to the current user, and the created/updated date is set.
Here's a list of all the actions you can trigger in O3, along with dependant parameters etc...
Security Issues
Some of these action allow users to update fields which may be undesirable for your application. For example, when updating an item, you can change it's name, expiry date, status etc... There's a simple low-security method to deal with this, and a fairly simple full security method too...
Things can only be updated according to the permissions set, so if you can trust your users - i.e. they are paying customers, part of your company etc. then it's unlikely they'll try to hack the system.
The sytem would be 'hacked' by passing parameters into O3 which you didn't specifically allow on your website. For example: the hacker would create an item update form based on the one on your site, but with additional fields to extend the expiry date, or change the status etc.
It's worth noting that if someone does this sort of thing then you know exactly who they are - so they're clearly not master-criminals. If you're concened about malicious attacks, then you should consider disabling certain features as described below.
Notes
- Users with admin access always get full access to things, whether accessing data from the front, or back-ends.
- It's not possible for non-admins to blank any fields from the front end! Blanks fields are not included in the update.
The Simplest Method To Prevent Unwanted Fields From Being Updated
Obviously you have total control over the update forms etc. which are presented to the user, so you can simply not provide a field allowing them to update an item name, for example.
If you can trust your users, then this is probably sufficient. Otherwise, you can disable the actions completely...
Disabling Update Actions
You can stop certain columns (fields) from being available for update from the front-end of the site. This is done in the simplest and most effective way - by commenting out the code.
To remove functionality, refer to the table below. It tells you which file to edit, a '#Note' label you can search for to find the exact place (cut & paste into your editor's search box), and a description of what to do.
Item Actions
Schedule Actions
Event Actions
Cart Actions
| submit=Add To Cart |
|---|
Add a product or item to the cart, or increment the quantity if it's already there.
Required Fields
- product or item - The product or item to add to the cart.
Optional Fields:
- quantity - Specifies the item Type. Must be a valid O3 type. If set, the item is created and a row of typedata is created too.
|
| submit=Change Quantity |
|---|
Change the quantity of a cart item.
Required Fields
- product or item - The product or item to add to the cart.
- new_qty - The new quantity
|
| submit=Remove |
|---|
Remove a cart item from the cart.
Required Fields
- product or item - The product or item to add to the cart.
- cart - The cart ID
Optional Fields:
- os0 - The first option selection (value) (products only)
- os1 - The second option selection (value) (products only)
|
| submit=Empty Cart |
|---|
Confirm emptying the cart. This displays a confirm form containing the text defined in the Settings.
Optional Fields
|
| submit=Yes - Empty Cart |
|---|
Empty the cart. If the cart ID isn't supplied - the current user's cart is emptied.
Optional Fields
|
Item Actions
| submit=New Item |
|---|
Create a new item. The item status & expiry are taken from the settings.
Optional Fields:
- it_type - Specifies the item Type. Must be a valid O3 type. If set, the item is created and a row of typedata is created too.
- it_category - Specifies the item Type. Must be a valid O3 category.
- copy_schedule - Creates a new schedule for the item by copying a template. Must be a valid O3 schedule. If set, the schedule is created and the item is associated with it.
|
| submit=Update Item |
|---|
Create a new item. The item status & expiry are taken from the settings.
Required Fields
- curitm - The item to update. Must be a valid O3 item.
Optional Fields
- new_it_name - The new item name.
- new_it_title - Item title.
- new_it_desc - Description.
- new_it_type - Schedule name.
- new_it_schedule - Schedule name.
- new_it_status - Status (A|N|P|E|I).
- new_it_category - Category name.
- new_it_expiry - New expiry date.
|
| submit=Approve Item |
|---|
Approves the item for publishing. This changes the status of the item from 'Pending' to 'Approved'.
Required Fields
- curitm - The item to delete. Must be a valid O3 item.
| submit=Delete Item |
|---|
Confirm the delete. This creates a confirmation form in the $o3msg variable (which should be displayed at the top of any page's content area - like it is in the catalog page) which then appears at the top of the page, so the user can confirm the delete. It's not necessary to do this confirmation stage - you can do the delete directly, see below.
Required Fields
- curitm - The item to delete. Must be a valid O3 item.
- curtype - The item's type (if set). If this isn't set, the type data won't be deleted - leaving it 'orphaned'.
|
| submit=Yes - Delete This Item |
|---|
Do the delete. This deletes the specified item, and any type-data.
Required Fields
- curitm - The item to delete. Must be a valid O3 item.
- curtype - The item's type (if set). If this isn't set, the type data won't be deleted - leaving it 'orphaned'.
|
| submit=Renew Item |
|---|
This sets the expiry date of an item to be today plus the Expiry Interval set in the Settings.
Note that this will work for ALL items - so it could be easily hacked to update any item. To counteract this - assuming your Free & Premium listings are of different Types - add something like this SQL to the end of the following line in list/list-func.php':
$qry="UPDATE o3_items SET it_expiry=DATE_ADD(now(), INTERVAL $s_expiry_interval), it_status='$new_stat' WHERE it_name='$_REQUEST[curitm]' AND it_type='freelisting'";
Required Fields
- curitm - The item to delete. Must be a valid O3 item.
- curtype - The item's type (if set). If this isn't set, the type data won't be deleted - leaving it 'orphaned'.
|
|
Schedule Actions
| submit=New Schedule |
|---|
Confirm the creation of a new schedule. The status is taken from the settings.
No fields
|
| submit=Copy Schedule |
|---|
Copy the specified schedule.
Required Fields
- cursch - The schedule to copy.
Optional Fields
- new_sc_name - The new schedule name.
|
| submit=Update Schedule |
|---|
Create a new schedule.
Required Fields
- cursch - The schedule to update.
Optional Fields
- new_sc_name - The new item name.
- new_sc_desc - Description.
- new_sc_type - Type.
- new_sc_category - Category.
- new_sc_status - Status (A|N|P|E|I).
- new_sc_start - New start date.
- new_sc_end - New end date.
- new_sc_interval - Interval (i.e. '1 DAY', '7 DAY', '1 MONTH')
- new_sc_multi - Allow multi events in the same interval? (Integer=number of events allowed).
- new_sc_scupd - Schedule update permissions.
- new_sc_scdel - Schedule delete permissions.
- new_sc_scapp - Schedule approve permissions.
- new_sc_evadd - Event add permissions.
- new_sc_evupd - Event update permissions.
- new_sc_evdel - Event delete permissions.
- new_sc_evapp - Event approve permissions.
- new_sc_evstatus - Default event status.
- new_sc_evcfmtext - Create event confirm text.
- new_sc_evcfbtext - Create event confirm button text.
- new_sc_evproduct - Event Product. If set - buying the product sets the event.
- new_sc_scupdfrm - Schedule update form.
- new_sc_scdelfrm - Schedule delete form.
- new_sc_scappfrm - Schedule approve form.
- new_sc_evcrfrm - Event create form.
- new_sc_evupdfrm - Event update form.
- new_sc_evdelfrm - Event delete form.
- new_sc_evappfrm - Event approve form.
- new_sc_evadd_eso - Event add: Email Schedule Owner? (Y|N).
- new_sc_evadd_eeo - Event add: Email Event Owner? (Y|N).
- new_sc_evchg_eso - Event change: Email Schedule Owner? (Y|N).
- new_sc_evchg_eeo - Event change: Email Event Owner? (Y|N).
- new_sc_evadd_sub - Event change: Email subject.
- new_sc_evadd_body - Event change: Email body.
- new_sc_evchg_sub - Event change: Email subject.
- new_sc_evchg_body - Event change: Email body.
|
| submit=Approve Schedule |
|---|
Confirm approval. This creates a confirmation form in the $o3msg variable allowing the user to confirm the approval.
- cursch - The schedule to approve.
|
| submit=Yes - Approve This Schedule |
|---|
Approves the schedule for publishing. This changes the status of the schedule from 'Pending' to 'Approved'.
Required Fields
- cursch - The schedule to approve.
| submit=Delete Schedule |
|---|
Confirm the delete. This creates a confirmation form in the $o3msg variable (which should be displayed at the top of any page's content area - like it is in the catalog page) which then appears at the top of the page, so the user can confirm the delete. It's not necessary to do this confirmation stage - you can do the delete directly, see below.
Required Fields
- cursch - The schedule to delete.
- curtype - The schedule's type (if set). If this isn't set, the type data won't be deleted - leaving it 'orphaned'.
|
| submit=Yes - Delete This Schedule |
|---|
Do the delete. This deletes the specified schedule, and any type-data.
Required Fields
- cursch - The schedule to delete.
- curtype - The schedule's type (if set). If this isn't set, the type data won't be deleted - leaving it 'orphaned'.
|
|
Event Actions
| submit=Confirm Event |
|---|
Confirm the creation of a new event. The status is taken from the schedule settings.
Required Fields
- ev_schedule - The new event's schedule. Must be valid.
Optional Fields:
- ev_name - Specifies the event name. Must be unique.
- ev_type - Specifies the event Type. Must be valid.
- ev_start - Specifies the event start date/time. Must be a valid MySQL date format (i.e. 'YYYY-MM-DD HH:II:SS').
- ev_end - Specifies the event end date/time.
|
| submit=Approve Event |
|---|
Confirm approval. This creates a confirmation form in the $o3msg variable allowing the user to confirm the approval.
- curev - The event to delete. Must be a valid O3 item.
|
| submit=Yes - Approve This Event |
|---|
Approves the event for publishing. This changes the status of the event from 'Pending' to 'Approved'.
Required Fields
- curev - The event to delete.
| submit=Update Event |
|---|
Update an event.
Required Fields
- curev - The event to update.
Optional Fields
- new_ev_name - The new item name.
- new_ev_title - Item title.
- new_ev_desc - Description.
- new_ev_type - Schedule name.
- new_ev_schedule - Schedule name.
- new_ev_status - Status (A|N|P|E|I).
- new_ev_start - New start date.
- new_ev_end - New end date.
|
| submit=Delete Event |
|---|
Confirm the delete. This creates a confirmation form in the $o3msg variable (which should be displayed at the top of any page's content area - like it is in the catalog page) which then appears at the top of the page, so the user can confirm the delete. It's not necessary to do this confirmation stage - you can do the delete directly, see below.
Required Fields
- curev - The event to delete.
- curtype - The event's type (if set). If this isn't set, the type data won't be deleted - leaving it 'orphaned'.
|
| submit=Yes - Delete This Event |
|---|
Do the delete. This deletes the specified event, and any type-data.
Required Fields
- curev - The event to delete.
- curtype - The event's type (if set). If this isn't set, the type data won't be deleted - leaving it 'orphaned'.
|
|
|
