Trying to sync up a postgres record to airtable on create/update. The field has a couple of ids that I would like to check for in airtable to determine whether I should create a new record or update an existing one. The first id (optional_id) I need to search on can possibly be null. This causes the search to fail before it can get to the other id(required_id) that should always be populated. Is there any way I can skip the initial search for optional_id if it turns out to be null in postgres?
My current outline is as follows:
I would use a Formatter > Text > Default Value step in case the input value can be null and then make sure the fallback value is from a record that does not exist.
If further help is needed, feel free to reach out to us here:
https://zapier.com/app/get-help
Related
I have a DateTime field (MyDTField) in my Azure DevOps instance (I am an admin on it, so I can change its schema if necessary). I would like to write a query that returns any items where the above field (MyDTField) changed in the last 7 days. Is this possible to do?
For e.g. the built in "Changed Date" field allows us to write a similar query, but that returns work times where any field value changed. I want to get items where a specific field changed within a specified time period.
Thanks!
You can try to set up a query like as below to see if it can work as expected.
To view more details, you can see:
Query history and discussion fields
Operators and macros supported for each data type
[UPDATE]
As a workaround, you can try like as below on each of the work item types that have the MyDTField field:
Add another custom Date/Time field, for example "MyDTField Latest change Date" field.
Add a work item rule like this. With this rule, once the MyDTField field changed, the value of the MyDTField Latest change Date field will be automatically changed to the current date/time.
Set up the query like as this. With this query, you will get the list of work items as your expectation.
Anyone been able to successfully update the custom_field_values for a matter via Clio's API?
I'm trying to update the value for custom_field_values under a single matter. I'm able to send a JSON string using PATCH and update the default values for a matter like location or description using the following format
{"data":{"location":"Orange"}}
But when it comes to updating a "custom field value" I'm getting a 422 Unprocessable Entity error. I'm following Clio's v4 API Documentation and my understanding is that to update a custom_field_value you need the following JSON:
{"data":{"custom_field_values":[{"id":658213,"custom_field":{"id":139385},"value":"New Value Goes Here!"}]}}
However here is the message coming with the 422 error:
{"error":{"type":"ArgumentError","message":"An invalid argument was supplied: invalid custom field value id provided, acceptable format is <type>-<unique id>"}}
I can't interpret the part suggesting the acceptable format!
I've also tried sending the JSON in the following format which is closest to Clio's V2 API Docs for updating a custom field:
{"data":{"custom_field_values":[{"custom_field":{"id":139385},"value":"New value goes here"}]}}
But then this is what I get back:
{"error":{"type":"ArgumentError","message":"An invalid argument was supplied: custom field value for custom field 139385 already exists"}}
Please note that this is being tested in POSTMAN regardless of my development environment. I appreciate your response!
I've successfully created queries to update custom field values in matters many times, and these run all the time for me. I've compared your json to some examples of the json I'm successfully sending. Your syntax appears correct, but there's enough missing for me to only guess at where your mistake might be.
First, you're sending a PATCH to https://app.clio.com/api/v4/matters/{matter id}.json right? It took me a while to learn that you can't update the value of a matter's custom field with a query to https://app.clio.com/api/v4/custom_fields/{id}.json.
Second, just to clarify, the 658213 id you used above (the first id field) should be the unique id of this instance of your custom field. You won't get this until you've created an instance of the custom field particular to this matter. The second id field, where you've put 139385 is the id for the custom field itself, which you could get with a query to https://app.clio.com/api/v4/custom_fields.json.
If you're looking in the V.4 docs under Custom Fields, you won't find this, or at least I didn't. BUT you can find it in the intro section to the Matters portion fo the documentation: https://app.clio.com/api/v4/documentation#tag/Matters
Hope this helps. I'd imagine someone at Clio could help by verifying your error string is delivered when you have an incorrect custom field value unique id.
To further clarify Jacob's answer for everyone else:
custom_field{id} is the id given to a custom_field when it's created and will be the same for all matters or contacts it's used in.
custom_field_value{id} is the id given to an instance of the custom_field added to a particular matter and unique only to that matter
To add a custom_field to a matter for the first time the following format is used:
{"data":{"custom_field_values":[{"custom_field":{"id":123456},"value":"string or integer depending on the type of CF"}]}}
To update a custom field already added to a matter the following format should be used:
{"data":{"custom_field_values":[{"id":"text_line-1234567", "custom_field":{"id":123456},"value":"string or integer depending on the type of CF"}]}}
To delete a custom field already added to a matter the following JSON format is sufficient:
{"data":{"custom_field_values":[{"id":"text_line-1234567", "custom_field":{"id":123456},"_destroy":true}]}}
Format for updating a custom field already added to a matter:
{"data":{"custom_field_values":[{"id":"unique_instance_of_your_custom_field", "custom_field":{"id":'custom_field_id'},"value":"value which should be updated"}]}}
Here, the first id field should be the unique id of this instance of your custom field. To get this value follow this documentation section, app.clio.com/api/v4/documentation#tag/Matters and the second id field is the id for the custom field itself.
The application I'm working on is a character based application. there is a field adfc.unme-code in a table and another field arbu.unit-code-shu. These two fields are shown in different windows but they must be in sync. When I update unme-code, unit-code-shu must be updated too.
Is a simple assign statement would be enough or should I do something else? Also, should I use the actual fields or a buffer?
You can use the ASSIGN statement in your code to assign both values at the same time. If there's a possibility of some other process changing those fields, you can create a database trigger procedures on each field to copy the value over to the other field. In the Data Dictionary, view the field properties and click on the "Triggers..." button to do that.
Yes, ASSIGN is used to set the value of a buffers/records field. However: certain critera needs to be met:
The buffer/record needs to be available.
You must have the "lock" of the buffer/record.
If you have the record available and locked you can simply do:
ASSIGN arbu.unit-code-shu = adfc.unme-code.
To make this code "safer" you can simply make sure that arbu is available and not locked by any other user. And finally it will handle if your assign fails because you have no lock at all.
IF AVAILABLE arbu AND NOT LOCKED arbu THEN DO:
ASSIGN arbu.unit-code-shu = adfc.unme-code NO-ERROR.
IF ERROR-STATUS:GET-NUMBER(1) = 396 THEN DO:
MESSAGE "Apparently the record is locked." VIEW-AS ALERT-BOX ERROR.
END.
END.
If you do not have the record (or the right locking) you need to look into your application and see how you can add this feature. What identifies the right record of the second table? A single id? Something else? Are there always a 1 to 1 relation between arbu and adfc etc?
Perhaps your application has a simple way of setting the value of a field. If there is a architecture at place you should try to stick to it...
I am trying to save a null value in a dateTimeField object in MongoDB. I have a date I only want set after a certain condition has been fulfilled, but my site has the ability to save an object multiple time to the database before this variable will be set to anything other than a null or empty string value. I tried using db.dateTimeField(null=True) in my model file per Mongo's documentation to save a null value, but I still get an error when trying to save to the database.
According to this issue on Github, there is some inconsistent behavior with setting null values to dateTimeFields. Does anyone know if this has been fixed? I have a work around (adding my attribute to my object, then assigning it a value right before saving, therefore bypassing the need to save a null value, but it is a bit hacky, and I would like to use MongoDB's built in functionality if possible).
Thanks in advance!
I'm trying to copy some field values to a duplicate database. One record at a time. This is used for history and so I can delete some records in the original database to keep it fast.
I don't want to manually save the values in a variable because there are hundreds of fields. So I want to go to the first field, save the field name and value and then go over to the other database and save the data. Then run a 'Go to Next Field' and loop through all the fields.
This works perfectly, but here is the problem: When a field is a calculation you cannot tab into it and therefore 'Go to Next Field' doesn't work. It skips it.
I though of doing a 'Go to Object' but then I need to name all the objects and I can't find a script to name objects.
Can anyone out there think of a solution?
Thanks!
This is one of those problems where I always found it easier to do an export/import.
Export all the data you want from the one database, and then import it into the other database. All you need to do is:
Manually specify which fields you want to copy
Map the data from the export to the right fields in the new database/table
You can even write a script to do these things for you.
There are several ways to achieve this.
To make a "history file", I have found there are several cases out there, so lets take a look.
CASE ONE
Single file I just want to "keep" a very large file with historical data, because I need to erease all data in my Main file.
In this case, you should create a "clone" table (in the same file ore in other file, is the same). Then change any calculation field to the type of the calculation result (number, text, date, an so on...). Remove any "auto entered value or calculation from any field, like auto number, auto creation date, etc..). You will have a "Plain Table" with no calculations or auto entered data.
Then add a field to control duplicate data. If you have lets say an invoice number (unique) for each record, you can do this to achieve this task. But if you do not have a unique field that identifies the record as unique, then you have to create one...
To create such a field, I recommed to add a new field on the clone table and set as an aunto entered calculation and make a field combination that is unique... somthing like this: invoiceNumber & "-" & lineNumber & "-" " & date.
On the clone table make shure that validation is set up for "always", and no empty values allowed and that this value is unique.
Once you setup the clone table... then you can import your records, making sure that the auto enty option is on. Yo can do it as many times as you like, new records will be added and no duplicates.
If you want, can make a Script to do the move to historical table all the current records before deleting them.
NOTE:
This technique works fine when the data you try to keep do not have changes over time. This means, once the record is created is has no changes.
CASE TWO
A historical table must be created but some fields are updated.
In the beginnig I thougth a historical data, never changes. In some cases I found this is not the case, like the case I want to track historical invoices but at the same time, keep track if they are paid or not...
In this case you may use the same technique above, but instead of importing data... you must update data based on the "unique" fields that identifiy the record.
Hope this technique helps
FileMaker's FieldNames() function, along with GetField() can give you a list of field names and then their values