Related
We are using REST APIs to remove users from the actor roles of Projects.
We are using DELETE call for removing user/actor from the roles from a project.
JIRA call (Delete)
https:///rest/api/2/project/11264/role/10100?user=
REST API referring to,
https://docs.atlassian.com/jira/REST/7.0.10/#api/2/project/{projectIdOrKey}/role-deleteActor
The API returns 204 status message, but the user/actor is not removed from the Project.
I have tried this using JAVA, REST Clients
Has anyone experience this behaviour. If yes, could you please guide me on this.
I ran into this too and submitted a support request to Atlassian. They told me the delete actor endpoint uses the user_key which is the lowercase version of the first username the user ever had.
Check the fault report at https://jira.atlassian.com/browse/JRASERVER-68189 for more detail.
The userkey can be found for a username by calling /rest/api/2/user?username= which includes the key in its response.
your call should be like this
https:/<JIRA_URL>/rest/api/2/project/<Project-KEY>/role/10100?user=<username>
eg.
https://myjira.uat.com:8443/rest/api/2/project/SAND/role/10700?user=amitraj
Yes, Jira always returns 204 regardless if user is removed or not, sadly.
Unfortunately, in some cases, the user is not removed (altough projectKey, roleId and userName are definitely correct. This happens approx. for 1/20 calls and I don't why.
To make sure if the user has been really deleted I run another API call to check project role members after deletion:
/rest/api/2/project/{projectIdOrKey}/role/{id}
I'm running Jira 7.3.6 and using REST API with Python.
Not sure if removing users using ScriptRunner and Groovy would be better but I don't want to rewrite whole script into a different environment.
I had the same issue with one user, and I just noticed that passing a lowercase username does work (JIRA+Crowd in our setup). Always using lowercase should be fine according to the documentation, though it should work in all cases.
Is there a way to check if the user is typing in the console window in Java? My program prints information it receives about client connections using System.out.print() and I want it to stop printing information temporarily while the user is typing. User input is read on a separate thread using the Scanner class. I need to be able to see if the user has typed anything and still have whatever the user has typed (if anything) available to the scanner. If it's possible I would like to avoid using external libraries and just stick with the java libraries.
No, there are no ways to do that directly using the console (that I'm aware of) - the content of the console will only get sent to the application once enter is pressed and will then be available to the Scanner.
One way to solve it is to make your own console, that you can read and write from. Then you'll be able to do anything you want really (including check if anything is highlighted and so on). If you don't know how to code a GUI, you should look into that. Oracle has a tutorial on GUI with Swing.
The thread that listens to the user console , Generates an interrupt when the user starts typing, while the other thread that prints the information need to reset the interrupt, all you have to do is implementation of the scenario.
I think you're looking for Thread.sleep(milliseconds);. Using this until the user is done, you should get what you want.
Next time, please elaborate on your questions.
I'm learning to program in Java and I'm wondering if there is a simple way to set a return point in a method in case a user decides they want to go back. For example, within a method, I ask the user to choose between one of three options:
1) Register
2) Search
3) Other
Let's say that the user chooses to register. This choice then presents them with two new options:
1) Register as User
2) Register as Admin
Let's say that they choose to register as an admin. They are then prompted to enter their information, but maybe halfway through they realize "Wait! I want to register as a user, not an admin!". Typing in "back" is also an option, and if they do so, I want to be able to take them back to the menu where they choose between user and admin, not all the way back to the beginning. Is there a way to do this? I know I could use loops, but my program is a bit more complicated than my example, so I would rather not if I can get around it. I'm looking for a way similar to the way you can name loops in assembly language, so that you can just say "go to this point" and it goes back without the user having to re-enter all the information that they did before the sub menu that they want to get to. (I realize that in my example they don't enter any info until that sub menu. In my actual program they do.)
Any ideas? If worse comes to worse, I'm not opposed to using a loop. Just figured I would ask!
Thanks so much!
I think using loops is as good a method as any. Two suggestions:
you might want to read up on the break-with-label statement; and/or
you might want to place each menu into a separate function to make the structure clear.
Let's say you have methods for each of these options. At any point if user wants to go to some option, just return from the existing method with some value which indicates the option user wants to jump to. From the main code, just go to the appropriate method depending on the option selected.
Also, each method may take input of the parent (id), so going back won't be a problem.
This way you can go back to the parent or to some other option from any point in your program.
I think you are looking at it the wrong way. You don't need to go back to a point in your code to do an undo or rewind, you need to create the logic to be able to change a decision and make it work with whatever data has been entered so far.
So for example, you would use a data structure to hold all the data that a user enters, and if he chooses to change his registration type, you'll be able to fill in his info from that data structure. He can also decide that the address he gave you is wrong and change it, you'll still want to keep all the data you got so far, regardless if he's changing from user to admin.
The point is, you are looking at this in a sequential way, as if code can only run forward and backward in a straight line, while Java and even assembly are not at all sequential, you can go in every direction, skip to some logical point in time, and jump back to where you were.
The description may sound like just a bunch of words so here is a more detailed explanation. I have a User object which is mapped to database table.
I want users to be in different roles. There will be a bunch of those - and they technically will be the same users in same table but to them will apply different roles. Say user in role A will have to have two fields as required, and will have to have certain restrictions to the length and contents on his password, as well as the time expiration of his password, etc.
While I can hardcore those rules I am very interested to find out of there is an other way to define the rules and may be store in database so it's easier to load/apply and the main idea - to change and update them -- without redeploying the codebase.
Technically the stupidest and straightforward solution is to implement class, serialized, store in db, then load, deserialze, call methods on it which will execute rules. The problem is in changes to the ruleset ( read "interface" of the rule class ) and that generally solution sounds like a hack.
Anytihing else? Any frameworks? Other approaches?
UPDATE: probably was not clear. say, I have class User.java
I need to define different rules say:
1. do we need to verify length of password, and what should it be?
2. do we need to require some properties to be required?
3. do we need to track login attempts for this user?
4. if we do track, how many login attempts allowed?
5. do we expire password?
6. if we do, then in how many days? or months? or weeks?
7. ...
and so on and so on.
so questions ARE.
- how do I define those rules and operate on User object WITHOUT modifying and redeploying code base?
- how do I store those set of rules?
Drools, jBPM, etc. do not seem like a fit for that task. But any advice would help!
JRuleengine is good I heard, sometime back I planned to use it for similar application.
There are many other Rule Engines though.
Well there are some good rules engines out there include jrules, drools I think is popular too. One thing to keep in mind is the relationship between a rule and the data it examines. After all you can have the rules in a word document, but when they execute they need examine data, and that is also a factor in choosing a rule engine or architecture. generally its if (a > b) then do y. Means you need to examine a and b in the rule execution. That is the real issue is how to get the parameters into the rule and engine.
I tried to do several searches before posting this question. If this is a duplicate, please let me know and I will delete it.
My question revolves around the proper way to handle errors produced through our web application. We currently log everything through log4j. If an error happens, it just says "An error has occurred. The IT Department has been notified and will work to correct this as soon as possible" right on the screen. This tells the user nothing... but it also does not tell the developer anything either when we try to reproduce the error. We have to go to the error log folder and try finding this error. Let me also mention that the folder is full of logs from the past week. Each time there is an error, one log file is created for that user and email is sent to the IT staff assigned to work on errors. This email does not mention the log file name but it is a copy of the same error text written that is in the log file.
So if Alicia has a problem at 7:15 with something, but there are 10 other errors that happen that same minute, I have to go through each log file trying to find hers.
What I was proposing to my fellow co-workers is adding an Error Log table into the database. This would write a record to the table for each error, record who it is for, the error, what page it happened on, etc. The bonus of this would be that we can return the primary key value from the table (error_log_id) and show that on the page with a message like "Error Reference Id (1337) has been logged and the proper IT staff has been notified. Please keep this reference id handy for future use". When we get the email, it would tell us the id of the error for quick reference. Or if the user is persistent, they can contact us with the id and we can find the error rather quickly.
How do you setup your error logging? By the way, our system uses Java Servlets that connect to a SQL Server database.
I answered a similar question here, but I will adapt that answer to your question.
We use requestID for this purpose - assign a request ID to each incoming (HTTP) request, at the very beginning of processing (in filter) and then log that on every log line, so you can easily grep those logs later by that ID and find all relevant lines.
If you think it is very tedious to add that ID to every log statement, then you are not alone - java logging frameworks have made it transparent with the use of Mapped Diagnostic Context (MDC) (at least log4j and logback have this).
RequestID can also work as a handy reference number, to spit out, in case of errors (as you already suggested). However, as others have commented, it is not wise to load those details to database - better use file-system. Or, the simplest approach is to just use the requestID - then you do not need to do anything special at the moment error occurs. It just helps you to locate the correct logfile and search inside that file.
How would one requestID look like?
We use the following pattern:
<instanceName>:<currentTimeInMillis>.<counter>
In consists of the following variables:
instanceName uniquely identifies particular JVM in particular deployment environment / .
currentTimeInMillis is quite self-explanatory. We chose to represent it in human-readable format "yyyyMMddHHmmssSSS", so it is easy to read request start time from it (beware: SimpleDateFormat is not thread-safe, so you need to either synchronize it or create a new one on each request).
counter is request counter in that particular millisecond - in the rare case you might need to generate more than one request ID in one millisecond
As you can see, the ID format has been set up in such a way that currentTimeInMillis.counter combination is guaranteed to be unique in particular JVM and the whole ID is guaranteed to be globally unique (well, not in the true sense of "global", but it is global enough for our purposes), without the need to involve database or some other central node. Also, the use of instanceName variable gives you the possibility to limit the number of log files you later need to look in to find that request.
Then, the final question: "that is fine and dandy in single-JVM solution, but how do you scale that to several JVMs, communicating over some network protocol?"
As we use Spring Remoting for our remoting purposes, we have implemented custom RemoteInvocationFactory (that takes request ID from context and saves it to RemoteInvocation attributes) and RemoteInvocationExecutor (that takes request ID from attributes and adds it to diagnostic context in the other JVM).
Not sure how you would implement it with plain-RMI or other remoting methods.
If multiple servers are running and each server leaves log messages on itself, it is really difficult to trace them. So,somebody or a tool should gather and sort them in time order.
It is a good way to have a central point where all messages are sent.
A possible solution, have your error page include a 'send email to whatever' link. When the user clicks this email the body of the e-mail might start with a few blank lines followed by something like:
----Please do not modify the information below this line.---
Error details
Any users complaining via this link will automatically send you the info you need and if you are reproducing the error you have quick access to the error message. You might even have a form for sending the e-mail so that the user never sees this (which may be important to some) but then you are relying on your system being at least able to send an e-mail.
Actually I find it useful to print the error details in an HTML comment on error pages like this so that I can always get at them myself.
I do agree with david above that I do not like storing this kind of information in a DB.
For the strategies of logging you can see the discussion Logging best practices.
I have used an approach like the one you're suggesting ( log to a db ) in the past and it has been very helpful.
Not only you cat get the error via SQL but you can also generate reports of what's the most recurring errors and attend them first.
On the design we did, equals stacktraces belong to the same records ( since they were originated exactly in the same place )
We had an small app that pooled that db and we knew then a new exception was generated instead of getting an e-mail that summed with the rest of the previous weeks were ignored altogether.
Of course this database design was very specific for the application we had and additional identifications were possible, we had software version, build, some times input parameters , etc. etc.
With time, the system administrators get to know what to do with each kind of exception and proceed accordingly.
But! Your application may not be that big anyway. Probably you can have the same just parsing the log files.
I'd oppose the idea of storing error logs in a database. The logging system should be as simple as possible and not involve components that are not 100% necesary to write a log record.
Things can get pretty complex when logging into a DB - e.g. you can having troubles logging any database-related errors (how to log errors that occured because DB not responding, e.g. because of a heavy load or a infrastructure error); other issue I'd see is a potential need to have separate transactions for logging, etc.
On the other hand, having a reference ID for an error is not a bad idea, but again, this it also means to increase complexity of logging system ( e.g. how would you propagate the ref. ID through all layers of your application when a error occurs? )
In projects I'm involved to, the general guideline is to log errors as verbosely as possible, and to include as much context information as possible (to write the logs, we use a 'conventional' approach usually - log4j or simillar). Usually, this works well even for heavy loaded systems.