I don't see anything listed in the changelog about the canonicalUrl field being removed from a Foursquare user object, but I am no longer seeing that field being returned.
Specifically, when running a venue details query, the user object located inside of the tips field is missing. I am using v=20120524 as the version.
No it's no longer available. But you just need the user id to generate it :
https://www.foursquare.com/user/{user_id}
Related
I'm trying to query for some SP list items, all is working fine except I can't seem to expand a custom column of type Person.
I can see the createdBy and lastModifiedBy expanded and even includes the AAD user id, which is great and also leads me to think what I want is possible!
But mine is a custom column.
I'm running this and can only seem to get the SP user list id and the user's display name...neither of which are much use.
/items?expand=fields(select=UserLookupId,User)
Ideally I'd like to get the AAD user id as per createdBy and modifiedBy field, but the email would suffice.
Otherwise the only way I can see is to query the User Information List (using the UserLookupId) to get the email?
Thanks
This appears to be correct assumption:
Otherwise the only way I can see is to query the User Information List
(using the UserLookupId) to get the email?
for non-system user fields, it is indeed a way to go, but there are some distinctions whether user field is multi-valued or single-valued.
If Approvers is a multi-valued user field, then the following query:
https://graph.microsoft.com/v1.0/sites/{site-id}/lists/{list-id}/items?$expand=fields($select=Approvers)
returns email and id properties along with displayName property for user field value.
While for single-valued user field only id (available via {userfield}LookupId property) and displayName properties could be requested via items endpoint, for example:
https://graph.microsoft.com/v1.0/sites/{site-id}/lists/{list-id}/items?$expand=fields($select=Approver,ApproverLookupId)
So, indeed User Information List needs to be utilized to request additional user properties, for example:
https://graph.microsoft.com/v1.0/sites/root/lists('User Information List')/items/{item-id}/?$expand=fields($select=Email)
where item-id corresponds to user field lookup id
This was my experience modifying the
Build Angular single-page apps with Microsoft Graph. In the examples below, I changed my id's out with the default text.
Here is
The Finished Project on thier github
In Graph Explorer, this worked. You can verify it at the Microsoft Graph Explorer.
https://graph.microsoft.com/v1.0/sites/{site-id}/lists/{list-id}/items?expand=fields($select=id,Title)
In the app/graph.service.ts in the app, this did not work. Even though you would expect it to based on the graph explorer.
.api('/sites/{site-id}/lists/{list-id}/items?fields($select=id,Title)')
Changing the app/graph.service.ts api call worked.
.api('/sites/{site-id}/lists/{list-id}/items?')
.expand('fields($select=id,Title)')
The result looked like this:
fields: {
#odata.etag: ""d6f5b6ea-9f90-452d-98ba-e838f58d3359,1"",
Title: "IT SPECIALIST (MID)",
id: "20"
}
Here's an example site id:
some.sharepoint.com,9dk062b-2e54-4e4f-b71a-cdb74f42cc44,c6cf6b0a-cc7c-41fd-a76a-ef8f97e8a22f
Here's an example list id.
8eg8c29a-5555-4cfc-bfa4-0e907488f781
The end url won't have any {} in it.
I know how to get the last document created by couchDB :
http://<IP>:5984/<DBname>/_changes?descending=true&limit=1
But my question is how to get the doc ID of the first document?
You can exclude the descending=true parameter from the URL and use only http://<IP>:5984/<DBname>/_changes?limit=1. However, according to the docs:
Only the most recent change for a given document is guaranteed to be provided, for example if a document has had fields added, and then deleted, an API client checking for changes will not necessarily receive the intermediate state of added documents.
So if the first document has been modified, it won't appear as the first item in the changes feed.
A way to achieve this would be to add a date_created timestamp in the documents when they are created and use a view that emits this field so that the documents are sorted by creation time.
I have a field on one of my base page types which I need to update programmatically from an external data feed, so that it can be included in my Smart Search index.
The documents are versioned, but I want to update the published value of this field regardless of checkout state, and obviously avoid any sort of overwrite when documents are checked in.
The field will not appear on the editor form -- or ideally, would conditionally display for Global Admins.
It appears that using the API to update the document without doing a CheckOut fails silently. However if I do a Checkout/Update/CheckIn on a checkout-out page, the author will lose their work I assume?
Any way to handle this "versionless" field via the Kentico data model and API?
I don't think there is a way around updating checked out pages. You can update the page type table directly, but as you mentioned, it will be overwritten when they check in. You could update the version history I believe to make changes to the current data that is checked out, but again, I think that will be lost if the user cancels.
The only way I can think of to solve your issue is to create another table that maps the values you want to the page. Then you don't have to worry about the pages being checked out, you just need to grab the documentID or something. Since the value isn't displayed to the editor, you just have a field that does a lookup on this table.
The preferred and right way is using the API but as you stated, it causes problems if a user has something already checked out and working on it or it's in workflow and not published yet.
If the field you're updating is page type specific, there is one thing specifically I can think of and that's going directly to the database to the page type's database field and perform an update to that field.
Note: this is not recommended unless you know specifically what you're doing and have done full testing on it
The down side of going direct to the database is this will not update the current version since you're using check in/out and workflow. You will also need to update the checked out and current version which means you need to:
Go to the Document itself in the cms_documents table and get the document you are working with.
Then using the fields DocumentCheckedOutVersionHistoryID and DocumentPublishedVersionHistoryID' you can get the version history IDs of the document from theCMS_VersionHistory` table.
Then you can perform an update to the CMS_VersionHistory and your custom page type fields.
You will then need to look in the CMS_WorkflowHistory table and find out if that document is in workflow and in what step.
After you have that workflow history step, use the VersionHistoryID field to go back to the CMS_VersionHistory table and update that record with your data.
Again, not an elegant solution since you are using check in/out and workflow but after some trial and error and testing you should be able to figure it out.
UPDATE
You may also be able to add a custom table or some other linked database table which will allow you to create a global handler. The linked table would be where you perform your updates via API and other calls without versioning or workflow. Then when a user updates a specific page type you could do a check to see when the last time that linked table was updated and update the field(s) you need on update of that particular page (of course by node and document IDs).
Unfortunately you'll have to check it in and out with API. See examples here.
Also you might need to publish it in order to reflect changes on the live site.
A user is not able to edit a form. The user had editor access and i've tried to replicate the issue using a test user and providing the same access as the user, but to no avail. I came across a link which told me that there is something called as additional ACL control in Lotus Administrator. I'm not sure if this actually can influence the editing privileges. I don't think that could be the problem. Anyway, please let me know if you can figure out the problem.
Additional info:
The user is a part of a distribution list(multipurpose group) and the group has editor access.
The default access to the form is Author, with a authors field in the form.
The user has 2 names mentioned in the names.nsf person document. An old name and a new name.
The required user roles are assigned to the group.
Let me know if you need additional info.
With Editor rights she should be able to edit. Please check her rights by placing a Computed Text with #UserAccess on the form.
Or if she is using a Notes client she can simply click the "Security" icon in the bottom toolbar of the Notes, near the right corner. It will open a dialog box telling what is her access level to the database.
A few things to check:
is the user listed explicitly in the ACL? If so, those rights will take precedence over any groups she's in.
check the authors field carefully. Best option is to look at the properties of the doc she's editing via the Notes client and examine the authors field in the dialog. That will let you see if any code altered the list of allowed authors. If she's an editor this shouldn't matter but based on the behavior you are seeing it sounds like she's acting as an author.
Make sure that the names in the authors fields are being stored in the canonical format and are not abbreviated or in common name. EG: using Herny Newberry/MyOrg does not work while using CN=Henry Newberry/O=MyOrg does.
The issue is solved. There was some problem with the user configuration. Thats the reason she was getting author access even though she was an editor. After reconfiguration of her Notes client, she'd able to edit the form now. Thanks to all of you for your help.
Although already answered and a solution found, it should be noted that user-names listed in the 'fullname' field of the NAB person record should list the current or 'newname' first as other names may not be recognized.
Has there been a change to the core venue field specials?
I'm using Venue Detail request (https://developer.foursquare.com/docs/venues/venues) to retrieve Venue Detail. As usual this request returns a "venue" for a response field.
What seems to have changed is the core venue field "specials". This now appears to be returning the same response fields as Specials/list ( https://developer.foursquare.com/docs/specials/list).
This requires iteration on specials.items as opposed to specials.
Looking at https://developer.foursquare.com/docs/responses/venue the Core venue field "specials" still should be returned as an array.
I'm trying to find in the change log where this may have changed?
The venues specials object is now using the standard count and items format that other lists in the api use.
The new format is only for clientversion 20120120 and later. Older versions get the old format.
We'll be updating the docs/changelog shortly.