I'm brand new to JIRA API programming.
I need to get a list of unresolved issues.
From the API, the function getIssuesFromFilterWithLimit() looks like a likely candidate. And I have also read on another SO thread that an issue is unresolved if the system Resolution field contains no value.
So, how would I construct the call, e.g (I'm fishing here) in pseudocode:
getIssuesFromFilterWithLimit(resolution=NULL)
Or is there a better way to do this?
According to the JIRA RPC documentation, getIssuesFromFilterWithLimit uses a predefined JIRA filter to retrieve issues. It will not work with a caller supplied query or search terms.
To use this method, you will need to define a filter in JIRA so it can be referenced in the getIssuesFromFilterWithLimit call.
An alternative would be to use getIssuesFromJQLSearch which works with a caller supplied JQL expression to retrieve issues. The JQL to return issues with now resolution would be resolved is EMPTY.
Related
I spent almost a full day debugging why my client can't post any forms, until I found out the anti-forgery mechanism got borked on the client-side and the server just responded with a 400 error, with zero logs or information (turns out anti-forgery validation is logged internally with Info level).
So I decided the server needs to special handle this scenario, however according to this answer I don't really know how to do that (aside from hacking).
Normally I would set up a IAlwaysRunResultFilter and check for IAntiforgeryValidationFailedResult. Easy.
Except that I use Api Controllers, so by default all results get transformed into ProblemDetails. So context.Result as mentioned here is always of type ObjectResult. The solution accepted there is to use options.SuppressMapClientErrors = true;, however I want to retain this mapping at the end of the pipeline. But if this option isn't set to true, I have no idea how to intercept the Result in the pipeline before this transformation.
So in my case, I want to do something with the result of the anti-forgery validation as mentioned in the linked post, but after that I want to retain the ProblemDetails transformation. But my question is titled generally, as it is about executing filters before the aforementioned client mapping filter.
Through hacking I am able to achieve what I want. If we take a look at the source code, we can see that the filter I want to precede has an order of -2000. So if I register my global filter like this o.Filters.Add(typeof(MyResultFilter), -2001);, then the filter shown here correctly executes before ClientErrorResultFilter and thus I can handle the result and retain the transformation after the handling. However I feel like this is just exploiting the open-source-ness of .Net 6 and of course as you can see it's an internal constant, so I have no guarantee the next patch doesn't change it and my code breaks. Surely there must be a proper way to order my filter to run before the api transform.
GraphQL is well-known for its easy to maintain backward-compatibility of APIs defined with it. You're supposed to just add new fields/types every time you need them and never remove old ones, only mark them with #deprecated directive. Thus, your server could evolve independently of its clients versions.
However, I have a quite opposite problem: we have many independent servers, some of which could not be updated ever, and client (potentially) could connect to anyone of them. Thus, when client adopts new fields in API types, that were introduced in some newer server, and then it connects to the older one, it will get the error, because it will try to query fields that do not exist on that server.
So the question is: is there some known approach on how to handle this type of situation in GraphQL?
The only thing I came up with is to have a top-level query field, that will return a list of supported types, as a string list. Thus, whenever you want to add a new filed in the existing type foo, you just add a new type foo2 and add this type to the list of supported types. Thus the client could decide what types it can use and, accordingly, what features it could show. However, this looks quite scary due to, well, graph nature of GraphQL: it is very hard to guaranty that clinet's query won't get to some unsupported type via some quirky path.
The other solution is, of course, just version the whole API and treat any change to schema as incompatible API version. But this looks, well, either too stiff, or too laborious to maintain.
P.S. I suppose, that, maybe GraphQL is just not a good solution for this type of situations, but, as usually happens, we decided to go with GraphQL far before we could foresee these use-cases.
... usually there is no state with 'could not be updated ever' servers
How it wouldn't affect REST servers? Just responds with 404 for /api/Vxxx - clearly not supported new version? Better DX than with graphQL? I don't think so.
Possible solutions:
provide APIs with some query version (+loadable schema) - ask devs to use at app beginning (with login query);
add 'field introduced in API version xxx' in docs;
keep a list of servers with supported API versions;
some service/server queryable for [nearest] server with minimum API version xxx.
I'm trying to figure out if FeathersJS suits my needs. I have looked at several examples and use cases. FeathersJS uses a set of request methods : find, get, create, update, patch and delete. No other methods let alone custom methods can be implemented and used, as confirmed on this other SO post..
Let's imagine this application where users can save their app settings. Careless of following method conventions, I would create an endpoint describing the action that is performed by the user. In this case, we could have, for instance: /saveSettings. Knowing there won't be any setting-finding, -creation, -updating (only some -patching) or -deleting. I might also need a /getSettings route.
My question is: can every action be reduced down to these request methods? To me, these actions are strongly bound to a specific collection/model. Sometimes, we need to create actions that are not bound to a single collection and could potentially interact with more than one collection/model.
For this example, I'm guessing it would be translated in FeathersJS with a service named Setting which would hold two methods: get() and a patch().
If that is the correct approach, it looks to me as if this solution is more server-oriented than client-oriented in the sense that we have to know, client-side, what underlying collection is going to get changed or affected. It feels like we are losing some level of freedom by not having some kind of routing between endpoints and services (like we have in vanilla ExpressJS).
Here's another example: I have a game character that can skill-up. When the user decides to skill-up a particular skill, a request is sent to the server. This endpoint can look like POST: /skillUp What would it be in FeathersJS? by implementing SkillUpService#create?
I hope you get the issue I'm trying to highlight here. Do you have some ideas to share or recommendations on how to organize the API in this particular framework?
I'm not an expert of featherJs, but if you build your database and models with a good logic,
these methods are all you need :
for the settings example, saveSettings corresponds to setting.patch({options}) so to the route settings/:id?options (method PATCH) since the user already has some default settings (created whith the user). getSetting would correspond to setting.find(query)
To create the user AND the settings, I guess you have a method to call setting.create({defaultOptions}) when the user CREATE route is called. This would be the right way.
for the skillUp route, depends on the conception of your database, but I guess it would be something like a table that gives you the level/skills/character, so you need a service for this specific table and to call skillLevel.patch({character, level})
In addition to the correct answer that #gui3 has already given, it is probably worth pointing out that Feathers is intentionally restricting in order to help you create RESTful APIs which focus on resources (data) and a known set of methods you can execute on them.
Aside from the answer you linked, this is also explained in more detail in the FAQ and an introduction to REST API design and why Feathers does what it does can be found in this article: Design patterns for modern web APIs. These are best practises that helped scale the internet (specifically the HTTP protocol) to what it is today and can work really well for creating APIs. If you still want to use the routes you are suggesting (which a not RESTful) then Feathers is not the right tool for the job.
One strategy you may want to consider is using a request parameter in a POST body such as { "action": "type" } and use a switch statement to conditionally perform the desired action. An example of this strategy is discussed in this tutorial.
I'm creating a new App in RVD and creating a request to an external service. Everything works as expected, I'm using different variables as core_From, core_To and so on. The problem is, I would like also send the date when the call is done but I don't find any variable for that and I wasn't able to find any documentation defining those variables.
I guess I could invoke an external service to know the date, but it seems to costly to do something so trivial... so I think I'm missing something obvious here. Any help on that would be welcomed.
After this PR, the variable core_callTimestamp is available to provide this functionality.
I know almost nothing about Documentum, so there are probably omissions in the information you need to answer my questions. But I'm going to try, anyway...
We use Documentum (obviously). Within Documentum, users can create workflows. These workflows contain ordered lists of services that are used to process data. So, we may have ServiceA, ServiceB, ServiceC, ServiceD, and ServiceE, and a user can create a workflow that says to process the data using, in order: ServiceC, ServiceA, and ServiceB. Another user's list might be: ServiceA, ServiceD, ServiceE.
I've been asked to find a way to get a list containing the id/name of each user, the user's workflow id (name?), and items within the workflow. From what I've read here on StackOverflow and elsewhere, it looks like this is possible via DQL.
And, if I have the DQL, it turns out that this will be simple to do using interfaces we've already built. If it's too complex, I'll need to write Java and use the API. I'd prefer the DQL.. :-)
So, can someone here provide me with a pointer to a reference on DQL, and perhaps some pointers on what to look at/for?
Maybe you need more than one DQL-Query. However, I would strongly recommend writing some DFC code and iterating over the results.
I would suggest to have a look in the Documentum Content Server Object Reference to find out more about the attributes of type dm_workflow (and, of course, related types like dmi_workitem, dmc_workqueue, etc.).
These types should provide the information you are looking for and where you might start best.