Closed jarp0l closed 3 weeks ago
Thanks for sharing the issue and the solution. I will include it in the next release.
Thanks @blupants! 🤍 This tool was exactly what we needed, it's really a great tool.
An unrelated question: Is there any plan to add a feature to let users scan specific projects instead of scanning all of them?
Thanks @blupants! 🤍 This tool was exactly what we needed, it's really a great tool.
An unrelated question: Is there any plan to add a feature to let users scan specific projects instead of scanning all of them?
Thank you for the kind words. I am glad to hear that the tool has been useful.
In a previous discussion it was suggested to add the capability to pause and resume scans. Since I couldn't confirm from Jira/Confluence APIs that the order of the scans would always be the same (not to mention that new issues, projects or workspaces could be created in between scans) I decided to put the pause/resume feature on hold.
Though, the same feature request discussion also covered adding the "--scan-target-" and "--skip-target-" capability. That way you could create a list of specific projects you want to scan. If you think that might help you, I can split the previous feature request in 2 parts:
Then, assuming you want to scan Jira project "IT", "MARKETING" and "FINANCE", you would do:
n0s1 jira_scan --server "https://<YOUR_JIRA_SERVER>.atlassian.net" --scan-target-keys "project" --scan-target-names "IT,MARKETING,FINANCE"
Would this "1. Scan/Skip target" new feature cover your use case?
Would this "Scan/Skip target" new feature cover your use case?
Definitely, it would. But having to add *-target-keys
feels a bit tedious and unnecessary. Perhaps we should only add --scan-target-names
and --skip-target-names
?
It's always going to be a "project" when we are talking about Jira, and it's always going to be a "space" when we are talking about Confluence, and so on. We could also add short flags, like -sc
for --scan-target-names
or -sk
for --skip-target-names
(though the short flags can be anything else that makes sense).
Pause/Resume: will be kept on hold (future release)
I'm not sure we would need a pause/resume feature so much when we can use the scan/skip target feature. I mean, it would be great if we could have this feature, but as you said, the order of scans and the number of issues, projects, etc., may not remain the same between scans.
But maybe this could work:
Would this "Scan/Skip target" new feature cover your use case?
Definitely, it would. But having to add
*-target-keys
feels a bit tedious and unnecessary. Perhaps we should only add--scan-target-names
and--skip-target-names
?It's always going to be a "project" when we are talking about Jira, and it's always going to be a "space" when we are talking about Confluence, and so on. We could also add short flags, like
-sc
for--scan-target-names
or-sk
for--skip-target-names
(though the short flags can be anything else that makes sense).Yes, for Jira and Confluence that would work. The problem is for tools such as Asana that have a deeper hierarchy scheme Organizations->Team->Project->Tasks. Asana users might want to filter only orgs or only teams. That's why I initially thought about the
*-target-keys
, but to be honest I don't completely like that approach either.
Other ticketing tools that I plan to support in the future might go even deeper in the hierarchy structure and I know it will be hard to come up with a one size-fits-all approach. One of my goals is to keep n0s1 usage as simple as possible and avoid as much as we can params that are applied to only a subset of scans.
But I understand that at some point down the road It will become impossible to support all ticketing tools with the same input args because they will differ from each other. I also think it's too early though, to dry that line in the sand. For now, we should probably have a new issue specifically to discuss how we should do filtering.
Pause/Resume: will be kept on hold (future release)
I'm not sure we would need a pause/resume feature so much when we can use the scan/skip target feature. I mean, it would be great if we could have this feature, but as you said, the order of scans and the number of issues, projects, etc., may not remain the same between scans.
But maybe this could work:
- Create a list of all the issues/projects to scan first (like taking a snapshot at a point in time),
- Sort them in order,
- Save the list to a file during/after the scan, mentioning what has been scanned so far and what hasn't,
- Use that information to pause/resume scans.
That's a great idea! Maybe we could have an argument called "mapping", that would not scan anything. It would just pull the hierarchy structure to a json or something. Then, users could edit the json according to their needs, and run a "scoped" scan using that json as an input.
Something like:
n0s1 jira_scan --server "https://<YOUR_JIRA_SERVER>.atlassian.net" --map-only "hierachy.json"
Edit/customize "hierachy.json"
n0s1 jira_scan --server "https://<YOUR_JIRA_SERVER>.atlassian.net" --scope "hierachy.json"
I suggest closing this issue so we can move on with release 1.0.19 and include the keyboard interrupt
and the Jira/Confluence errors
to it. I will also create a new issue specific for the "Filtering Scans" feature request, so we can get more inputs from the open source community. And once we all agree we have a good solution for filtering, we can include it in a future release.
Any thoughts?
Sorry for replying late.
Maybe we could have an argument called "mapping", that would not scan anything. It would just pull the hierarchy structure to a json or something. Then, users could edit the json according to their needs, and run a "scoped" scan using that json as an input.
Something like: ...
That would be a good idea I think.
Yeah, let's create a new issue and get feedback from the community.
Meanwhile, closing this issue for #21.
Is your feature request related to a problem? Please describe. While using the
jira_scan
command to scan Jira projects/issues, some projects only allowed me to view information like project name and project lead but not issues. So this caused the tool to not proceed to scanning the rest of the projects, and throwingJiraError HTTP 400
continuously.Part of the error log:
Describe the solution you'd like Handle the
JiraError
exception by addingbreak
statement to thewhile not issues_finished
loop to skip to the next project. This will allow the tool to continue scanning other projects even if searching issues in some projects returns a400
error (see API docs).Here is my implementation to handle this issue in my case: https://github.com/jarp0l/n0s1/blob/c3e84b5a91310bcae5f178c0a92072f804368f18/src/n0s1/controllers/jira_controller.py#L89-L93