Izara Wiki - Recent changes [en]

Per Service Schemas

Sven the Barbarian — Tue, 25 Aug 2026 14:07:23 GMT

@@ Line 475: / Line 475: @@
 </syntaxhighlight>
-= Generated S3 files =
+= Error Schema =
 * generate multiple files for different uses, eg:

Standard Data Structures

Sven the Barbarian — Tue, 25 Aug 2026 14:04:07 GMT

← Older revision		Revision as of 14:04, 25 August 2026
Line 302:		Line 302:
	* identifiers: contains identifiers data		* identifiers: contains identifiers data
	* fields: another data except		* fields: another data except

			== errorType ==

			<syntaxhighlight lang="JavaScript">
			{
			serviceTag: "xxx",
			errorTag: "yyy"
			}
			</syntaxhighlight>

	== example data ==		== example data ==

User Data Handling

Sven the Barbarian — Tue, 25 Aug 2026 13:49:32 GMT

← Older revision		Revision as of 13:49, 25 August 2026
Line 55:		Line 55:
	== Object level Account Limits ==		== Object level Account Limits ==

	== Add increase/decrease ~~action~~ =		== Generating code ==

			* Can generate AccountLimit tags automatically for each flow
			* if flow objType has belongTo or rbac addOnDataStructure always check AccountLimit, eg createOrder number of orders allowed to create
			* some flows accept multiple objType, eg createObject, if only generated flows are like this then we could hardcode request to AccountLimit from objType param, but if developer made flows also are like this we could add a setting to the flow, eg: multipleObjTypes = true, if true then could standardize param name and generate request to AccountLimit
			* if flow is event S3 can generate AccountLimit request for size of file

			== Add increase/decrease effect ==

	* currently account limits will find the highest limit of all roles attached to a customer		* currently account limits will find the highest limit of all roles attached to a customer

Per Service Schemas

Seagame — Tue, 25 Aug 2026 02:44:14 GMT

ObjectSchema | ObjectFieldSchema.js

← Older revision		Revision as of 02:44, 25 August 2026
(One intermediate revision by the same user not shown)
Line 62:		Line 62:
	},		},
	{		{
	type:"rbac"		type:"rbac",
			billalble:true // true \|\| false , required
	},		},
	// ...		// ...

User Data Handling

Sven the Barbarian — Sun, 23 Aug 2026 10:24:31 GMT

Show changes

Per Service Schemas

Sven the Barbarian — Sun, 23 Aug 2026 09:54:16 GMT

← Older revision		Revision as of 09:54, 23 August 2026
Line 24:		Line 24:
	// systemGenerated must be created by flow/s		// systemGenerated must be created by flow/s
	// searchResultGenerated see separate notes below		// searchResultGenerated see separate notes below
	generatedBy: "~~userGenerated~~" \|\| "~~systemGenerated~~" \|\| "systemNoUserId" \|\| "systemWithUserId" \|\| "searchResultGenerated" // required		generatedBy: "xx", // "user"\|"systemNoUserId"\|"systemWithUserId"\|"searchResultGenerated" // required
	searchResultGeneratedFlowType: {}, // for generatedBy = searchResultGenerated		searchResultGeneratedFlowType: {}, // for generatedBy = searchResultGenerated
	addOnDataStructure: [ // optional, add for additional setting to objectType		addOnDataStructure: [ // optional, add for additional setting to objectType
Line 195:		Line 195:
	{		{
	"xxx": { // relationshipTag - name of relationship type stored in graph		"xxx": { // relationshipTag - name of relationship type stored in graph
	generatedBy: "~~userGenerated~~" \|\| "~~systemGenerated~~" \|\| "systemNoUserId" \|\| "systemWithUserId~~" // default="userGenerated~~"		generatedBy: "xx", // "user"\|"systemNoUserId"\|"systemWithUserId"
	canChangeToRelTypes: [		canChangeToRelTypes: [
	{		{
Line 202:		Line 202:
	relationshipTag: "yyy"		relationshipTag: "yyy"
	},		},
	changeBy: "~~user~~" // "~~systemNoUserId~~" \| "~~systemWithUserId~~" \| "~~user", default="user~~"		changeBy: "xx", // "user"\|"systemNoUserId"\|"systemWithUserId"
	}		}
	// another relType		// another relType
Line 225:		Line 225:
	requiredOnCreate: false, // default=false		requiredOnCreate: false, // default=false
	optionalOnCreate: false, // default = false		optionalOnCreate: false, // default = false
	updateBy: "~~user~~" // "~~systemNoUserId~~" \| "~~systemWithUserId~~" \| "~~user~~" \| "none~~", default="user~~"		updateBy: "xx", // "user"\|"systemNoUserId"\|"systemWithUserId"\|"none"
	validation: {} // ajv syntax		validation: {} // ajv syntax
	},		},
Line 241:		Line 241:
	requiredOnCreate: true, // if set true will create relationshipTag when create objType data, if both "from" and "to" linkType="many" should not have requiredOnCreate, exists in "from" or "to" only		requiredOnCreate: true, // if set true will create relationshipTag when create objType data, if both "from" and "to" linkType="many" should not have requiredOnCreate, exists in "from" or "to" only
	linkType: "", // one \| many		linkType: "", // one \| many
	// moveBy: "~~none~~", // "~~systemNoUserId~~" \| "~~systemWithUserId~~" \| "~~user~~" \| ~~"none", default=~~"none"		// moveBy: "xx", // "user"\|"systemNoUserId"\|"systemWithUserId"\|"none"
	// belongTo:true		// belongTo:true
	},		},
