VbzCart/tables/event vc ord hold - Revision history

Woozle: syntaxhighlight

2017-11-21T21:25:37Z

syntaxhighlight

← Older revision		Revision as of 21:25, 21 November 2017
Line 24:		Line 24:
	* '''ID_Type''' -> {{l/vbzcart/table\|ord_hold_type}}.ID		* '''ID_Type''' -> {{l/vbzcart/table\|ord_hold_type}}.ID
	==SQL==		==SQL==
	<mysql>CREATE TABLE `event_vc_ord_hold` (		<syntaxhighlight lang=mysql>CREATE TABLE `event_vc_ord_hold` (
	`ID_Event` INT NOT NULL AUTO_INCREMENT,		`ID_Event` INT NOT NULL AUTO_INCREMENT,
	`ID_Order` INT NOT NULL COMMENT "orders.ID",		`ID_Order` INT NOT NULL COMMENT "orders.ID",
Line 36:		Line 36:
	PRIMARY KEY(`ID_Event`)		PRIMARY KEY(`ID_Event`)
	)		)
	ENGINE = InnoDB;</~~mysql~~>		ENGINE = InnoDB;</syntaxhighlight>

Woozle: /* SQL */ BOOL doesn't take a modifier

2017-06-03T12:12:14Z

SQL: BOOL doesn't take a modifier

Woozle: /* SQL */ ID -> ID_Event

2017-06-03T11:05:44Z

SQL: ID -> ID_Event

← Older revision		Revision as of 11:05, 3 June 2017
Line 25:		Line 25:
	==SQL==		==SQL==
	<mysql>CREATE TABLE `event_vc_ord_hold` (		<mysql>CREATE TABLE `event_vc_ord_hold` (
	`ID` INT NOT NULL AUTO_INCREMENT,		`ID_Event` INT NOT NULL AUTO_INCREMENT,
	`ID_Order` INT NOT NULL COMMENT "orders.ID",		`ID_Order` INT NOT NULL COMMENT "orders.ID",
	`ID_Type` INT NOT NULL COMMENT "ord_hold_type.ID",		`ID_Type` INT NOT NULL COMMENT "ord_hold_type.ID",
Line 34:		Line 34:
	`doExamine` TINYINT(1) DEFAULT NULL COMMENT "TRUE = this order needs further examination",		`doExamine` TINYINT(1) DEFAULT NULL COMMENT "TRUE = this order needs further examination",
	`Notes` MEDIUMTEXT DEFAULT NULL COMMENT "human-added notes about the hold event",		`Notes` MEDIUMTEXT DEFAULT NULL COMMENT "human-added notes about the hold event",
	PRIMARY KEY(`ID`)		PRIMARY KEY(`ID_Event`)
	)		)
	ENGINE = InnoDB;</mysql>		ENGINE = InnoDB;</mysql>

Woozle: Woozle moved page VbzCart/tables/event vc ord change to VbzCart/tables/event vc ord hold: see in-page history

2017-06-02T10:35:20Z

Woozle moved page VbzCart/tables/event vc ord change to VbzCart/tables/event vc ord hold: see in-page history

← Older revision	Revision as of 10:35, 2 June 2017
(No difference)

Woozle: table redesign pass 1 complete; about to rename again

2017-06-02T10:34:48Z

table redesign pass 1 complete; about to rename again

