ayanova/devdocs/todo.txt

@@ -13,7 +13,8 @@ MISC ITEMS THAT CAME UP
 todo: acc-service-bank is using a decimal control instead of a  currency control for currency field
 todo: Unit override warranty lifetime active should disable or even hide "override length" field
 todo: OverrideLifetime is bad text, fix it, key is "UnitOverrideLifeTime" and maybe it just says "Life time warranty"
-
+todo: should user required rule (defined in form custom settings) show a variation of the required error message so that it's clear *they* defined it and they can unset it in customize?
+	right now they could set a required rule, forget they set it then email us to bitch that it shouldn't be required
 todo: inconsistent use of browser language and browser languages
 	getBrowserLanguages() <--- more often used vs getBrowserFirstLanguage() <-- fewer times used
 	some things are using the default first language
@@ -47,27 +48,6 @@ todo: WHEN HAVE WORKORDER FORM customer popup notes need to pop pop pop, forgot
 
 ## SERVER MISC ITEMS
 
-todo: child collection items error / rule / customization handling
-	All commented in with //TODO: CHILD COLLECTION MOD 
-	Currently not supported but should be when get to wo it will be a beast without this
-	users will need to hide child items, set required on them and see errors from server on them
-	RESOLUTION:
-		Add child collection items to FormFieldReference and set the FieldKey to be in teh form of ParentCollectionName.FieldName 
-			where ParentCollectionName is exactly the same as the Model collection property name and 
-			FieldName is exactly the same as the child collection objects Model property name
-		Update RequiredFieldsValidator to look for these period seperated items and navigate through teh collection by name / reflection to step through children and flag errors to include parent 
-			e.g in purchase order record, validation error for not entering required Ordered quantity
-			"target" field name would be "items[0].quantityOrdered"  to indicate poitems collection quantityOrdered field and items[0] indicates the first record in the collection
-			Note that this is how the built in validation for Model Required rules operates and that's useful so mirroring it even though it's a little harder to parse it saves a lot of dev time
-			as data annotations will be supported as is
-		Update ValidationError.cs class, add index property and use it for above
-		Update BizObject.cs add error methods that include index for use with indexed collection item errors
-		Update client gzform.cs server errors handler to handle indexed child collection like that and report error on row and in popup edit form 
-		Update client po items form to display error in data table read only display somehow (can't be hover due to mobile so other way)
-			maybe just red row to indicate has errors with some non color secondary indicator, they open and the edit form shows the exact error on the field		
-		Update client po edit poitem form input controls, use regular biz rule error from server handling but use the compound key name for the item e.g. "poitem.vendorpartnumber"
-		Update form customization form at client to group together the child collection items and maybe indicate the collection name above or in a group
-			so all poitem fields grouped in UI apart from header form fields
 
 todo: tax codes, taxable objects
 	Biz rules updated to prevent tax value changes to any of the following fields once it's been used on any item that has tax codes
@@ -92,14 +72,31 @@ todo: tax codes, taxable objects
 		private Guid mTaxRateSaleID;
 	PurchaseOrder needs to default tax codes when created from global settings
 
+todo: actual Customer report with names populated
+	
+	I *was* thinking an alternate data list mode for reporting where there are more defined links in the list to fetch names?
+	But that doesn't really fit in with the object nature of new reporting as datalist returns will be kind of ugly to work with and also bad for exporting
+	So I'm back to model populating in biz getreportdata method:
+	    //Note in purchaseorderbiz::getreportdata: 
+		TODO: for reporting this would be more ideal if it populated the displayName fields
+                //I'm doing that in this object already by fluke, and don't really want to populate them always and in other objects but for reporting maybe 
+                //have a report mode get or I guess just do it all here (but then need for export as well, but then again this is the way it gets for export via getreportdata)
+                //so perhaps we have a REPORT format of a biz object model and that format has display names mirroring all the fields
+                //it's fetching it here anyway, might as well do the whole shebang?
+	So, bottom line might be an alternate ReportModel (e.g. Customer / ReportCustomer) with display fields (not the model sent to the client during normal work as that would eat up bandwidth unnecessarily)
+	Stop thinking about efficiency too much, this is a time to waste a few cycles but make a much easier to work with data return for reports / export
+	All display fields are populated as is done with PO similarly and that is done *in* get report data because that's also the export route use too which fits nicely with what we want
+	Make it work with Customer then backport to all the extant objects and add to item migrate todo list below as a step so it doesn't get missed in future ones
 
+	
 
 todo: GetWorkorderSerial/name from leaf nodes 
 	traverse up the tree and fetch the serial number
 	once coded fixup in purchaseorderbiz::getasync MIGRATE_OUTSTANDING bit
 
-todo: actual customer reports so can figure out datalist for bringing other names in
-	I'm thinking an alternate mode for reporting where there are more defined links in the list to fetch names?
+
+
+	
 
 
 todo: v8 migrate additions
@@ -180,17 +177,18 @@ todo: test new from scratch po
 todo: test duplicate route
 todo: test inventory affecting ops
 	reversals, updates, deletes etc
-todo: test default tax codes are set
 todo: test form customization hide child collection items
 
-
 todo: test read only form of PO
 todo: test reports, tagging etc
 todo: can edit po number but if I set an existing po number 4 to 23 for example and the last autogenerated is 22 it will happily make another 23 so there are now two
 	what I want to happen is it skips existing numbers
+	Research this method and how we can work with it and give it a good think because it maybe a dangerous thing to expose or just fuckery
+	it really only will be of use in rare circumstances and most likely when importing v7 with oddball numbers (Scott?)
 	not many serialized objects, maybe a utility to do wahtever, renumbering with them could be done for just that purpose entirely
 	(along with resetting the autoid number)
-	Does this require a special role?
+	Should this operation require a special role?
+		i.e. if logged in as a bizadmin full then can edit serials