Line 251:		Line 251:
	linkType: "", // one \| many		linkType: "", // one \| many
	// moveBy allows the relationship to be moved between 2 instances of the same objType only		// moveBy allows the relationship to be moved between 2 instances of the same objType only
	moveBy: "~~none~~", // "~~systemNoUserId~~" \| "~~systemWithUserId~~" \| "~~user~~" \| ~~"none", default=~~"none"		moveBy: "xx", // "user"\|"systemNoUserId"\|"systemWithUserId"\|"none"
	belongTo:true, // false		belongTo:true, // false
	},		},
Line 295:		Line 295:
	{		{
	flowTag: "yyy",		flowTag: "yyy",
	initiateBy: "~~user~~", // "user" \| "~~system~~" ~~-- if receive plugin should be user~~		initiateBy: "xx", // "user"\|"systemNoUserId"\|"systemWithUserId"
	handleObj: "one", // "one" \| "multi"		handleObj: "one", // "one" \| "multi"
	statusType: "statusField", // "statusField" \| "storedCache" \| "none" \| "triggerCache"		statusType: "statusField", // "statusField" \| "storedCache" \| "none" \| "triggerCache"

Design concepts

Sven the Barbarian — Sun, 23 Aug 2026 05:43:49 GMT

← Older revision		Revision as of 05:43, 23 August 2026
Line 35:		Line 35:
	* [[Development environment]]		* [[Development environment]]
	* [[Test environment overview]]		* [[Test environment overview]]
	* [[Local test environment]]
	* [[Using Postman]]		* [[Using Postman]]
	* [[Git development]]		* [[Git development]]
Line 50:		Line 49:
	* [[Per Service Schemas]]		* [[Per Service Schemas]]
	* [[Standard Data Structures]]		* [[Standard Data Structures]]
	* [[Standard Config Table Per Service]]
	* [[User Data Handling]]		* [[User Data Handling]]
	*: (maybe removing)
	* [[Standard LogicalResults Per Service]]		* [[Standard LogicalResults Per Service]]
	* [[Standard FindData Per Service]]		* [[Standard FindData Per Service]]
Line 59:		Line 56:
	* [[Standard WebSocketTask Per Service]]		* [[Standard WebSocketTask Per Service]]
	* [[Error Handling Multi Thread Processing]]		* [[Error Handling Multi Thread Processing]]
	* [[Multi Thread Invocation]]
	* [[Copying large Dynamo data from to another service table]]		* [[Copying large Dynamo data from to another service table]]

2022-11-09 - Multi Thread Invocation

Sven the Barbarian — Sun, 23 Aug 2026 05:43:03 GMT

← Older revision		Revision as of 05:43, 23 August 2026
(One intermediate revision by the same user not shown)
(No difference)

Multi Thread Invocation

Sven the Barbarian — Sun, 23 Aug 2026 05:41:52 GMT

Sven the Barbarian moved page Multi Thread Invocation to 2022-11-09 - Multi Thread Invocation

← Older revision		Revision as of 05:41, 23 August 2026
(One intermediate revision by the same user not shown)
Line 27:		Line 27:
	* Initial calling function saves AwaitingMultipleSteps for each thread		* Initial calling function saves AwaitingMultipleSteps for each thread
	* as each thread detects there are no remaining pages to process it clears it's AwaitingMultipleStep and checks if any awaiting steps remain, if not it continues the work flow		* as each thread detects there are no remaining pages to process it clears it's AwaitingMultipleStep and checks if any awaiting steps remain, if not it continues the work flow

			[[Category:Working documents\| 2022-11-09]]

Remote repository and workspace structure

Sven the Barbarian — Sun, 23 Aug 2026 05:34:33 GMT

← Older revision		Revision as of 05:34, 23 August 2026
Line 1:		Line 1:
	= Repository Design =		= Repository Design (Forgejo) =
	* One ~~workspace~~ per stack		* One organization per stack
	* If all repositories grouped together only need one project, same name as workspace
	* If have areas within stack
	* web service = one final project, eg: Izara Market

	= ~~Workspaces~~ =		= Core Stacks =

	== Izara Core - Libraries ==		== Izara Core - Libraries ==
Line 29:		Line 26:

	= Developers =		= Developers =
	* When working on a ~~workspace,~~ developer creates a ~~workspace~~ with the same name ~~suffixed with their name in brackets~~		* When working on a repository developer creates a fork with the same name suffixed with their name in brackets
	* That developer forks the repositories they are working on into this workspace, name of repository suffixed with their name in brackets		* If multiple developers working on the same repositories, only one person forks and names that repository, others fork/PR or push to developers fork
	* If multiple developers working on the same repositories, only one person forks and names that repository
	* name suffix of repositories will match the workspace forked into
	* copy the names of workspace/project/~~repository from originals, only adding name suffix in brackets~~

	~~= User Access =~~
	* Bitbuckets 5 developer limit is per workspace
	* by splitting into many workspaces we can more easily apply access to ~~people working on that code~~
	* always create User Groups for each workspace and apply to repositories (can apply as default access), so can easily adjust who has access

Test environment overview

Sven the Barbarian — Sun, 23 Aug 2026 05:30:26 GMT

← Older revision		Revision as of 05:30, 23 August 2026
Line 1:		Line 1:
	= Test environments =		= Test environments =

			* Old notes, now primarily use AI to check local developer code without mock AWS resources, [[Service - Integration Testing]] in AWS test environment, non-destructive tests in production environment could be implemented in the future

	There are three test environments to plan for:		There are three test environments to plan for:

Local test environment

Sven the Barbarian — Sun, 23 Aug 2026 05:26:46 GMT

← Older revision		Revision as of 05:26, 23 August 2026
Line 1:		Line 1:
	= Overview =		= Overview =

			* No longer used *

	Each repository is a micro-service that performs has responsibility for one part of the {{ProjectNameLong}}, although each is meant to be used as part of a network of interconnected micro-services when a single repository is cloned the first level of testing is at the self contained local level.		Each repository is a micro-service that performs has responsibility for one part of the {{ProjectNameLong}}, although each is meant to be used as part of a network of interconnected micro-services when a single repository is cloned the first level of testing is at the self contained local level.

Per Service Schemas

Seagame — Wed, 19 Aug 2026 07:11:54 GMT

← Older revision		Revision as of 07:11, 19 August 2026
Line 24:		Line 24:
	// systemGenerated must be created by flow/s		// systemGenerated must be created by flow/s
	// searchResultGenerated see separate notes below		// searchResultGenerated see separate notes below
	generatedBy: "userGenerated" \|\| "systemGenerated" \|\| "searchResultGenerated" // required		generatedBy: "userGenerated" \|\| "systemGenerated" \|\| "systemNoUserId" \|\| "systemWithUserId" \|\| "searchResultGenerated" // required
	searchResultGeneratedFlowType: {}, // for generatedBy = searchResultGenerated		searchResultGeneratedFlowType: {}, // for generatedBy = searchResultGenerated
	addOnDataStructure: [ // optional, add for additional setting to objectType		addOnDataStructure: [ // optional, add for additional setting to objectType
Line 195:		Line 195:
	{		{
	"xxx": { // relationshipTag - name of relationship type stored in graph		"xxx": { // relationshipTag - name of relationship type stored in graph
	generatedBy: "userGenerated" \|\| "systemGenerated" // default="userGenerated"		generatedBy: "userGenerated" \|\| "systemGenerated" \|\| "systemNoUserId" \|\| "systemWithUserId" // default="userGenerated"
	canChangeToRelTypes: [		canChangeToRelTypes: [
	{		{

2026-08-18 - Backend User and RBAC Data

Seagame — Wed, 19 Aug 2026 02:23:57 GMT

updated idea

← Older revision		Revision as of 02:23, 19 August 2026
(One intermediate revision by the same user not shown)
Line 7:		Line 7:
	= updated idea =		= updated idea =

	* baseUserId can stay in ~~iz_Context~~ because it should not change during processing		* baseUserId can stay in _izContext because it should not change during processing
	* maybe change baseUserId to submittedByUserId to be more clear, but see baseUserId reason for name below		* maybe change baseUserId to submittedByUserId to be more clear, but see baseUserId reason for name below
	* however consider if future flows will handle many submittedByUserIds, eg automated tasks that handle many submitted tasks, if that is common it might be better to allow generated code to pass the submittedByUserId as a flow input param		* however consider if future flows will handle many submittedByUserIds, eg automated tasks that handle many submitted tasks, if that is common it might be better to allow generated code to pass the submittedByUserId as a flow input param
Line 45:		Line 45:
	* using schemas and generated code		* using schemas and generated code
	* RBAC moved out of authorizers and implemented inside handler lambdas		* RBAC moved out of authorizers and implemented inside handler lambdas
	* still in ~~iz_Context~~		* still in _izContext
	* variable name is baseUserId, because accountLimits/resourceUse are connected to target userId if belong to User, but baseUserId if not		* variable name is baseUserId, because accountLimits/resourceUse are connected to target userId if belong to User, but baseUserId if not

Line 51:		Line 51:

	* targetId is a concat string for composite identifiers, want all handling of identifiers to be an object, only change to concat when required (eg save to database that requires single string)		* targetId is a concat string for composite identifiers, want all handling of identifiers to be an object, only change to concat when required (eg save to database that requires single string)
	* some flows might need to adjust target according to steps, eg importBatch submission belongTo user but each pending element may have different belongTo objType/instances, this complicates targetId management in ~~iz_Context~~		* some flows might need to adjust target according to steps, eg importBatch submission belongTo user but each pending element may have different belongTo objType/instances, this complicates targetId management in _izContext

	[[Category:Working_documents - User Data Handling\| 2026-08-18]]		[[Category:Working_documents - User Data Handling\| 2026-08-18]]
	[[Category:Working documents\| 2026-08-18]]		[[Category:Working documents\| 2026-08-18]]

2026-08-18 - Plug In Service between SupplyChian and VideoFeed

Sven the Barbarian — Tue, 18 Aug 2026 15:51:05 GMT

Created page with "= Overview = Move connection between monitor service and eg IzaraVideoFeed into a plugIn service = notes = * move monitor links (location/transformUnits/StageAdjust) to plugin * maybe not need monitor services anymore in SupplyChain, plugins create and configure the links, SupplyChain focuses on changes to units * location/transformUnits/StageAdjust links in plugin have properties that can in the future be used to create history video of a unit (eg high quality or spe..."

New page

= Overview =

Move connection between monitor service and eg IzaraVideoFeed into a plugIn service

= notes =

* move monitor links (location/transformUnits/StageAdjust) to plugin
* maybe not need monitor services anymore in SupplyChain, plugins create and configure the links, SupplyChain focuses on changes to units
* location/transformUnits/StageAdjust links in plugin have properties that can in the future be used to create history video of a unit (eg high quality or speed up video during markers)
* maybe not have a database entry for each transform/adjust, instead have per config (transformConfigId/stageAdjustmentId) links to videoFeed(s?) - videoFeeds maybe validate are children of location's monitorIzaraVideoFeedGroup, but perhaps not need this so user has more freedom
- if user changes the transformConfigId/stageAdjustmentId > videoFeed link old links will no longer work, warn that they should create a new transform/stageAdjust if they want to keep history

= old notes =

* location points to monitorIzaraVideoFeedGroup (need to change on wiki) object which is one set of videoFeeds in an Operation, eg a warehouse with many videoFeeds
* transform or stage points to a marker which is a string that is passed to the monitor service, for videoFeeds this can be a tag that we add to videoFeeds, specifying which feed/s are focused during that stage/transform
* maybe can add properties to feeds and tag a specific property name, or maybe handle in supVid plugin

[[Category:Working documents| 2026-08-18]]

Per Service Schemas

Sven the Barbarian — Tue, 18 Aug 2026 15:01:49 GMT

generatedCodeConfig removed, previously for eg Issue which would create a topic auto when making, but now use importBatch O>O

← Older revision		Revision as of 15:01, 18 August 2026
Line 323:		Line 323:
	}		}
	],		],

	~~// event="generatedCode" setting~~
	~~generatedCodeConfig: {~~
	~~generatedCodeTag: "create", // tag for generated code, eg "create" \| "update" \| "delete"~~
	~~codeHookTag: "xx", // which codeHook to initiate flow from~~
	~~// maybe validate: invocationType must exist in "event" array, so don't need to check 2 places when eg creating sns topic~~
	~~invocationType: "ownTopic", // "ownTopic" \| "lambdaSyncInv"~~

	~~objType: {}, // which cases in the generated code trigger the flow~~
	~~// .. other settings depending on generated code~~
	},

	outputTopic: boolean,		outputTopic: boolean,


	flowSteps: {		flowSteps: {

Service - Organization

Mint — Tue, 18 Aug 2026 03:45:58 GMT

organization

← Older revision		Revision as of 03:45, 18 August 2026
Line 16:		Line 16:
	objectType: "organization",		objectType: "organization",
	canDelete: false,		canDelete: false,
			generatedBy: "userGenerated",
	addOnDataStructure: [		addOnDataStructure: [
	{		{

Service - SupplyVideoFeed Location

Sven the Barbarian — Tue, 18 Aug 2026 02:48:51 GMT

← Older revision		Revision as of 02:48, 18 August 2026
Line 41:		Line 41:
	{		{
	type: "partitionKey",		type: "partitionKey",
	fieldNames: ["supplyNetworkId", "operationId"],		fieldNames: ["supplyNetworkId", "operationId", "supplyLocationId"],
	name: "~~supVidLinkId~~",		name: "supVidLinkSupLocId",
	},		},
	{		{
	type: "sortKey",		type: "sortKey",
	fieldName: "~~supplyLocationId~~"		fieldName: "feedGroupId"
	},		},
	]		]
	}		}
	</syntaxhighlight>		</syntaxhighlight>

			* one supplyLocationId can link to multiple feedGroupIds

	== Relationships ==		== Relationships ==

Service - SupplyVideoFeed Stage Adjustment

Sven the Barbarian — Tue, 18 Aug 2026 02:46:18 GMT

Created page with " = Overview = Links Stage Adjust objects to VideoFeed structures. = Repository = ... = Object Schemas = ; Additional Information: Per Service Schemas == supVidStageAdjustLink == <syntaxhighlight lang="JavaScript"> { objectType: "supVidStageAdjustLink", generatedBy: "userGenerated", canDelete: false, belongTo: { serviceTag: "SupplyVideoFeedLink", objectType: "supVidLinkBySupplyNetwork" }, addOnDataStructure: [], storageResources: { "dynamo": {..."

New page

= Overview =

Links Stage Adjust objects to VideoFeed structures.

= Repository =

...

= Object Schemas =
; Additional Information: [[Per Service Schemas]]

== supVidStageAdjustLink ==

<syntaxhighlight lang="JavaScript">
{
objectType: "supVidStageAdjustLink",
generatedBy: "userGenerated",
canDelete: false,
belongTo: {
serviceTag: "SupplyVideoFeedLink",
objectType: "supVidLinkBySupplyNetwork"
},
addOnDataStructure: [],
storageResources: {
"dynamo": {
"storageType": "dynamoDB",
"tableName": "supVidStageAdjustLink",
},
"myGraph": {
"storageType": "graph",
"graphServerTag": "GraphHandler"
}
},
fieldNames: {
// supplyNetworkId
// operationId
// stageAdjustmentId
// videoFeedId
},
identifiers: [
{
type: "partitionKey",
fieldNames: ["supplyNetworkId", "operationId", "stageAdjustmentId"],
name: "supVidLinkStagAdjId",
},
{
type: "sortKey",
fieldName: "videoFeedId"
},
]
}
</syntaxhighlight>

* one transformConfigId can link to multiple videoFeedIds

== Relationships ==

...

= flowSchemas =

...

= Working documents =

[[:Category:Working_documents - SupplyVideoFeed Stage Adjustment| SupplyVideoFeed Stage Adjustment]]

[[Category:Backend services| SupplyVideoFeed Stage Adjustment]]

Service - SupplyVideoFeed Transform Units

Sven the Barbarian — Tue, 18 Aug 2026 02:44:46 GMT

Created page with "= Overview = Links Transform Unit objects to VideoFeed structures. = Repository = ... = Object Schemas = ; Additional Information: Per Service Schemas == supVidTransformUnitLink == <syntaxhighlight lang="JavaScript"> { objectType: "supVidTransformUnitLink", generatedBy: "userGenerated", canDelete: false, belongTo: { serviceTag: "SupplyVideoFeedLink", objectType: "supVidLinkBySupplyNetwork" }, addOnDataStructure: [], storageResources: { "dynamo":..."

New page

= Overview =

Links Transform Unit objects to VideoFeed structures.

= Repository =

...

= Object Schemas =
; Additional Information: [[Per Service Schemas]]

== supVidTransformUnitLink ==

<syntaxhighlight lang="JavaScript">
{
objectType: "supVidTransformUnitLink",
generatedBy: "userGenerated",
canDelete: false,
belongTo: {
serviceTag: "SupplyVideoFeedLink",
objectType: "supVidLinkBySupplyNetwork"
},
addOnDataStructure: [],
storageResources: {
"dynamo": {
"storageType": "dynamoDB",
"tableName": "supVidTransformUnitLink",
},
"myGraph": {
"storageType": "graph",
"graphServerTag": "GraphHandler"
}
},
fieldNames: {
// supplyNetworkId
// operationId
// transformConfigId
// videoFeedId
},
identifiers: [
{
type: "partitionKey",
fieldNames: ["supplyNetworkId", "operationId", "transformConfigId"],
name: "supVidLinkTranConfId",
},
{
type: "sortKey",
fieldName: "videoFeedId"
},
]
}
</syntaxhighlight>

* one transformConfigId can link to multiple videoFeedIds

== Relationships ==

...

= flowSchemas =

...

= Working documents =

[[:Category:Working_documents - SupplyVideoFeed Transform Units| SupplyVideoFeed Transform Units]]

[[Category:Backend services| SupplyVideoFeed Transform Units]]

Service Stack - SupplyVideoFeed Markers

Sven the Barbarian — Tue, 18 Aug 2026 02:41:30 GMT

← Older revision		Revision as of 02:41, 18 August 2026
Line 8:		Line 8:

	* [[Service - SupplyVideoFeed Transform Units]]		* [[Service - SupplyVideoFeed Transform Units]]
			* [[Service - SupplyVideoFeed Stage Adjustment]]

	= Working documents =		= Working documents =

	[[:Category:Working_documents - Service Stack - SupplyVideoFeed Markers\| Service Stack - SupplyVideoFeed Markers]]		[[:Category:Working_documents - Service Stack - SupplyVideoFeed Markers\| Service Stack - SupplyVideoFeed Markers]]

Service Stack - SupplyVideoFeed Markers

Sven the Barbarian — Tue, 18 Aug 2026 02:41:08 GMT

Created page with "= Overview = Services that manage markers (transformUnits/StageAdjust) links to videoFeeds. = Services = == Markers == * Service - SupplyVideoFeed Transform Units = Working documents = Service Stack - SupplyVideoFeed Markers"

New page

= Overview =

Services that manage markers (transformUnits/StageAdjust) links to videoFeeds.

= Services =

== Markers ==

* [[Service - SupplyVideoFeed Transform Units]]

= Working documents =

[[:Category:Working_documents - Service Stack - SupplyVideoFeed Markers| Service Stack - SupplyVideoFeed Markers]]

Service - SupplyVideoFeed Location

Sven the Barbarian — Tue, 18 Aug 2026 02:39:10 GMT

Created page with "= Overview = Links Location objects to VideoFeed structures. = Repository = ... = Object Schemas = ; Additional Information: Per Service Schemas == supVidLocationLink == <syntaxhighlight lang="JavaScript"> { objectType: "supVidLocationLink", generatedBy: "userGenerated", canDelete: false, belongTo: { serviceTag: "SupplyVideoFeedLink", objectType: "supVidLinkBySupplyNetwork" }, addOnDataStructure: [], storageResources: { "dynamo": { "storageTy..."

New page

= Overview =

Links Location objects to VideoFeed structures.

= Repository =

...

= Object Schemas =
; Additional Information: [[Per Service Schemas]]

== supVidLocationLink ==

<syntaxhighlight lang="JavaScript">
{
objectType: "supVidLocationLink",
generatedBy: "userGenerated",
canDelete: false,
belongTo: {
serviceTag: "SupplyVideoFeedLink",
objectType: "supVidLinkBySupplyNetwork"
},
addOnDataStructure: [],
storageResources: {
"dynamo": {
"storageType": "dynamoDB",
"tableName": "supVidLocationLink",
},
"myGraph": {
"storageType": "graph",
"graphServerTag": "GraphHandler"
}
},
fieldNames: {
// supplyNetworkId
// operationId
// supplyLocationId
// feedGroupId
},
identifiers: [
{
type: "partitionKey",
fieldNames: ["supplyNetworkId", "operationId"],
name: "supVidLinkId",
},
{
type: "sortKey",
fieldName: "supplyLocationId"
},
]
}
</syntaxhighlight>

== Relationships ==

...

= flowSchemas =

...

= Working documents =

[[:Category:Working_documents - SupplyVideoFeed Location| SupplyVideoFeed Location]]

[[Category:Backend services| SupplyVideoFeed Location]]

Service - SupplyVideoFeed Link

Sven the Barbarian — Tue, 18 Aug 2026 02:36:35 GMT

← Older revision		Revision as of 02:36, 18 August 2026
Line 15:		Line 15:
	{		{
	objectType: "supVidLinkBySupplyNetwork",		objectType: "supVidLinkBySupplyNetwork",
			generatedBy: "systemGenerated",
	canDelete: false,		canDelete: false,
	addOnDataStructure: [],		addOnDataStructure: [
			{
			type:"rbac"
			},
			],
	storageResources: {		storageResources: {
			"myGraph":{
			"storageType": "graph",
			"graphServerTag": "GraphHandler"
			},
	"dynamo": {		"dynamo": {
	"storageType": "dynamoDB",		"storageType": "dynamoDB",
	"tableName": "~~supVidLinkBySupplyNetwork~~",		"tableName": "comAccLinkByBusiness",
	}		}
	},		},
Line 29:		Line 38:
	identifiers: [		identifiers: [
	{		{
	// supplyNetworkId		// supplyNetworkId: [supplyNetworkId,operationId]
	}		}
	]		]

Service Stack - SupplyVideoFeed Location

Sven the Barbarian — Tue, 18 Aug 2026 02:24:30 GMT

Created page with "= Overview = Services that manage location links to videoFeeds. = Services = == Locations == * Service - SupplyVideoFeed Location = Working documents = Service Stack - SupplyVideoFeed Location"

New page

= Overview =

Services that manage location links to videoFeeds.

= Services =

== Locations ==

* [[Service - SupplyVideoFeed Location]]

= Working documents =

[[:Category:Working_documents - Service Stack - SupplyVideoFeed Location| Service Stack - SupplyVideoFeed Location]]

Development - Izara Supply to VideoFeed

Sven the Barbarian — Tue, 18 Aug 2026 02:23:30 GMT

← Older revision		Revision as of 02:23, 18 August 2026
(One intermediate revision by the same user not shown)
Line 4:		Line 4:

	* [[Service Stack - SupplyVideoFeed Link]]		* [[Service Stack - SupplyVideoFeed Link]]

			* [[Service Stack - SupplyVideoFeed Location]]
			* [[Service Stack - SupplyVideoFeed Markers]]

	== NPM modules ==		== NPM modules ==

	* ..		* ..

2026-08-18 Backend User and RBAC Data

Sven the Barbarian — Tue, 18 Aug 2026 01:38:41 GMT

Sven the Barbarian moved page 2026-08-18 Backend User and RBAC Data to 2026-08-18 - Backend User and RBAC Data

New page

[[User Data Handling]]

= Overview =

How to pass around userId and targetIdentifiers for permissions/account limits/resource use, and for creating automatic data such as createdBy and belongTo relationships in graph database.

= updated idea =

* baseUserId can stay in iz_Context because it should not change during processing
* maybe change baseUserId to submittedByUserId to be more clear, but see baseUserId reason for name below
* however consider if future flows will handle many submittedByUserIds, eg automated tasks that handle many submitted tasks, if that is common it might be better to allow generated code to pass the submittedByUserId as a flow input param
* targetId change to identifer object {fieldname: fieldValue} named targetIdentifiers
* generated code can where possible add this automatically when initializing flows, and can check received valid identifiers according to flowSchema

== RBAC ==

* RBAC actions are basically list of flows, with target coming from the flows base objType (using either that objTypes rbac additional addOnDataStructure or if that objType has belongTo following that)
* generated code automatically validates submittedByUserId and targetIdentifiers, sends to permissionHandler/RBAC

== Account Limits ==

* standardize checking of accountLimits so generated code can check per flow
* probably allow for additional developer added accountLimits to be checked anywhere in code

== Resource use ==

* ? connected to target user if belongTo = user, but if not connect to submittedByUserId

= old attempts =

== First design ==

* url paths sent from frontend had the service/resource/action and targetId in the url path, extracted by API Gateway
* submittedBy userId was extracted/confirmed from the Cognito token/sub
* RBAC was handled by a Lambda authorizer that used the above extracted variables
* submittedBy and targetIds were saved into iz_Context and automatically passed to proceeding logic

=== limitations ===

* requests must pass API Gateway to extract values
* Lambda authorizers can have limitations that complicated processing

== Second design ==

* using schemas and generated code
* RBAC moved out of authorizers and implemented inside handler lambdas
* still in iz_Context
* variable name is baseUserId, because accountLimits/resourceUse are connected to target userId if belong to User, but baseUserId if not

=== limitations ===

* targetId is a concat string for composite identifiers, want all handling of identifiers to be an object, only change to concat when required (eg save to database that requires single string)
* some flows might need to adjust target according to steps, eg importBatch submission belongTo user but each pending element may have different belongTo objType/instances, this complicates targetId management in iz_Context

[[Category:Working_documents - User Data Handling| 2026-08-18]]
[[Category:Working documents| 2026-08-18]]

User Data Handling

Sven the Barbarian — Tue, 18 Aug 2026 01:18:16 GMT

← Older revision		Revision as of 01:18, 18 August 2026
Line 10:		Line 10:
	* targetId change to identifer object {fieldname: fieldValue} named targetIdentifiers		* targetId change to identifer object {fieldname: fieldValue} named targetIdentifiers
	* generated code can where possible add this automatically when initializing flows, and can check received valid identifiers according to flowSchema		* generated code can where possible add this automatically when initializing flows, and can check received valid identifiers according to flowSchema

			== Graph ==

			* automatically adds createdBy/versionData updatedBy relationships for objects created/updated by user
			* automatically adds createdBy/updatedBy for relationships created/updated by user, relationshipSchema specifies which node to connect this history to
			* automatically adds belongTo relationship when creating a node connecting to targetIdentifiers instance of belongTo objType
			* relationshipSchema sets which side is belongTo node, that node must have belongTo relationship (ie that node must have belongTo or rbac addOnDataStructure)

	== RBAC ==		== RBAC ==

	* RBAC actions are basically list of flows, with target coming from the flows base objType (using either that objTypes rbac ~~additional~~ addOnDataStructure or if that objType has belongTo following that)		* RBAC actions are basically list of flows, with target coming from the flows base objType (using either that objTypes rbac addOnDataStructure or if that objType has belongTo following that)
	* generated code automatically validates submittedByUserId and targetIdentifiers, sends to permissionHandler/RBAC		* generated code automatically validates submittedByUserId and targetIdentifiers, sends to permissionHandler/RBAC

User Data Handling

Sven the Barbarian — Tue, 18 Aug 2026 01:08:23 GMT

Created page with "= Overview = submittedByUserId, targetUserId and targetIdentifiers for permissions/account limits/resource use, and for creating automatic data such as createdBy and belongTo relationships in graph database. = Structure = * baseUserId can stay in iz_Context because it should not change during processing * maybe change baseUserId to submittedByUserId to be more clear, but see baseUserId reason for name below * however consider if future flows will handle many submitted..."

New page

= Overview =

submittedByUserId, targetUserId and targetIdentifiers for permissions/account limits/resource use, and for creating automatic data such as createdBy and belongTo relationships in graph database.

= Structure =

* baseUserId can stay in iz_Context because it should not change during processing
* maybe change baseUserId to submittedByUserId to be more clear, but see baseUserId reason for name below
* however consider if future flows will handle many submittedByUserIds, eg automated tasks that handle many submitted tasks, if that is common it might be better to allow generated code to pass the submittedByUserId as a flow input param
* targetId change to identifer object {fieldname: fieldValue} named targetIdentifiers
* generated code can where possible add this automatically when initializing flows, and can check received valid identifiers according to flowSchema

== RBAC ==

* RBAC actions are basically list of flows, with target coming from the flows base objType (using either that objTypes rbac additional addOnDataStructure or if that objType has belongTo following that)
* generated code automatically validates submittedByUserId and targetIdentifiers, sends to permissionHandler/RBAC

== Account Limits ==

* standardize checking of accountLimits so generated code can check per flow
* probably allow for additional developer added accountLimits to be checked anywhere in code

== Resource use ==

* ? connected to target user if belongTo = user, but if not connect to submittedByUserId

= Working documents =

[[:Category:Working_documents - User Data Handling| User Data Handling]]

2026-08-18 Backend User and RBAC Data

Sven the Barbarian — Tue, 18 Aug 2026 01:07:12 GMT

Created page with "User Data Handling = Overview = How to pass around userId and targetIdentifiers for permissions/account limits/resource use, and for creating automatic data such as createdBy and belongTo relationships in graph database. = updated idea = * baseUserId can stay in iz_Context because it should not change during processing * maybe change baseUserId to submittedByUserId to be more clear, but see baseUserId reason for name below * however consider if future flows will..."

New page

Per Service Schemas

Sven the Barbarian — Tue, 18 Aug 2026 00:59:39 GMT

Not extendObjType

← Older revision		Revision as of 00:59, 18 August 2026
Line 16:		Line 16:
	shortNameObjectType:"x", // optional, use when generate code create lambda role with long name		shortNameObjectType:"x", // optional, use when generate code create lambda role with long name
	canDelete: false, // whether any fields can be deleted // default = false		canDelete: false, // whether any fields can be deleted // default = false
	belongTo: {		belongTo: {
	serviceTag:"iii",		serviceTag:"iii",
	objectType:"jjj"		objectType:"jjj"

Design concepts

Sven the Barbarian — Tue, 18 Aug 2026 00:32:43 GMT

← Older revision		Revision as of 00:32, 18 August 2026
Line 51:		Line 51:
	* [[Standard Data Structures]]		* [[Standard Data Structures]]
	* [[Standard Config Table Per Service]]		* [[Standard Config Table Per Service]]
			* [[User Data Handling]]
	*: (maybe removing)		*: (maybe removing)
	* [[Standard LogicalResults Per Service]]		* [[Standard LogicalResults Per Service]]

2025-11-20 IntegrationTest

Mint — Mon, 17 Aug 2026 03:25:49 GMT

dynamoDBSeedDataTags

Show changes

Per Service Schemas

Seagame — Wed, 12 Aug 2026 02:28:51 GMT

Flow Schema | FlowSchemas.js

← Older revision		Revision as of 02:28, 12 August 2026
Line 364:		Line 364:
	previousSteps: [		previousSteps: [
	{		{
	stepName: "xxx"		sourceType:"ownTopic", // if from own flow
			stepName: "xxx",
	},		},
	{		{
Line 370:		Line 371:
	serviceTag: "InventoryService",		serviceTag: "InventoryService",
	topic: "ReserveStock_In",		topic: "ReserveStock_In",
	~~fromStepName~~: "xx" // which step in this flow sent request to external flow, used to find awaitingStep prefix		fromStepNames: ["xx"] // which step in this flow sent request to external flow, used to find awaitingStep prefix
	}		}
	],		],
	nextSteps: [		nextSteps: [
	{		{
			targetType:"ownTopic", // if from own flow
	stepName: "yyy"		stepName: "yyy"
	},		},
Line 380:		Line 382:
	targetType: "extTopic",		targetType: "extTopic",
	serviceTag: "InventoryService",		serviceTag: "InventoryService",
	topic: "ReserveStock_In"		topic: "ReserveStock_In",
			toStepNames: ["xx"] // which step in this flow sent request to external flow, used to find awaitingStep prefix
	}		}
	],		],

Per Service Schemas

Sven the Barbarian — Tue, 11 Aug 2026 14:19:59 GMT

Flow Schema | FlowSchemas.js

Show changes

2025-11-20 IntegrationTest

Sven the Barbarian — Tue, 11 Aug 2026 13:08:42 GMT

graphSeedDataTags

← Older revision		Revision as of 13:08, 11 August 2026
(One intermediate revision by the same user not shown)
Line 120:		Line 120:
	{		{
	logicalResultId: {		logicalResultId: {
	value: "eeeeeeeeee4"		value: "eeeeeeeeee4"
	},		},
	"identifiersId": {		identifiersId: {
	"value: "lllll123456"		value: "lllll123456"
	},		},
	"processLogicalResultExpiryTimestamp" {		processLogicalResultExpiryTimestamp: {
	calcType: "currentTimestampAdjustment", // can add other types of calculated data in future		calcType: "currentTimestampAdjustment", // can add other types of calculated data in future
	action: "subtract", // add\|subtract		action: "subtract", // add\|subtract
Line 133:		Line 133:
	{		{
	logicalResultId: {		logicalResultId: {
	value: "eeeeeeeeee4"		value: "eeeeeeeeee4"
	},		},
	"identifiersId": {		"identifiersId": {
	"value: "lllll777777"		value: "lllll777777"
	},		},
	"processLogicalResultExpiryTimestamp" {		processLogicalResultExpiryTimestamp: {
	calcType: "currentTimestampAdjustment", // can add other types of calculated data in future		calcType: "currentTimestampAdjustment", // can add other types of calculated data in future
	action: "add", // add\|subtract		action: "add", // add\|subtract
Line 145:		Line 145:
	}		}
	],		],
	},		},
	},
	{		{
	"tableName": "MLocationsTestFloatingRelationships",// servcieTag+stage+tablename		"tableName": "MLocationsTestFloatingRelationships",// servcieTag+stage+tablename
Line 200:		Line 199:
	"identifiers": {		"identifiers": {
	"sellOfferPlanDeliveryMethodLinkId": {		"sellOfferPlanDeliveryMethodLinkId": {
	"value": "minttestrefreshSeedData_01",		"value": "minttestrefreshSeedData_01",
	},		},
	},		},
	"fields": {		"fields": {
	"productId": {		"productId": {
	"value": "ddddd",		"value": "ddddd",
	},		},
	"price": {		"price": {
	"value": 9999		"value": 9999
	},		},
	exampleTimestamp:{		exampleTimestamp: {
	calcType: "currentTimestampAdjustment", // can add other types of calculated data in future		calcType: "currentTimestampAdjustment", // can add other types of calculated data in future
	action: "subtract", // add\|subtract		action: "subtract", // add\|subtract
Line 297:		Line 296:
	"value": true		"value": true
	},		},
	exampleTimestamp:{		exampleTimestamp: {
	calcType: "currentTimestampAdjustment", // can add other types of calculated data in future		calcType: "currentTimestampAdjustment", // can add other types of calculated data in future
	action: "subtract", // add\|subtract		action: "subtract", // add\|subtract
	adjustment: "2 days", // Human-Readable Relative Format		adjustment: "2 days", // Human-Readable Relative Format
	}		}
	}		}
	}		}

2025-11-20 IntegrationTest

Mint — Tue, 11 Aug 2026 07:18:47 GMT

graphSeedDataTags

@@ Line 119: / Line 119: @@
        "datas": [
+         {
-           "logicalResultId": "eeeeeeeeee4",
+           logicalResultId: {
-           "identifiersId": "lllll123456"
+	    		  value: "eeeeeeeeee4"
          },
+         {
-           "logicalResultId": "eeeeeeeeee4",
+           logicalResultId: {
-           "identifiersId": "lllll777777"
+	    		  value: "eeeeeeeeee4"
+         }
        ],
 		},
 	},
@@ Line 188: / Line 199: @@
            "objectDetail": {
              "identifiers": {
-               "sellOfferPlanDeliveryMethodLinkId": "minttestrefreshSeedData_01"
+               "sellOfferPlanDeliveryMethodLinkId": {
-            },
+				        "value": "minttestrefreshSeedData_01",
              "fields": {
-               "productId": "ddddd",
+               "productId": {
-               "price": 9999
+				        "value": "ddddd",
+             }
+           }
          },
@@ Line 279: / Line 293: @@
                "relTypeConcat": "servcieMintTest_shoppingMall_hasShoppingMallCalculateSetting",
                "relId": "uuid-77777-99999",
-               "relationshipProperty": {
+               "relationshipProperties": {
-                 "statusName": true
+                 "statusName": {
+               }
+             }
+           ]