We are using the below API to get key versions. Our assumption is it returns the list sorted by version (latest version first). Is that correct?
https://learn.microsoft.com/en-us/rest/api/keyvault/getkeyversions/getkeyversions
Is that correct?
Yes, based on my test, the first one is the latest version. It is ordered by created attributes.
If we want to get the latest version, we also could use Get key API
https://{keyvaultName}.vault.azure.net/keys/{keyName}/versions?api-version=2016-10-01
It will return the default current(latest) version of key
Related
I am pulling a file from on premise TFS source control using the Rest API. I can't find on premise specific documentation, but it seems to be very close to version 4.1 of the Azure Get Item call. According to this documentaiton, it should return a TfvcItem object which has a lot of metadata including the version. However, when I make the call it only returns the file contents (the content field of the documentation's TfvcItem).
How do I get the current version of the file?
I need the version when I check itin with create changeset. I don't need it for any other reason, so if you know another way to check in an edited file that would help.
Instead of using Get Item API, some related REST APIs are not documented. For these REST APIs we can use tools such as Fiddler or directly press F12 - network in Chrome to track them.
You should use below API to fetch latest changeset version of a file:
post https://dev.azure.com/{organizationname}/{Projectname}/_api/_versioncontrol/history?__v=5
For body:
{"repositoryId":"","searchCriteria":"{\"itemPath\":\"$/MyFirstProject/Main/1.txt\",\"itemVersion\":\"T\",\"top\":50}"}
itemPath is your server path of the file.
From the response, you will get the version info such as "version": "139", instead of the file content.
Not sure your detail version of TFS, I was using Azure DevOps Service for an example. There maybe some difference for different TFS version. You could track the detail API on your own side.
More detail info kindly take a look at this question: VSTS Release API Documentation
Had the same issue. You can get item metadata by specifying "scopePath" URI parameter, instead of "path". Microsoft example in API documentation seems incorrect, as it indeed returns only item content: https://learn.microsoft.com/en-us/rest/api/azure/devops/tfvc/items/get?view=azure-devops-rest-6.0#get-item-metadata-and/or-content-for-a-single-item.
I need to support a special release per user (or group), and I want each user will auto-update to a new available release only if it's suitable for him (by some kind of logic in the backend).
I've tried to do so by using electron-builder's electron-updater module, and also by using Electron's autoUpdater built in module, but it seems that both always fetch the latest version when calling autoUpdater.checkForUpdates.
I've seen that when deploying my own update server, some of them (such as nuts) support a download url for a specific version.
as described using nuts
Specific version for detected platform: http://download.myapp.com/download/1.1.0
but there seem to be no support to request a specific version in the app itself using autoUpdater.
summarizing all this up: How can I achieve auto-update to a specific release other than latest?
The solution for me was channels.
appUpdater.channel (getter and setter)
Define the channel which the Auto-Updater will follow (see the
auto-update with channels tutorial) using appUpdater.channel = 'beta'
or get the current channel with currentChannel = appUpdater.channel.
Note that channels are not supported when using GitHub as a provider (for now), as described in electron-builder autoUpdate documentation:
channel String - Get the update channel. Not applicable for GitHub. Doesn’t return channel from the update configuration, only if was previously set.
You can set the channel name to anything, and can even dynamically (if needed) direct your users to pull updates from that channel.
You can also edit the {your-channel-name}.latest file manually and add parameters that will help you determine whether the current "asking for update" user should consume the certain version (in the update-available event from the updateInfo parameter for example).
I just upgraded a docker container to Neo4j 3.4, excited to start using some of its new features, most importantly their native support for spatial data.
I tried running a test query to create an example node with a point like so:
CREATE (n:LocationNode { name: 'New York', location: point({latitude: 0.0, longitude: 0.0}) })
The result was an exception thrown which reads as follows:
Neo.DatabaseError.General.UnknownError: Current record format does not support POINT_PROPERTIES. Please upgrade your store to the format that support requested capability.
I am unaware of any configuration required to add support for spatial data. Is there anything I need to configure or enable to support point properties?
Thanks in advance.
I think it would also have worked if you set allow_store_upgrade=true before starting Neo4j 3.4 on an older store. Neo4j can run with older store formats without requiring an upgrade, but in that case you will also not get the features of the new formats (like support for Point and DateTime as property types).
Note that this does not also cover index formats, so even if you allow_store_upgrade=true, pre-existing indexes might not support the newer features (like native indexes for strings, datetime and point). If you also want to upgrade the indexes to get the newer features, drop and recreate them.
I solved the issue by creating a new store by backing up the old data, deleting the old graph.db store from the previous version and creating a new one.
Classic me, trying to fix something for hours, finally deciding to place a question here, only to find a solution minutes later.
While performing the checkin in sharepoint my file version is getting updated by 0.2 but it should be 0.1.
This is happening because after checkin i am uploading the edited file again which further increase the version number by 0.1.
How i can prevent the version update in case of uploading the edited file?.
i have used below method and in both case version is getting updated
case 1 /_api/web/getfolderbyserverrelativeurl('%#')/Files/add(url='%#',overwrite=true)
Method:POST
body:content of file
case 2
/_api/web/getfilebyserverrelativeurl('%#')/$value
Method:POST
body:content of file
Have you try check out/check in ?
First Check out your document.
Do all your update (field values, content of file)
After all your update, check in (major or minor version)
Your version should be upgrade once (you create new version when you check out only visible by you, you can work on you doc, when you check in the version is validate and all users can see it)
I'm using the Jira (version 5) Rest API to Delete a version and like the documentation tell me, I pass the moveFixIssuesTo and moveAffectedIssuesTo to transfer issue from the deleted version to a other version. This just doesn't work. The issues that has AffectedVersion / FixVersion set to the deleted version have no version after the delete.
/rest/api/2/version/{id}?moveFixIssuesTo&moveAffectedIssuesTo
Here an example of the call :
http:// /rest/api/2/version/16238?16237&16237
My {id} is an existing versionId I want to delete.
moveFixIssuesTo and moveAffectedIssuesTo are versionId of the version I want the issues to be transfer.
If I do the same kind of action from the Web UI of Jira ( Deleting a version and setting in the form the version to transfer the AffectedVersion and FixVersion, It work correctly and I see the new version in the field of the issues.
Any idea why this does not work as expected ?
I think if you changed implementation of service operation - you must use another url for this operaton. For this thing you can change value of attribute version in rest tag in the file atlassian-plugin.xml:
<rest name="My Rest Resource" key="custom-rest-resource" path="/my-custom-resource" version="1.0"/>