I'm making a bunch of Rally API calls using the C# Rally Rest API Wrapper, with great success... except when I'm trying to query into a non-default workspace. For example, take this code:
public Project GetProject(string objectID)
{
Request request = new Request("Project");
// request.Workspace = "2354109555"; //"CTO:SST";
request.Query = new Query("ObjectID", Query.Operator.Equals, objectID);
QueryResult q = _restApi.Query(request);
foreach (var result in q.Results)
{
return CreateProjectFromResult(result);
}
return null;
}
If objectID is in the default workspace, the project is found. If it is not, it is not found. I've tried setting the Workspace property to the workspace object id, the workspace name, not setting it.. to no avail. I've also gone into Rally, switched my default workspace, and verified the switch in which projects are successfully obtained.
I've also triple checked the objectIDs for the projects and workspaces.
I'm officially stumped. Does anyone have the magic answer or something else I can try?
Much appreciated,
Orlando
I think you're 99 pct of the way there. When you specify a workspace attribute on your Request object, it needs to be in the form of a ref, i.e.:
request.Workspace = "/workspace/2354109555"; //"CTO:SST";
Your code should pull from that Workspace once you make that modification.
Related
I noticed this in the debug environment where I have to do many re-installs in order to test persistent data storage, initial settings, etc... It may not be relevant in production, but I mention this anyway just to inform other developers.
Any files created by an app in its App Folder are not 'visible' to queries after manual un-install / re-install (from IDE, for instance). The same applies to the 'Encoded DriveID' - it is no longer valid.
It is probably 'by design' but it effectively creates 'orphans' in the app folder until manually cleaned by 'drive.google.com > Manage Apps > [yourapp] > Options > Delete hidden app data'. It also creates problem if an app relies on finding of files by metadata, title, ... since these seem to be gone. As I said, not a production problem, but it can create some frustration during development.
Can any of friendly Googlers confirm this? Is there any other way to get to these files after re-install?
Try this approach:
Use requestSync() in onConnected() as:
#Override
public void onConnected(Bundle connectionHint) {
super.onConnected(connectionHint);
Drive.DriveApi.requestSync(getGoogleApiClient()).setResultCallback(syncCallback);
}
Then, in its callback, query the contents of the drive using:
final private ResultCallback<Status> syncCallback = new ResultCallback<Status>() {
#Override
public void onResult(#NonNull Status status) {
if (!status.isSuccess()) {
showMessage("Problem while retrieving results");
return;
}
query = new Query.Builder()
.addFilter(Filters.and(Filters.eq(SearchableField.TITLE, "title"),
Filters.eq(SearchableField.TRASHED, false)))
.build();
Drive.DriveApi.query(getGoogleApiClient(), query)
.setResultCallback(metadataCallback);
}
};
Then, in its callback, if found, retrieve the file using:
final private ResultCallback<DriveApi.MetadataBufferResult> metadataCallback =
new ResultCallback<DriveApi.MetadataBufferResult>() {
#SuppressLint("SetTextI18n")
#Override
public void onResult(#NonNull DriveApi.MetadataBufferResult result) {
if (!result.getStatus().isSuccess()) {
showMessage("Problem while retrieving results");
return;
}
MetadataBuffer mdb = result.getMetadataBuffer();
for (Metadata md : mdb) {
Date createdDate = md.getCreatedDate();
DriveId driveId = md.getDriveId();
}
readFromDrive(driveId);
}
};
Job done!
Hope that helps!
It looks like Google Play services has a problem. (https://stackoverflow.com/a/26541831/2228408)
For testing, you can do it by clearing Google Play services data (Settings > Apps > Google Play services > Manage Space > Clear all data).
Or, at this time, you need to implement it by using Drive SDK v2.
I think you are correct that it is by design.
By inspection I have concluded that until an app places data in the AppFolder folder, Drive does not sync down to the device however much to try and hassle it. Therefore it is impossible to check for the existence of AppFolder placed by another device, or a prior implementation. I'd assume that this was to try and create a consistent clean install.
I can see that there are a couple of strategies to work around this:
1) Place dummy data on AppFolder and then sync and recheck.
2) Accept that in the first instance there is the possibility of duplicates, as you cannot access the existing file by definition you will create a new copy, and use custom metadata to come up with a scheme to differentiate like-named files and choose which one you want to keep (essentially implement your conflict merge strategy across the two different files).
I've done the second, I have an update number to compare data from different devices and decide which version I want so decide whether to upload, download or leave alone. As my data is an SQLite DB I also have some code to only sync once updates have settled down and I deliberately consider people updating two devices at once foolish and the results are consistent but undefined as to which will win.
I am developing a plugin, in my plugin I want to get another plugin ID. I use the following code:
PreferenceManager pm = PlatformUI.getWorkbench( ).getPreferenceManager();
List<IPreferenceNode> list = pm.getElements(PreferenceManager.PRE_ORDER);
String pluginid;
// restoreDefValues("org.eclipse.ant.ui");
for(IPreferenceNode node : list){
the code to find the node related to the plugin;
}
When I debug the program, I can clearly see that in variable node(IPreferenceNode), it has the value of the pluginId. However, I check the document of IPreferenceNode, it seems that the neither IPreferenceNode nor the class PreferenceNode, provide a method to return the value of pluginId. I tried node.toString() as well, couldn't get the pluginId. So what should I do? Is there any other ways to get a plugin ID from another plugin?
Preference nodes created using the org.eclipse.ui.preferencePages extension point will actually be instances of org.eclipse.ui.internal.dialogs.WorkbenchPreferenceNode. The super class of this (WorkbenchPreferenceExtensionNode) contains the plugin id.
These classes are internal so you should not try to use them directly. However they implement org.eclipse.ui.IPluginContribution which can be used and has a getPluginId() method.
So something like:
if (node instanceof IPluginContribution) {
pluginId = ((IPluginContribution)node).getPluginId();
}
should work.
Application: Connecting to BigQuery using BigQuery APIs for Java
Environment: Eclipse, Windows 7
My application was running fine until last night. I've made no changes (except for restarting my computer) and my code is suddenly giving me this error:
Application name is not set. Call Builder#setApplicationName.
Thankfully I had a tar'd version of my workspace from last night. I ran a folder compare and found the local_db.bin file was different. I deleted the existing local_db.bin file and tried to run the program again. And it worked fine!
Any idea why this might have happened?
Hopefully this will help anyone else who stumbles upon this issue.
Try this to set your application name
Drive service = new Drive.Builder(httpTransport, jsonFactory, null)
.setHttpRequestInitializer(credential)
.setApplicationName("Your app name")
.build();
If you are working with only Firebase Dynamic Links without Android or iOS app
Try this.
builder.setApplicationName(firebaseUtil.getApplicationName());
FirebaseUtil is custom class add keys and application name to this class
FirebaseDynamicLinks.Builder builder = new FirebaseDynamicLinks.Builder(
GoogleNetHttpTransport.newTrustedTransport(), JacksonFactory.getDefaultInstance(), null);
// initialize with api key
FirebaseDynamicLinksRequestInitializer firebaseDynamicLinksRequestInitializer = new FirebaseDynamicLinksRequestInitializer(
firebaseUtil.getFirebaseApiKey());
builder.setFirebaseDynamicLinksRequestInitializer(firebaseDynamicLinksRequestInitializer);
builder.setApplicationName(firebaseUtil.getApplicationName());
// build dynamic links
FirebaseDynamicLinks firebasedynamiclinks = builder.build();
// create Firebase Dynamic Links request
CreateShortDynamicLinkRequest createShortLinkRequest = new CreateShortDynamicLinkRequest();
createShortLinkRequest.setLongDynamicLink(firebaseUtil.getFirebaseUrlPrefix() + "?link=" + urlToShorten);
Suffix suffix = new Suffix();
suffix.setOption(firebaseUtil.getShortSuffixOption());
createShortLinkRequest.setSuffix(suffix);
// request short url
FirebaseDynamicLinks.ShortLinks.Create request = firebasedynamiclinks.shortLinks()
.create(createShortLinkRequest);
CreateShortDynamicLinkResponse createShortDynamicLinkResponse = request.execute();
1) Earlier this week I was able to create defects and testcases using the Create method, which took 2 arguments at the time (a string and the DynamicJsonObject). However now, it needs three. I understand that one of these is now the workspace reference. How do I go about getting the workspace reference? For creating defects and testcases, I am using an empty string, and this seems to be working correctly for me. Is this to be expected?
2) For creating test case results, I am having a bit of trouble.
DynamicJsonObject newTCResult = new DynamicJsonObject();
newTCResult["Date"] = DateTime.Now.ToString("yyyyMMdd");
newTCResult["TestCase"] = "/testcase/11271454106";
newTCResult["Notes"] = "test";
newTCResult["Build"] = "13.1.0.90";
newTCResult["Verdict"] = "Pass";
CreateResult cr = restApi.Create(" ", "TestCaseResult", newTCResult);
As of right now, absolutely nothing is happening when I run this. I was able to do this successfully earlier this week (when I was able to use the Create method with two arguments). I feel that the problem is because I don't have a valid workspace reference. I followed the suggestion of another user in a similar question prior to this which worked for earlier, however now I am having this problem.
I was finally able to resolve this. It appears that the date field needs to be converted to UTC, so my code now looks something like this
newTCResult["Date"] = DateTime.UtcNow.ToString("o");
After making that small change results were working correctly.
It's somewhat surprising that Creates on Stories or Defects work with an empty string for a Workspace ref, although I suspect that on the server-side, the Webservices API is just using Default Workspace for the User of concern.
Either way, here's how you can get a ref to the Workspace of interest:
String myWorkspaceName = "My Workspace";
// Get a Reference to Target Workspace
Request workspaceRequest = new Request("workspace");
workspaceRequest.Fetch = new List<string>()
{
"Name",
"ObjectID"
};
workspaceRequest.Query = new Query("Name", Query.Operator.Equals, myWorkspaceName);
QueryResult workspaceQueryResults = restApi.Query(workspaceRequest);
var targetWorkspace = workspaceQueryResults.Results.First();
Console.WriteLine("Found Target Workspace: " + targetWorkspace["Name"]);
String workspaceRef = targetWorkspace["_ref"];
You can then use workspaceRef in your call to restApi.Create().
I need to obtain a parent issue of given issue via SOAP API, or even using database. It seems to be very basic objective, however I didn't find any useful information in internet. Besides, I didn't find any fields in jira's db tables (jiraissue) to set the parent issue of an issue.
Additional info: Jira 5.1, c# .Net
As far as I know there is no way to do this using the SOAP directly.
One possible solution would be using the Jira Scripting Suite. You can create a post-function that will run after the Open status that will copy the parent to a custom field using getParentObject. Then you could use the SOAP function getCustomFields to get the parent.
Another solution via REST API:
Issue issue = getRestClient().getIssueClient().getIssue(task.getKey(), new NullProgressMonitor());
Field issueParent = issue.getField("parent");
if (issueParent !=null){
JSONObject jsonParent = (JSONObject)issueParent.getValue();
BasicIssue partsedIssue = null;
try {
partsedIssue = new BasicIssueJsonParser().parse(jsonParent);
} catch (JSONException e1) {
e1.printStackTrace();
}
System.out.println("parent key: "+partsedIssue.getKey());
}