This commit is contained in:
@@ -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
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -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
|
||||
vm.obj = res.data;
|
||||
//Change URL to new record
|
||||
//NOTE: will not cause a page re-render, almost nothing does unless forced with a KEY property or using router.GO()
|
||||
|
||||
// this.$router.push({
|
||||
// name: "inv-purchase-order",
|
||||
// params: {
|
||||
// recordid: res.data.id,
|
||||
// obj: res.data // Pass data object to new form
|
||||
// }
|
||||
// });
|
||||
//POST or PUT - whole new object returned which is a little different than other objects
|
||||
//so if it's new then need to navigate to it to update url with id
|
||||
if (vm.$route.params.recordid != 0) {
|
||||
console.log("STAY IN PLACE");
|
||||
//update of existing record
|
||||
vm.obj = res.data;
|
||||
} else {
|
||||
console.log("NAV TO NEW");
|
||||
this.$router.push({
|
||||
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({
|
||||
|
||||
Reference in New Issue
Block a user