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
 
 
 

ayanova/src/views/inv-purchase-order.vue

@@ -28,6 +28,7 @@
             <gz-pick-list
               :aya-type="ayaTypes().Vendor"
               :show-edit-icon="true"
+              :allow-no-selection="false"
               v-model="obj.vendorId"
               :readonly="formState.readOnly"
               :label="$ay.t('Vendor')"
@@ -35,6 +36,7 @@
               data-cy="vendorId"
               :error-messages="form().serverErrors(this, 'vendorId')"
               @input="fieldValueChanged('vendorId')"
+              :rules="[form().required(this, 'vendorId')]"
             ></gz-pick-list>
           </v-col>
           <v-col
@@ -758,7 +760,7 @@ export default {
         {
           id: 0,
           concurrency: 0,
-          serial: null,
+          serial: 0,
           notes: null,
           wiki: null,
           customFields: null,
@@ -769,7 +771,7 @@ export default {
           vendorId: null,
           orderedDate: window.$gz.locale.nowUTC8601String(),
           expectedReceiveDate: null,
-          status: null,
+          status: 1,
           projectId: null,
           text1: null,
           text2: null,
@@ -1138,25 +1140,29 @@ export default {
         let url = API_BASE_URL; // + vm.$route.params.recordid;
         //clear any errors vm might be around from previous submit
         window.$gz.form.deleteAllErrorBoxErrors(vm);
-
+        console.log("UPSERT");
         let res = await window.$gz.api.upsert(url, vm.obj);
 
         if (res.error) {
           vm.formState.serverError = res.error;
           window.$gz.form.setErrorBoxErrors(vm);
         } else {
-          //POST or PUT - whole new object returned
+          //POST or PUT - whole new object returned which is a little different than other objects
-          vm.obj = res.data;
+          //so if it's new then need to navigate to it to update url with id
-          //Change URL to new record
+          if (vm.$route.params.recordid != 0) {
-          //NOTE: will not cause a page re-render, almost nothing does unless forced with a KEY property or using router.GO()
+            console.log("STAY IN PLACE");
-
+            //update of existing record
-          // this.$router.push({
+            vm.obj = res.data;
-          //   name: "inv-purchase-order",
+          } else {
-          //   params: {
+            console.log("NAV TO NEW");
-          //     recordid: res.data.id,
+            this.$router.push({
-          //     obj: res.data // Pass data object to new form
+              name: "inv-purchase-order",
-          //   }
+              params: {
-          // });
+                recordid: res.data.id,
+                obj: res.data // Pass data object to new form
+              }
+            });
+          }
 
           //Update the form status
           window.$gz.form.setFormState({