JeremyAnson
Qrew Cadet
Joined 6 years ago
User Profile
User Widgets
Contributions
Unexpected behaviour with 'require' form rules
We are seeing unexpected behaviour with form rules on a legacy form. The form contains a form rule that makes several date fields required - I'll call them A, B and C. The rule was set up so that the fields would be made required in the order A, B, C. However, the form generates 'the field X is required' messages in the order B, C, A. The behaviour doesn't change when we create 3 separate rules and change the order. It appears that the messages are generated in field ID order. Has anyone seen this behaviour? Secondly, when we click OK after the 'the field X is required' messages, the date fields are being populated with the last date field entered into the form - e.g. if I populate field B and get a message to populate field A, field A is being populated with the value in field B when the form redisplays. It's very strange. Again, has anyone seen this behaviour?14Views0likes0CommentsRe: Behaviour of report filters applied in combination
So, it seems that what we're seeing with new style reports is 'currently the correct behaviour'. When switched to old style, the dynamic filters also do not adjust based on other dynamic filter selections, so it doesn't help us out in this case. It's been a while since I've used old style reports and I can't remember if this has always been the case; I suspect it has been.20Views0likes1CommentBehaviour of report filters applied in combination
It was my understanding that when a value is selected in a filter on a report, other filters would adjust to only include values from the resulting set of records - i.e. you could only select from values that occur in the record set you are viewing. For example, in a table where request types are grouped into categories, picking a single request category in a filter would mean you would only see request types relating to that category in the filter for that column. That's not how filtering is working, so ... has it always been this way, or has something changed?48Views0likes5CommentsRe: "Attempting to add a non-unique value to a field marked "unique" error on a QB Connected Table
The approach in Excel was to download as a CSV file and then pivot on the key field. It didn't find any because the accounts were different. When I followed your approach there were some duplicates (the accounts were different, but the name part of the accounts were the same). I removed one of each pair from the source table and repeated the exercise, but still no luck. After some further selective pruning of the data I got the sync to work. I'm not sure what made the difference, but it worked. We have pipelines running overnight that may add some of the data back in, so it will be interesting to see if the sync keeps working.63Views0likes0CommentsRe: "Attempting to add a non-unique value to a field marked "unique" error on a QB Connected Table
Hi Mark, yes, I checked on the source table, which has 'user account' as a key field (not sure why we did that when we created the table). There were a few accounts showing multiple records, where someone has two accounts linked to separate email addresses (so not identified as duplicates when checked in Excel). I've removed the 'duplicates' but am still getting the same error.70Views0likes2CommentsRe: Using a formula field to open a record in another form
Yes, that should work in most cases. We found the logic required to deliver different UIs based on attributes of the record was becoming extremely complicated to implement and test. We also had to place fields on different tabs depending on these attributes, which meant the single form route wouldn't work (AFAIK :)). ------------------------------ Jeremy Anson ------------------------------42Views0likes6CommentsRe: Using a formula field to open a record in another form
We have used this approach, but it's not hugely successful because users end up on different forms when switching modes. Short of trying to replace all the default form buttons it seems there is no way to achieve the desired outcome. It would be really useful to be able to define simple logic to define which form to display. ------------------------------ Jeremy Anson ------------------------------53Views0likes8Comments