When it comes to creating/updating custom objects, can I use both dedupeFields or lookupField when pushing the data to Marketo?
What is the difference between the two?
I'm not sure what do you mean under lookupField, as there is no such input field described in the API documentation of the Sync Custom Objects endpoint. (That is the endpoint to create or update custom objects.)
In the other hand, you do not need such a standalone lookup field, as with the input array you provide the objects you want to create or update, with all their important values. Have a look at the sample payload in the docs.
When input is used together with the optional dedupeBy and action fields, you have full control over which object you want to create or update.
Also, the endpoint expects the name of the dedupe field under dedupeBy key, as opposed to dedupeFields. So the name is singular; you can provide a single field name use, and it does what you can expect: if the value in the field for a given record is not unique, an error will be returned for the individual record.
Related
I have EntityField and UsersField(ListBox). When I change Entity to USERS, I need to pass: UsersLookupCall, when I change Entity to Projects, i need to pass ProjectUsersLookupCall to UsersField.
Also if that is possible, how to pass a parameter to that lookup call I am passing to another field?
Thanks
You can exchange the lookup-call on a (Smart-)Field simply by calling the setLookupCall(ILookupCall<T>) method on the field. However, since the value of the field is strongly typed and the type of the lookup must match the type of the field you can only set lookup calls with the same type.
You find a lot of examples on how to react on value changes in the Scout Beginners Guide.
You can set additional parameters on the lookup call by implementing the execPrepareLookup(ILookupCall<T>) method. Note: there are also specialized execPrepare* methods for the three lookup modes: key, text and rec.
I created a custom object and i want to get all its existing records. Is there a way of doing that via the REST API? Seems like a very basic and simple operation but i couldn't find information about it anywhere.
As you say, it seems like a basic task, but in the reality, it is more complex indeed.
Unfortunately, the Get Custom Object endpoint (which is the only endpoint to fetch Custom Objects) requires the filterType and filterValues parameters to be present as well. Basically this means that you have to have some information about the queried objects beforehand.
Also, a further restriction is that the value of filterType can only be one of the “searchable” fields of the Custom Object, meaning that it has to be either a Link field or a Dedupe field. (These fields are listed under the searchableFields property in the response from the Describe Custom Objects endpoint.)
So as mentioned above, you have to know the values for at least one of the properties of your Custom Objects before you make the query.
With additional queries though, you can grab these required values.
Let's say, you have your Custom Object linked to the Lead Object, and the Link field is called Owner Email (with the REST API name being ownerEmail) which links to the Email Address field of the Lead Object. In this case you could set the filterType to ownerEmail and set the emails of the leads as filterValues.
Then it is up to you how you gather the emails of those Leads who has a Custom Object attached. Luckily the REST API won’t throw an error if you provide a value that has no corresponding Custom Objects.
If your Custom Object is linked to a Lead, it's a bit complex but you can do like this:
Create a smart list and filter with "Has You Custom Object"
Get the smart list with API (GET /rest/asset/v1/smartLists.json)
Based on this list of Leads, get all Custom Objects (see the other answer).
Specifically \Forms\SalesCreateOrder\Data Sources\SalesTable\Fields\CustAccount\lookup
Where does the super() call go to? What determines the fields that are populated with this?
The EDT is CustAccount, and I don't see a "FormHelp".
The super() calls the performDBLookup method of the control, which creates the lookup form .
You can read all about it on Axaptapedia.
Axapta uses a simple system to determine which fields to display in an automatically created lookup.
If no special changes are made, then the fields shown on the lookup are determined by the following information from the base table:
The field(s) responsible for the relation
TitleField1
TitleField2
The first field of every index of the table (in the order of the index-id)
I have some indexes in portal_catalog, for various types.
Given a portal_type and a fieldname, how can I find out the name of the index (if any) for that field?
Some relevant pointers to documentation about zcatalog might help me too!
Thanks..
There is no easy one-on-one way to determine this. In Plone 4, there are basically three different ways that an index in the catalog can obtain the information from your content type.
Index configuration
First and foremost, indexes can optionally be configured with the name(s) of the attributes or methods to index on a given object. Indexes generally have a getIndexSourceNames method that'll tell you what items they'll index.
Usually this is the same as the index id, but this is not a given. Generally, if your field accessor is listed in the result of getIndexSourceNames then that index will be indexing that field for a given type:
from Products.CMFCore.utils import getToolByName
catalog = getToolByName(context, 'portal_catalog')
for index in catalog.index_objects():
if field.accessor in index.getIndexSourceNames():
print 'Index %s indexes %s' % (index.getId(), field.getName()'
In the above examples, I assumed you already have a hold of your field object in the variable field, with an actual instance of your type in the variable context.
Custom indexing adapters
When an object is indexed, the catalog also constructs a wrapper around the object and will look up indexing adapters for your object. These adapters are registered both for the indexed name (so the name listed in getIndexSourceNames) and an interface or class. If your content class implements that interface or has an indexing adapter directly registered for it's class or a base class, the indexing adapter can be brought into play.
Indexing adapters are arbitrary snippets of code, and thus could call any field on your content object to produce their results. There is no programmatic way for you to determine if a given field on your content type will be used, or if any fields will be used at all.
The CMFPlone.CatalogTool module lists several examples of indexing adapters, these are all registered for Interface, meaning all objects:
allowedRolesAndUsers collects security information about your object.
getObjPositionInParent determines the position of the current object in it's container. Thus, this indexer does not need any information from the object itself to determine it's value.
sortable_title takes your content Title value and generates a value suitable for sorting catalog search results with. It normalizes the value, lowercases it, and prefixes numbers with leading zeros to make sorting on numbered titles easier.
Direct method access
Fields are basically generated methods on your content object. But your content class can also implement methods on it's class. The same remarks as for custom indexing adapters apply here; these are arbitrary Python code so they could be using your content type fields, aggregating and mangling the information before passing it to the index.
The Archetypes BaseObject class (used in all Archetypes content types) defines the SearchableText method for example. This method takes all available fields with the searchable property set to True, tries to get each field value as plain text, and aggregates the results for the SearchableText index.
Conclusion
You can only make educated guesses about index contents as they relate to your fields. By introspecting index configuration, you won't see if there might be a custom indexer adapter masking your field (register a getField index adapter and it'll be used instead of directly calling getField). Custom indexers and class methods can still access your fields and pass on the information to a catalog index.
You just add an index for the method or attribute name that you want to use for the index value--there's nothing too tricky about it and it can potentially all be done TTW
If you need a bit more logic to grab the index, check out this stackoverflow question: Problem with plone.indexer and Dexterity
I have a table in my SQL Server DB that holds auditing information for certain actions a user takes within my system. Things like who performed the action, when it was performed, and what action are all pieces of information that can easily span multiple actions. But depending on the action performed, there may be other information that I want to capture, that is specific to the action. To handle this, I elected to add an "XML Metadata" column to the table that holds serialized XML of different metadata objects that I've created. I created a metadata object for each of the actions that I'm interested in tracking extra for. So each object is responsible for tracking specific extra information (metadata) for it's action. The objects are serialized and written to my new column.
I have SystemAction objects that I use to store information from this table, and I've added a string field that holds the XML string from the DB. The problem is, when I'm reading this XML back from the SystemAction objects, I'm struggling with a way to generically translate it back into it's correct metadata object. Each metadata object is going to have different fields, and each object has it's own static method that takes an XML string and attempts to return the metadata object type. So I could say:
SomeActionMetadata mdObj = SomeActionMetadata.BuildFromXML(xmlStringFromDB);
But I really don't know of a way to say "Here's some XML that could translate to any number of different objects. Figure it out and give me the right object back."
Given my current implementation, I could always just assign a unique ID to each metadata object that is stored as a field in each object, then use a case statement to switch on that ID and use the appropriate class's static build method to build the right object. But I was hoping for something a little more automatic than that. What if I have a List of SystemAction objects and just want to loop through them and generate the correct metadata object type?
I was hoping someone might have run across something similar to this before, or could point me to an article or post that could help me out. Thanks very much.
As indicated by Subhash Dike in the comments below, there is a similar SO question here that was able to point me in the right direction.