I am using the podio-js package in a project designed to handle our invoicing. I am currently facing a problem in my attempts to update an item's category type field.
Here is the code I am currently running with:
const url = `/item/${item_id}/value/${field_id}`;
// newOptionId is the id of the option I want to switch to
const requestData = JSON.stringify({[field_id]: newOptionId});
const responseData = await this.podio.request('PUT', url, requestData);
I tried several other formats as described here: https://developers.podio.com/doc/items/add-new-item-22362, but every time I get the same result, it unselects the current selected option and leaves my category type field with no selected option.
Please provide me with the correct requestData format as I think the problem is coming from there.
Thanks.
The request format {value: your_id} is not supported anymore, it worked for me using this.podio.request('PUT', url, [myId]) to update a category field.
#Podio team: it would be cool to update and complete your documentation.
There are 4 slightly different ways of setting value to a field.
1. One when creating new item Podio: create item
2. Another one when updating whole item Podio: update item. This includes for example reverting to specific revision or setting each and every field including meta-fields like files, reminders, recurrences, etc.
3. Yet another one is updating item value Podio: update item value, which is updating whole item but only fields. So, it only accepts content that is inside fields parameter for methods #1 and #2 above.
4. And one more is for updating item field values Podio: update item field values. This one expects values for single field and only content of fields['field_id'] from methods #1 and #2 should be passed here.
Each way requires different format for value and uses different url.
I've updated documentation to include 2 cURLs examples for last 2 methods to make it clear, but will be happy to include additional explanations if you provide them.
Related
I need to create an item in SP list. Unfortunately it does not work due to a Lookup field to another list.
Both lists exceed the list view threshold.
I tried more ways but got the same error.
Is there away to fix it?
attempt01
attempt02
Try using a SharePoint REST call instead. In my example below I'm updating an item, but you can create items too by simply using the PUT method.
The data to use is:
Site Address = Your full site URL.
Method = PUT to create new or PATCH to update existing.
Uri = The REST call portion of the URL, using the GUID ID of the list in question and the item ID of the specific item to be updated.
Headers = If-Match use *, Content-Type use application/json;odata-verbose, Accept use application/json;odata=verbose
Body = {"__metadata":{"type":"SP.Data.MyListListItem"},"MyField":"NewFieldValue","My2ndField":"New2ndFieldValue"}
NOTE: The double underscore before metadata.
NOTE: type is defined as "SP.Data. concatenated with the List Name, concatenated with ListItem"
NOTE: Multiple fields are updated in "name":"value","name":"value" pairs separated by commas.
I have a content type post where the entries have a categories attribute, which is an Array of Links (to a category content type).
I want to fetch all posts that have been tagged with a certain category. That is, Post entries where fields.categories[any link sys.id] = MyCategoryId.
I can only find an example only where the reference field is a singleton, not an array.
Would love any help, thanks!
You could specify your query like this:
/spaces/YOURSPACEID/entries?content_type=CONTENTTYPEID&fields.categories.sys.id=SOMEID
Notice that a content type restriction is necessary as we are filtering on a field property.
Also note that this only works because we're filtering on a system property directly accessible from the actual entry returned. If you wanted to filter on another property of the Category content type, for example title or description that is not currently supported.
Here's also a link to the official documentation including examples and explanations for the search api: https://www.contentful.com/developers/docs/references/content-delivery-api/#/reference/search-parameters/query-entries
EDIT: Rephrased issue
I think there is either a bug or I am doing something wrong.
I add a field to the type Blogpost. This field is of type
Contentpicker. I call it Related Page.
Then I create to regular pages (ContentType Page).
I create 4 blogposts. Two blogposts get PageOne as selected value in the RelatedPage field. The other two posts get PageTwo as selected value in the RelatedPage.
Now I create a query with filter ContentType is BlogPost. And a filter with Blog Post.Related Page equals {21} (that is the Id of PageOne).
I would expect to get results BlogPostOne and BlogPostTwo. Instead I don't get results. Actually I wanted the pageid to be retrieved from the page the widget is placed on but couldn't get it to work, so I reduced back to a predefined value instead of dynamic for the filter. But like I said no results.
So is the query wrong and how should I do it then. Or is there a bug with filters for ContentPicker fields.
P.S. I will also submit an issue in Codeplex.
UPDATE
In Tokenizer all the values that contain { } are being seen as tokens and therefore are replaced. The problem is that the Ids of content items in a contentpicker field are stored with accolades. So when having {21} as the value for the filter, 21 gets tokenized and since there is no value for this token the value becomes empty. When skipping the tokenizer it works (while debugging). But one cannot skip the tokenizer, because it is very legitimate that there is a token present.
So I believe there is a bug with either the tokenizer, or the way the ids are stored in the contentitem field for contentpicker. I think it can be solved by changing the contentpicker to store numbers separated with comma's but without the accolades.
have you tried using the alias of the page instead of content id as the identifier? e.g. "/about-us", like you do in the layer rules.
When should one use Fields from the CMS and when to use class properties and database fields?
My scenario:
Created a product content part with fields usage (text) and price (double). Then I have created a contenttype product and added the part.
I could also have created a product record in models and added a product table. And a part with driver etc.
At first glance I dont see difference besides option 2 requiring programming.
However I did encounter a problem:
In option 2 I could use repository and create a lot of items programmatically.
In option 1 I could create product content items but was not able to fill in the fields of the product part (no errors, but fields remained empty)
So when to use option 1 and when option 2?
And is my problem with option 1 related to that option?
EDIT: Clarifiation of problem with option 1
I have created a productpart. To the productpart I have added the field price which is a decimal and I have added a field Usage of product which is a text field.
In the code I have the following:
dynamic item = _cm.New("Product");
item.TitlePart.Title = "Mijn dummy product";
item.BodyPart.Text = "Some dummy text for this product";
item.ProductPart.Price.Value = new decimal(20.5);
item.ProductPart.Usage.Value = "Some dummy usage of this product";
_cm.Create(item);
After running the code, the product is created with the correct title and body text, but Usage and Price come up emtpy.
I also tried it with the item.As<> method. But that does not compile to As since I have not created an object with that name.
A difference is that fields can only be queried against with projections but more generally parts and fields are for different usage: parts are meant to be reusable, not fields. Price for example is going to be a characteristic of any product so it should probably be a part property. Usage, I don't know, it sounds fairly specific to what you're doing and may be better done as a field.
As for your problems with option 1, it's hard to say without seeing your code but chances are you're doing it wrong.
Apparently the item has to be created first before accessing the contentpart and fields. At least it worked for me.
Please verify if my analysis is correct. If so I will mark it an answer, as well as the answer of Bertrand.
The code now looks like this:
var item = _cm.New("Product");
item.As<TitlePart>().Title = "Mijn dummy product";
item.As<BodyPart>().Text = "Some dummy text for this product";
//Create first before accessing the contentparts that are dynamic.
_cm.Create(item);
//And then access the product via dynamic object.
dynamic dyn = item;
item.ProductPart.Price.Value = new decimal(20.5);
item.ProductPart.Usage.Value = "Some dummy usage of this product";
How do you create a lookup column to a Document Library that uses the 'Name' of the document as the lookup value?
I found a blog post that recommends adding another custom field like "FileName" and then using a item reciever to populate the custom field with the value from the Name field but that seems cheesy.
Link to the blog in case people are interested:
http://blogs.msdn.com/pranab/archive/2008/01/08/sharepoint-2007-moss-wss-issue-with-lookup-column-to-doc-lib-name-field.aspx
I've got a bunch of custom document content types that I dont want to clutter with a work around that should really work anyway.
I created a one step workflow to set the title from the name, fired on modify and created. Seems to work and took seconds to create.
One way you can do this (although not the easiest way) is by creating a custom field type that extends the SPFieldLookup class. SharePoint's field editor for Lookup fields purposefully hides any columns types that aren't supported by Lookup fields, but you can create a field editor for your custom field type that shows them.
However, I have created a Lookup column that points to a Name column in a Document Library before, and it probably doesn't work like you'd expect. While the value stored in the lookup column is valid, it doesn't show up right in List view or on the View Properties form.
The solution you posted may actually be the best way to handle this. Lookup fields require some kludges if you want to handle more complex scenarios, but that's because they're not meant to provide the same functionality as a foreign key relationship in a database.
Coding in any form always scares me. So Here's what I did: I simply renamed the Stupid "Title" Field to something else, say "Keywords", since you cant do anything with that field: cant even make it mandatory.
Then I created another Single line field called "Title" and used this field for the Lookups
Well there is a simple solution to that and in might work in some case.
In the nutshell if you make the Title field Mandatory, this will force the user to enter a title. In that manner we can use title field as a lookup field.
Now How to do that?
One you are done create a document library go to the library setting. Select Advance Setting and Select Yes for the option "Allow management of content types?".
Then go back to the Library setting and Under content types select the "Document" Content type. THen Select Title Column and then Select "Required (Must contain information)" and say OK.
Now try uploading a document to this document library. You will see Title field in the form.
Hope this helps
Cheers
Vaqar
You have to add the field as XML with the ShowField as 'FileLeafRef'
var XmlFieldDefinition = "<Field DisplayName='myLookupColumn' Type='LookupMulti' StaticName='myLookupColumn' Name='myLookupColumn' Required='FALSE' List='THE LOOKUP ID HERE' WebId='THE WEB ID HERE' UnlimitedLengthInDocumentLibrary='TRUE' Mult='TRUE' Sortable='FALSE' ShowField='FileLeafRef' />"
Field fld = fieldCollection.AddFieldAsXml(XmlFieldDefinition, true, AddFieldOptions.DefaultValue);
ClientContext.Load(fld);
ClientContext.ExecuteQuery();