← Older revision		Revision as of 10:34, 2 June 2017
Line 1:		Line 1:
	==About==		==About==
	* '''Purpose''': EventPlex extension for tracking events (usually or always manually-invoked) which change the status of an order		* '''Purpose''': EventPlex extension for tracking events (usually or always manually-invoked) which change the status of an order
	* '''Related''': {{l/vbzcart/table\|~~ord_change_type~~}}		* '''Related''': {{l/vbzcart/table\|orders}}, {{l/vbzcart/table\|ord_hold_type}}
			==Rules==
			This is a bit complicated, but not messy.

			* A '''hold event''' is where a hold-type is '''invoked''' or '''released'''.
			* Each '''hold event record''' indicates which type of hold is applicable and whether it was set ("hold invoke event") or released ("hold release event"), and also keeps track of the current hold-state for the order. This provides a log of the order's hold-state over time as well as a quick lookup of the current hold-state so we don't also have to store it in the order record.
			* If a hold-release event results in no flags being set, then the order's ID_Hold field can be set to NULL; otherwise it should always point to the most recent hold event record.
	==History==		==History==
	* '''2008-12-27''' Extracted from main "tables" page, but no documentation yet		* '''2008-12-27''' Extracted from main "tables" page, but no documentation yet
	* '''{{l/sub\|2009}}''' Summary: Added '''isActive''' but then replaced it with '''do*''' fields		* '''{{l/sub\|2009}}''' Summary: Added '''isActive''' but then replaced it with '''do*''' fields
	* '''2017-06-01''' Renamed from {{l/vbzcart/table\|ord_change}} to {{l/vbzcart/table\|event_vc_ord_change}}; redesigning as EventPlex extension. Will need to import {{l/vbzcart/table\|ord_pull}} data, if possible.		* '''2017-06-01''' Renamed from {{l/vbzcart/table\|ord_change}} to {{l/vbzcart/table\|event_vc_ord_change}}; redesigning as EventPlex extension. Will need to import {{l/vbzcart/table\|ord_pull}} data, if possible.
			* '''2017-06-02''' Renaming from {{l/vbzcart/table\|event_vc_ord_change}} to {{l/vbzcart/table\|event_vc_ord_hold}}
			** I decided "change" was too general, and could be about changing information in the order, or order events like packaging... but instead of "pull" let's call it a "hold", for consistency with field names and to avoid conflict with old "pull" tables/naming. Also, a "hold" is different from a "pull" in that an order can have multiple active "holds" but only one active "pull".
			** Finally figured out that a release is a separate event from an invoke, and adjusted table design accordingly:
			*** '''isRelease''' field
			*** No need for separate NotesPull/NotesFree fields as in ord_pull, nor a WhenFreed timestamp.
			** Made the Notes field larger.
			** Oh hey, this is still MYISAM... Changed to InnoDB.
			** Wrote out as clearly as possible how this is supposed to work, since it basically took me 2-3 hours to work back around to what I had apparently intended earlier (2009?) and explained in at least one place (but not prominently enough for me to notice it until I had almost worked the same thing out again).
	==Fields==		==Fields==
	* The '''do*''' ~~tristate-~~flag fields (formerly '''isActive''') represent the state of the order after this event, as determined by taking the ~~order's~~ previous ~~flags~~ and applying the event type~~'s flags~~. This provides a record of the order's actual state over time, negating the need to follow the event history from the beginning in order to ~~find~~ the order's state at any given time.		* The '''do*''' flag fields (formerly '''isActive''') represent the ''state of the order after this event'', as determined by taking the flags from the previous hold-event and applying the flags belonging to the event-type for this hold-event. This provides a record of the order's actual state over time, negating the need to follow the event history from the beginning in order to determine the order's state at any given time.
	* '''ID_Type''' -> {{l/vbzcart/table\|~~ord_change_type~~}}.ID		* '''ID_Type''' -> {{l/vbzcart/table\|ord_hold_type}}.ID
	* '''VbzUser''' is the user's wiki username, and only applies to events initiated through the wiki user interface
	* '''Machine''' hasn't been rigorously defined yet; it just needs to be some way we can tell what computer was being used (and it does not need to be authenticated; authentication records should be kept elsewhere). Ideally, it should be netname@[ip address], but various coding environments may not support both of those.
	==SQL==		==SQL==
	<mysql>CREATE TABLE `~~event_vc_ord_change~~` (		<mysql>CREATE TABLE `event_vc_ord_hold` (
	`ID` INT NOT NULL AUTO_INCREMENT,		`ID` INT NOT NULL AUTO_INCREMENT,
	`~~ID_Ord~~` INT NOT NULL COMMENT "~~core_orders~~.ID",		`ID_Order` INT NOT NULL COMMENT "orders.ID",
	`ID_Type` INT NOT NULL COMMENT "~~ord_event_type~~.ID",		`ID_Type` INT NOT NULL COMMENT "ord_hold_type.ID",
			`isRelease` BOOL(1) NOT NULL COMMENT "TRUE = this is a release, not an invoke",
	`doHoldRstk` TINYINT(1) DEFAULT NULL COMMENT "TRUE = do not base restock request items on this order",		`doHoldRstk` TINYINT(1) DEFAULT NULL COMMENT "TRUE = do not base restock request items on this order",
	`doHoldChrg` TINYINT(1) DEFAULT NULL COMMENT "TRUE = do not charge bank card for this order",		`doHoldChrg` TINYINT(1) DEFAULT NULL COMMENT "TRUE = do not charge bank card for this order",
	`doContact` TINYINT(1) DEFAULT NULL COMMENT "TRUE = customer needs to be contacted about this order",		`doContact` TINYINT(1) DEFAULT NULL COMMENT "TRUE = customer needs to be contacted about this order",
	`doExamine` TINYINT(1) DEFAULT NULL COMMENT "TRUE = this order needs further examination",		`doExamine` TINYINT(1) DEFAULT NULL COMMENT "TRUE = this order needs further examination",
	`~~WhenDone~~` ~~DATETIME COMMENT "when the event happened",~~		`Notes` MEDIUMTEXT DEFAULT NULL COMMENT "human-added notes about the hold event",
	~~`VbzUser` VARCHAR(127) COMMENT "VbzCart username of whoever initiated the event, if available",~~
	~~`SysUser` VARCHAR(127) COMMENT "who logged into the operating system, if available",~~
	~~`Machine` VARCHAR(63) COMMENT "network name or IP address of client",~~
	~~`Notes` VARCHAR(255)~~ COMMENT "human-~~entered~~ notes~~, if needed~~",
	PRIMARY KEY(`ID`)		PRIMARY KEY(`ID`)
	)		)
	ENGINE = ~~MYISAM~~;</mysql>		ENGINE = InnoDB;</mysql>

