I'm quite new to WSO2. Although I managed to find a quick hack to ignore the version number from the url path when calling my services, I would like to know if there's an efficient way of doing this: /Personal/1.0.0/Members?tenantId=1&entityNumber=1
Make that API with default version in the Implementation Tab by checking "Make this default version" checkbox. Check here for more and the below image for how to do it.
Once you have checked that "Make this default version" option, You can two URLs for the API in the Store like below
A default API can be invoked without specifying the version number in
the URL. For example, if you mark http://host:port/youtube/2.0 as the
default version when the API has 1.0 and 3.0 versions as well,
requests made to http://host:port/youtube/ get automatically routed to
version 2.0.
If you mark any version of an API as the default, you get two API URLs
in its Overview page in the API Store. One URL is with the version and
the other is without. You can invoke a default version using both
URLs.
From APIM 1.9.0 onwards there is a new feature introduced as "version strategy" where you can provide {version} tag in the context in any place. As an example, if you provide the context as api/{version}/test and in the version field as 1.0.0v it will replace the URL pattern as api/1.0.0/test.
Same like that if you really need to get rid of version number apart from the above answer you can provide a text in the version field since it allows text as well.
E.g.,
In context -> api/{version}/test and in version -> text will make the url pattern as api/text/test
But please note this is not recommended since version is supposed to use version number. You can use the default url as explained in Abiraman's answer. But since version field number allows numeric and text for a situation like -> 1.0.0v, 1v, 1.0.b you can try this as well.
Related
Successfully build Commerce 2011_7 with Spartacus 3.3 last week (using the standard instructions for B2B Commerce) and all appears to function on initial tests.
This week, I've gone to test the Standard Order Flows with mark.rivers#pronto-hw.com and noticed that the "Self Service" buttons that typically appear against a placed order in My Account are missing, and these are definitely there in the JSP Storefront and earlier versions of Spartacus.
I'm able to follow the instructions but not a developer so asking if anyone knows whats causing them to 'not appear' and could help me get them back please - have supplied a screenshot with the Console open as well.
The two lines in the console that concerned me were:
spartacus-storefront.js:18398 No component implementation found for the CMS component type 'AccountOrderDetailsOverviewComponent'.
Make sure you implement a component and register it in the mapper.
spartacus-storefront.js:18398 No component implementation found for the CMS component type 'AccountOrderDetailsReorderComponent'.
Make sure you implement a component and register it in the mapper.
enter image description here
order self service was added in 1.4 but you need release 2005.
see https://sap.github.io/spartacus-docs/cancellations-and-returns/
it's possible that with installation of 3.3, the cancel/returns code wasn't installed? we transitioned to many smaller libraries for 3.3. but also you need cms content in the backend (which looks like you have).
I've integrated Testlink with Jira using below xml
<issuetracker>
<username>xyz</username>
<password>#123</password>
<uribase>abc.net/projects/KEY/</uribase>
<uriapi>abc.net/rest/api/latest/</uriapi>
<uriview>abc.net/browse/</uriview>
<projectkey>KEY</projectkey>
<issuetype>1</issuetype>
</issuetracker>
I am able to link existing jira issue in to test link.
But create issue window contains Version field which would not alow me to enter any value or not giving any suggestion as displayed in below image.
I've tried to create version in jira but it doesn't work.
So,
What value i should enter/configure for version field ?
What is use of <issuetype>1</issuetype> ? can we provide any other value?
How to link new field on create Issue window?
4.Version is mismatched with jira field Versions.
I'm not sure which version of JIRA REST API you are using but the tutorial for the v2 says:
Just like everyone else in the real world, we're faced with time and resource constraints. Supporting two serialisation formats requires more time than just a single one. Hence, for our initial release of the JIRA REST API, we decided to provide "more stuff in JSON" rather than "less stuff in JSON and XML".
So I'm not sure about the XML support. I have no experience with Testlink, but I guess it's using some kind of serialiser at the back end.
If you check the Create issue endpoint, there is no version field. I guess it will be the versions field instead. In JIRA projects can have multiple versions. You can get a list of versions from the Get project eversions endpoint.
Issue type is an ID of issue type you want to use for your issue. You can get a list of project specific issue types from the Get issue all types
endpoint.
I'm not sure about this
Check the first point
This version field is empty because you have not specified any version for your project in JIRA. In my case it was Fix version in JIRA. Currently the rest API is getting an empty list of versions. You can try
curl -X GET http://example.com/rest/api/2/project/KEY/versions
-H 'authorization: Basic dtgzkisVlbyhsuYWhtYijdsdidjjsidDkw'
This will give you an empty list.
Once you set FixVersion in for your project in JIRA, this API will return the list of available versions for your project and the Version field will be populated with those versions.
PS: use your own authorization headers. You can use [Postman][1] for this purpose.
Use case: A user can bookmark a link which contains a pdf-document for downloading or viewing it online.
The url contains a version number provided by liferay.
Is it possible to ensure that you always get the latest version of the bookmarked pdf-document even if the url was bookmarked months ago ?
The uploaded pdf-documents are versioned by Liferays document library.
Of course you can remove the version number from the pdf-link but this i guess would lead to the problem that your browser will cache the document and you are again not sure if your pdf- document is the latest one.
Does anyone can drop me a hint ?
No, you cannot do it, so the only solution is to make a hook for the method that fetches the document. In this case I think you should override some of the DLFileEntryLocalServiceUtil methods. With these two links you will have enough information:
Override a service - https://dev.liferay.com/develop/tutorials/-/knowledge_base/6-2/overriding-a-portal-service-using-a-hook
DLFileEntryLocalServiceUtil - https://docs.liferay.com/portal/6.2/javadocs/com/liferay/portlet/documentlibrary/service/DLFileEntryLocalServiceUtil.html
Good luck!
So, I know just recently that google maps API is now available in SSL (here).
My question is, how do I retro-fit my http google maps api script to use this?
So my http Google maps API script call looks like this:
http://maps.google.com/maps?file=api&v=3&sensor=false&key=########
They suggest via this link that to use SSL it should be this:
https://maps-api-ssl.google.com/maps/api/js?v=3&sensor=false
I've tried retro-fitting this into my old URL format like so:
https://maps-api-ssl.google.com/maps/api/js?v=3&sensor=false&key=########
but that no longer displays the map.
Does anyone have any suggestions on what the URL should be?
Thanks
Try this line:
https://maps.google.com/maps/api/js?v=3.5&sensor=true
Google btw suggests that you explicitly enter what version of the api you are going to use. Just entering v=3 will always return the latest version, at the moment 3.5. I believe that the current stable version is 3.3.
As Trott wrote in his answer, api key is no longer needed.
You don't need an API key to use v3, but I suppose it probably doesn't hurt. General things to try:
Open your browser's JavaScript console and see if it is reporting any problems when you load the page.
Remove the API key
Change & to just &
Copy and paste the exact link text you put above into your code, because that link text is working for me. I'm referring to this:
https://maps-api-ssl.google.com/maps/api/js?v=3&sensor=false&key=########
Of course, change ######## to your API key (or just remove it altogether).
Our company publishes our software product's documentation using a custom-built content management system using a dynamic URL namespace like this:
http://ourproduct.com/documentation/version/pageid
Where "version" is the version number to which the documentation applies, and "pageid" is a unique string which identifies that page in our back-end content management system. For example, if content (e.g. a page about configuration best practices) is unchanged from version 3.0 and 4.0 of our product, it'd be reachable by two different URLs:
http://ourproduct.com/documentation/3.0/configuration-best-practices
http://ourproduct.com/documentation/4.0/configuration-best-practices
This URL scheme allows us to scope Google search results to see only documentaiton for a particular product version, like this:
configuration site:ourproduct.com/documentation/4.0
But when the user is searching across all versions, we don't want Google to arbitrarily choose one of the URLs to show in results. Instead, we always want the latest version to show up. Hence our planned use of rel=canonical so we can proscriptively tell Google which URL we want to show up if multiple versions are being searched. (Users who do oddball things like searching 2 versions but not all of them are a corner case, so we don't care which version(s) show up in that case-- the primary use-cases we care about is searching one version or searching all versions)
But what will happen to scoped searches if we do this? If my rel=canonical URL points to version 4.0, but my search is scoped to 3.0, will Google return a result?
Even if you don't know the answer offhand, do you know a site which uses rel=canonical to redirect across folders in a URL namespace. If so, I could run a few Google searches and figure out the answer.
The rel=canonical link element helps search engines to determine the URL that they should index, so ultimately, by specifying it for a URL, you're telling them to drop the old version and only to index the new version. In practice, it might be that both versions are indexed for a while (depending on how they're discovered and crawled), but in the long run only the canonical will generally remain indexed. In other words, if you do this for your site, over time the site:-query results for the old versions will drop (which probably makes sense).
If you need to have both versions indexed, then I wouldn't use the rel=canonical link element, I'd just link from the old versions to the new versions (eg "The current version of this document can be found at X").
Wikia uses rel=canonical link elements fairly extensively, though I don't think they use it in folders, but you can still see the results for individual URLs.