Woozle: a little post-move tidying; redesign yet to be done

2017-06-01T10:49:14Z

a little post-move tidying; redesign yet to be done

← Older revision		Revision as of 10:49, 1 June 2017
Line 1:		Line 1:
	==About==		==About==
	'''Purpose''': for tracking events (usually or always manually-invoked) which change the status of an order		* '''Purpose''': EventPlex extension for tracking events (usually or always manually-invoked) which change the status of an order
	~~===backstory===~~		* '''Related''': {{l/vbzcart/table\|ord_change_type}}
	~~I apparently designed this and its "types" table ({{vbzcart\|table\|ord_change_type}}) sometime in 2008, but didn~~'~~t document them; a note on the~~ {{vbzcart\|table\|ord_change_type}} ~~page dated 2008-12-27 says "Are we actually using this, or is it part of the future online ordering system redesign?"~~

	~~As of 2009-07, though, it has become clear that a general order log seems necessary for the following reasons:~~
	* To replace the {{vbzcart\|table\|ord_pull}} table
	* To make it unnecessary to track user details inside other order-related records
	* To keep an automatic record of all changes made to an order and any significant processing events

	~~The system implemented here of defining event types which may or may not block certain things seems compatible with this goal, and we mainly just needed to add fields for user-tracking.~~
	==History==		==History==
	* '''2008-12-27''' Extracted from main "tables" page, but no documentation yet		* '''2008-12-27''' Extracted from main "tables" page, but no documentation yet
	* '''~~2009-07-12'''~~		* '''{{l/sub\|2009}}''' Summary: Added '''isActive''' but then replaced it with '''do*''' fields
	** Preliminary documentation		* '''2017-06-01''' Renamed from {{l/vbzcart/table\|ord_change}} to {{l/vbzcart/table\|event_vc_ord_change}}; redesigning as EventPlex extension. Will need to import {{l/vbzcart/table\|ord_pull}} data, if possible.
	** Added '''isActive''' field (was in {{~~vbzcart~~\|~~table\|ord_change_type~~}}~~, didn~~'~~t belong there)~~
	** Added ''~~'VbzUser''' and '''Machine''' fields~~
	** Renamed to singular form
	* '''2009-10-18'''
	** Replaced '''isActive''' ~~field~~ with '''do*''' fields
	** Added '''~~SysUser~~'''~~, for consistency with other event log tables~~
	** Renamed from ~~'''ord_event'''~~ to ~~'''ord_change'''~~; ~~using '''~~{{vbzcart\|table\|~~ord_event~~}}~~''' for stateless/internal events~~
	==Fields==		==Fields==
	* ~~<s>'''isActive''' represents</s>~~ The '''do*''' tristate-flag fields represent the state of the order after this event, as determined by taking the order's previous flags and applying the event type's flags. This provides a record of the order's actual state over time, negating the need to follow the event history from the beginning in order to find the order's state at any given time.		* The '''do*''' tristate-flag fields (formerly '''isActive''') represent the state of the order after this event, as determined by taking the order's previous flags and applying the event type's flags. This provides a record of the order's actual state over time, negating the need to follow the event history from the beginning in order to find the order's state at any given time.
			* '''ID_Type''' -> {{l/vbzcart/table\|ord_change_type}}.ID
	* '''VbzUser''' is the user's wiki username, and only applies to events initiated through the wiki user interface		* '''VbzUser''' is the user's wiki username, and only applies to events initiated through the wiki user interface
	* '''Machine''' hasn't been rigorously defined yet; it just needs to be some way we can tell what computer was being used (and it does not need to be authenticated; authentication records should be kept elsewhere). Ideally, it should be netname@[ip address], but various coding environments may not support both of those.		* '''Machine''' hasn't been rigorously defined yet; it just needs to be some way we can tell what computer was being used (and it does not need to be authenticated; authentication records should be kept elsewhere). Ideally, it should be netname@[ip address], but various coding environments may not support both of those.
	==SQL==		==SQL==
	<mysql>CREATE TABLE `~~ord_change~~` (		<mysql>CREATE TABLE `event_vc_ord_change` (
	`ID` INT NOT NULL AUTO_INCREMENT,		`ID` INT NOT NULL AUTO_INCREMENT,
	`ID_Ord` INT NOT NULL COMMENT "core_orders.ID",		`ID_Ord` INT NOT NULL COMMENT "core_orders.ID",

Woozle: Woozle moved page VbzCart/tables/ord change to VbzCart/tables/event vc ord change: adapting for EventPlex

2017-06-01T10:18:03Z

Woozle moved page VbzCart/tables/ord change to VbzCart/tables/event vc ord change: adapting for EventPlex

← Older revision	Revision as of 10:18, 1 June 2017
(No difference)

Woozle: tidying before rename/redesign/repurpose

2017-06-01T10:10:41Z

tidying before rename/redesign/repurpose

@@ Line 1: / Line 1: @@
 ==About==
-* '''Purpose''': for tracking events which change the status of an order, usually (always?) invoked manually
+'''Purpose''': for tracking events (usually or always manually-invoked) which change the status of an order
 ===backstory===
 I apparently designed this and its "types" table ({{vbzcart|table|ord_change_type}}) sometime in 2008, but didn't document them; a note on the {{vbzcart|table|ord_change_type}} page dated 2008-12-27 says "Are we actually using this, or is it part of the future online ordering system redesign?"
@@ Line 25: / Line 10: @@
 The system implemented here of defining event types which may or may not block certain things seems compatible with this goal, and we mainly just needed to add fields for user-tracking.
 ==SQL==
-<section begin=sql /><mysql>CREATE TABLE `ord_change` (
+<mysql>CREATE TABLE `ord_change` (
    `ID`             INT        NOT NULL AUTO_INCREMENT,
    `ID_Ord`         INT        NOT NULL COMMENT "core_orders.ID",
@@ Line 42: / Line 42: @@
+)
 ENGINE = MYISAM;</mysql>

Woozle: clarification/update of VbzUser

2009-10-18T18:55:08Z

clarification/update of VbzUser

← Older revision		Revision as of 18:55, 18 October 2009
Line 14:		Line 14:
	* '''Fields''':		* '''Fields''':
	** <s>'''isActive''' represents</s> The '''do*''' tristate-flag fields represent the state of the order after this event, as determined by taking the order's previous flags and applying the event type's flags. This provides a record of the order's actual state over time, negating the need to follow the event history from the beginning in order to find the order's state at any given time.		** <s>'''isActive''' represents</s> The '''do*''' tristate-flag fields represent the state of the order after this event, as determined by taking the order's previous flags and applying the event type's flags. This provides a record of the order's actual state over time, negating the need to follow the event history from the beginning in order to find the order's state at any given time.
	** '''VbzUser''' ~~will probably just be~~ the username ~~from the wiki~~, ~~if we will be using the wiki to manage user log-ins~~ and ~~provide access to the ordering system. Not sure how~~ to ~~let wiki authentication work for vbzcart code, unless we move~~ the wiki ~~to the same domain instead of its own subdomain (...or actually have the wiki present vbzcart pages, eventually?).~~		** '''VbzUser''' is the user's wiki username, and only applies to events initiated through the wiki user interface
	** '''Machine''' hasn't been rigorously defined yet; it just needs to be some way we can tell what computer was being used (and it does not need to be authenticated; authentication records should be kept elsewhere). Ideally, it should be netname@[ip address], but various coding environments may not support both of those.		** '''Machine''' hasn't been rigorously defined yet; it just needs to be some way we can tell what computer was being used (and it does not need to be authenticated; authentication records should be kept elsewhere). Ideally, it should be netname@[ip address], but various coding environments may not support both of those.
	===backstory===		===backstory===

Woozle: post-move cleanup/updates

2009-10-18T17:56:19Z

post-move cleanup/updates

← Older revision		Revision as of 17:56, 18 October 2009
Line 1:		Line 1:
	==About==		==About==
	* '''Purpose''': for tracking ~~all order-related~~ events~~, especially those affecting~~ the order~~'s status~~		* '''Purpose''': for tracking events which change the status of an order, usually (always?) invoked manually
	* '''History''':		* '''History''':
	** '''2008-12-27''' Extracted from main "tables" page, but no documentation yet		** '''2008-12-27''' Extracted from main "tables" page, but no documentation yet
	** '''2009-07-12'''		** '''2009-07-12'''
	*** Preliminary documentation		*** Preliminary documentation
	*** Added '''isActive''' field (was in {{vbzcart\|table\|~~ord_event_type~~}}, didn't belong there)		*** Added '''isActive''' field (was in {{vbzcart\|table\|ord_change_type}}, didn't belong there)
	*** Added '''VbzUser''' and '''Machine''' fields		*** Added '''VbzUser''' and '''Machine''' fields
	*** Renamed to singular form		*** Renamed to singular form
Line 11:		Line 11:
	*** Replaced '''isActive''' field with '''do*''' fields		*** Replaced '''isActive''' field with '''do*''' fields
	*** Added '''SysUser''', for consistency with other event log tables		*** Added '''SysUser''', for consistency with other event log tables
			*** Renamed from '''ord_event''' to '''ord_change'''; using '''{{vbzcart\|table\|ord_event}}''' for stateless/internal events
	* '''Fields''':		* '''Fields''':
	** <s>'''isActive''' represents</s> The '''do*''' tristate-flag fields represent the state of the order after this event, as determined by taking the order's previous flags and applying the event type's flags. This provides a record of the order's actual state over time, negating the need to follow the event history from the beginning in order to find the order's state at any given time.		** <s>'''isActive''' represents</s> The '''do*''' tristate-flag fields represent the state of the order after this event, as determined by taking the order's previous flags and applying the event type's flags. This provides a record of the order's actual state over time, negating the need to follow the event history from the beginning in order to find the order's state at any given time.
Line 16:		Line 17:
	** '''Machine''' hasn't been rigorously defined yet; it just needs to be some way we can tell what computer was being used (and it does not need to be authenticated; authentication records should be kept elsewhere). Ideally, it should be netname@[ip address], but various coding environments may not support both of those.		** '''Machine''' hasn't been rigorously defined yet; it just needs to be some way we can tell what computer was being used (and it does not need to be authenticated; authentication records should be kept elsewhere). Ideally, it should be netname@[ip address], but various coding environments may not support both of those.
	===backstory===		===backstory===
	I apparently designed this and its "types" table ({{vbzcart\|table\|~~ord_event_type~~}}) sometime in 2008, but didn't document them; a note on the {{vbzcart\|table\|~~ord_event_type~~}} page dated 2008-12-27 says "Are we actually using this, or is it part of the future online ordering system redesign?"		I apparently designed this and its "types" table ({{vbzcart\|table\|ord_change_type}}) sometime in 2008, but didn't document them; a note on the {{vbzcart\|table\|ord_change_type}} page dated 2008-12-27 says "Are we actually using this, or is it part of the future online ordering system redesign?"

	As of 2009-07, though, it has become clear that a general order log seems necessary for the following reasons:		As of 2009-07, though, it has become clear that a general order log seems necessary for the following reasons:
Line 25:		Line 26:
	The system implemented here of defining event types which may or may not block certain things seems compatible with this goal, and we mainly just needed to add fields for user-tracking.		The system implemented here of defining event types which may or may not block certain things seems compatible with this goal, and we mainly just needed to add fields for user-tracking.
	==SQL==		==SQL==
	<section begin=sql /><mysql>CREATE TABLE `~~ord_event~~` (		<section begin=sql /><mysql>CREATE TABLE `ord_change` (
	`ID` INT NOT NULL AUTO_INCREMENT,		`ID` INT NOT NULL AUTO_INCREMENT,
	`ID_Ord` INT NOT NULL COMMENT "core_orders.ID",		`ID_Ord` INT NOT NULL COMMENT "core_orders.ID",

← Older revision		Revision as of 12:12, 3 June 2017
Line 25:		Line 25:
	==SQL==		==SQL==
	<mysql>CREATE TABLE `event_vc_ord_hold` (		<mysql>CREATE TABLE `event_vc_ord_hold` (
	`ID_Event` INT NOT NULL AUTO_INCREMENT,		`ID_Event` INT NOT NULL AUTO_INCREMENT,
	`ID_Order` INT NOT NULL COMMENT "orders.ID",		`ID_Order` INT NOT NULL COMMENT "orders.ID",
	`ID_Type` INT NOT NULL COMMENT "ord_hold_type.ID",		`ID_Type` INT NOT NULL COMMENT "ord_hold_type.ID",
	`isRelease` BOOL~~(1)~~ NOT NULL COMMENT "TRUE = this is a release, not an invoke",		`isRelease` BOOL NOT NULL COMMENT "TRUE = this is a release, not an invoke",
	`doHoldRstk` TINYINT(1) DEFAULT NULL COMMENT "TRUE = do not base restock request items on this order",		`doHoldRstk` TINYINT(1) DEFAULT NULL COMMENT "TRUE = do not base restock request items on this order",
	`doHoldChrg` TINYINT(1) DEFAULT NULL COMMENT "TRUE = do not charge bank card for this order",		`doHoldChrg` TINYINT(1) DEFAULT NULL COMMENT "TRUE = do not charge bank card for this order",
	`doContact` TINYINT(1) DEFAULT NULL COMMENT "TRUE = customer needs to be contacted about this order",		`doContact` TINYINT(1) DEFAULT NULL COMMENT "TRUE = customer needs to be contacted about this order",
	`doExamine` TINYINT(1) DEFAULT NULL COMMENT "TRUE = this order needs further examination",		`doExamine` TINYINT(1) DEFAULT NULL COMMENT "TRUE = this order needs further examination",
	`Notes` MEDIUMTEXT DEFAULT NULL COMMENT "human-added notes about the hold event",		`Notes` MEDIUMTEXT DEFAULT NULL COMMENT "human-added notes about the hold event",
	PRIMARY KEY(`ID_Event`)		PRIMARY KEY(`ID_Event`)
	)		)
	ENGINE = InnoDB;</mysql>		ENGINE = InnoDB;</mysql>