Igor Sereda
My feedback
151 results found
-
8 votes
An error occurred while saving the comment An error occurred while saving the comment Hi Fred,
Thanks for your request. Yes, it's been a long time, but Structure 3.0 has been our main focus since this Summer. The next big release will be Structure 3.0 and it will allow organize a hierarchy out of projects or other JIRA's "items". ETA is not available yet.
Could you please elaborate, what do you mean exactly when you safe "supporting the project hierarchies natively"? The expectation for "native support" can vary widely. If you mean that the projects can be parts of the structures without creating "fake" issues to represent them -- yes, that will be possible. But if you expect that, for example, a sub-project would inherit some project settings from a parent project, that's currently beyond our scope.
Kind regards,
IgorAn error occurred while saving the comment Baci, thanks for your questions - I've edited the title to be more like an idea.
Currently, a structure may contain only issues. Often our customers use issues to represent all kinds of items - projects included. (So you'd have a separate issue type called "Project".) That's a bit confusing of course, but as a bonus you get workflow, custom fields, etc for a project from JIRA.
In the future versions, we plan to support hierarchies made of the JIRA projects and other JIRA "things" natively, without additional issues.
Igor
-
4 votes
waiting for clarification
An error occurred while saving the comment Marcos, thanks for adding your vote for this feature.
At the moment, Structure does not have this feature out of the box. It is possible to add it through a third-party plugin and using Structure API and adding a new column, so maybe someone will create one.
At the same time, we're working on Structure 3.0 now, and we'll try to fit in this specific feature into 3.0 or in one of the following releases that should come out faster after 3.0. (The ETA is still not announced.)
Kind regards,
IgorAn error occurred while saving the comment Brian, thanks for your comment. There are two ways we can do this roll-up:
1. Actually change the field of a parent issue when children's field changes. That will require an installation of a synchronizer that would do the change in the background. It's also naturally limited to one structure - if an issue is in two or more structures, you need to decide which to roll up.
2. Do not modify the issue itself, but displayed the "rolled up date" on the Structure grid, like total estimation is displayed right now. This addresses the issues with the 1st approach, but the drawback is that the issue will not have this rolled up value in its field - so the core JIRA functionality or other plugins will not "see" the rolled up value.
Which of these solutions would best suit you?
Thanks,
IgorAn error occurred while saving the comment Jeffery, thank you very much for the comment.
I like the idea of "flags", which means that things won't necessarily happen automatically, but will draw attention and will allow the user to act.
The way you suggest to automatically divide the time between sub-issues and calculate due dates based on that implies that the issues are worked on in order (noone starts working on the next issue until previous is finished), with no work done in parallel, and with no dependencies without tasks. I'm not sure how much traction in real world would this calculation make.
Isn't it better, perhaps, just to propagate due date as it is, and leave it up to the user to set due dates for sub-issues (that will also be propagated down), and show the red flag when there's a contradiction?
Or, rather, solve this problem with a Gantt chart with dependencies, resources and stuff - when we have it...
Igor
An error occurred while saving the comment Thanks for posting this idea. Could you please elaborate a bit, how would this work? What is the relationship between due dates of sub-issues and parent issue? How is estimated time a factor?
-
1 vote
An error occurred while saving the comment Hi,
Thanks for your suggestion. So, you'd like to take a structure (or a part of it), and have it all assigned to a specific Sprint, and also see the structure as a part of the Sprint. Is that correct?
We can work on mass-updating issues in structure to put them into a single Sprint.
But the way Sprint is displayed on Agile board is out of reach for us --- you and us can ask Atlassian to integrate JIRA Agile with Structure, but I'm afraid there's little chance they'd do that.
So if you need to see a hierarchy of issues as a part of your Sprint, we'll need to represent the Sprint on the Structure Board. This will be partly possible in Structure 3.0.
Let me know your thoughts, or if you have further suggestions.
Thanks!
Igor -
4 votes
Collecting requirements – please see the comment.
An error occurred while saving the comment Hi Helen,
Thanks for your question. It could actually be a separate idea!
Current version of Structure.Testy cannot provide this functionality out of the box, however, it could be automated through REST API and some additional "agent" program, which detects test run status and updates issue status.
We can plan a feature in Testy that would automate issue status change, however there are certain questions that needs answers --- for example, if issue status is updated to "Passed" because the latest test run is Passed, what happens if a new test run is created? Are all "Passed" issues become "Not Passed" again? Do only some of the issues change?
I've also added a feature request for associating a date or a version number with a test run, so it's possible to tell which one is the latest - https://jira.almworks.com/browse/STY-47
Kind regards,
IgorAn error occurred while saving the comment Robert, thanks for the explanation. Got it now.
We intend to add a free-form text field, editable in/around test run column, so the user can type any comments regarding why the status is marked passed/failed.
We also consider adding a panel to the issue view that would show the status of the issue for the test runs that it was in.
As for more complex scheme of configurable fields per test run - that is a bit out of scope. Structure.Testy was supposed to be a lightweight solution, easily usable without much configuration, and not a full test management suite. Did you try other JIRA-based testing tools like Zephyr (I believe there are others too). As much as I would like you to use our product, if what you need is actually something else, then it's better to use something else! Actually, if those plugins didn't work for you, it would be interesting to get your feedback, why.
Thanks
IgorPS. Oh, actually - we have a thought to associate a Test Run (as a column) with an issue. So then - if the user defines "Test Run" issue type, and associates test runs with those issues, it will be possible to have JIRA's custom fields functionality for the test runs. It will take some glue to make the data searchable through JQL, but I think it could be done.
An error occurred while saving the comment Hello Robert,
Thank you very much for your feedback! It makes sense and falls in line with our thoughts about future Testy features.
I'm a bit baffled by the idea title though - could you please explain what did you mean by "type of parent-child relation inside an issue" and how it connects with the necessity to have environment parameters and reports?
Thanks!
Igor -
1 vote
An error occurred while saving the comment Hello Paulino,
Thanks for your suggestion - we definitely have this on our radar. Which language(s) do you need Structure translated to?
Kind regards,
Igor -
1 vote
An error occurred while saving the comment Thanks for your suggestion! Could you please clarify, would you like to adjust colors just for Structure, or does your JIRA have a non-standard color scheme and you'd like Structure to follow the same color scheme? (Which we can extract from JIRA settings)
Kind regards,
Igor -
3 votes
please see the question in the comments
An error occurred while saving the comment Hi,
I'm not sure I understand fully your request - but if you'd like to have a filter that is based on whether an issue belongs to a structure, you can use structure() function - please check out https://wiki.almworks.com/x/dIPE - you can combine it with other JQL filters using AND operation.
If you need something else, could you please explain in a bit more detail?
Thanks!
Igor -
3 votes
collecting requirements in the comments
An error occurred while saving the comment Hi Juha, thanks for your suggestion! I agree, Structure does not look quite good on Wallboards, so this makes sense.
However, besides stylesheets we might need to add more options regarding Structure navigation - because you typically have the "focused" issue, you scroll up/down, expand/collapse nodes, etc. - these things are not supposed to be done on a wallboard, right? So we'll need to figure out how to display structure, which levels to expand, and what to do if it doesn't fit into the space available.
Could you please elaborate a bit more, what kind of structure would you have on a wallboard, and how would you like the questions above to be addressed?
Thanks
Igor -
10 votes
Possible as per-user CSS customization feature
An error occurred while saving the comment Heiko, thanks for your suggestion! Please note that you can hide all resolved issues by clicking "Unresolved" button in the toolbar.
An error occurred while saving the comment Mohamed, thanks for your comment!
An error occurred while saving the comment Martin, thanks for your comment! Unfortunately, so far the resolved issues are marked with the green tick icon. Also, if you add Progress column, resolved issues will have 100% progress. I hope that would be sufficient for presenting your structure to the customer.
As for the future development, we will definitely not make strikethrough style for resolved issues the default. If we did that, I am sure most of our users would disapprove and request rolling that change back. However, we can consider a user-level or global admin-level option for switching that style on.
An error occurred while saving the comment David, thanks for your comment!
I beg to disagree - in the Issue Navigator, when you search for issues that have been resolved, they are not displayed with strikethrough. The only place this happens, as I recall, is in the Issue Links section, probably Sub-tasks section and when you mention an issue key in Description or a Comment.
Anyway, as I commented earlier, we'll have a feature to allow JIRA admin or the users to specify custom CSS rules.
Kind regards,
IgorAn error occurred while saving the comment Heath, thanks for your suggestion!
I understand strikethrough may be the usual way to check out the completed tasks, but I'm afraid it would look really ugly on the grid.
Currently you can see comleted items are marked with green tick, you can hide them with "Unresolved" button, and you can use JQL filter "resolution is empty" with Filter mode turned off to make the resolved issues dim.
If that's not enough, I believe what we can do is make it possible for per-user configuration of additional CSS rules to decorate the grid as the user sees fit.
Igor
-
3 votes
An error occurred while saving the comment Torben, thanks for the clarification. A new way to construct dynamic structures comes with Structure 3.0 (ETA is not available yet). It will have a solution for this.
-- Igor
An error occurred while saving the comment Torben, thanks for your idea. Do I understand you correctly that you'd like to add not all sub-tasks, but only specific sub-tasks that satisfy a JQL query? And if they stop satisfying a JQL query, remove them?
-
3 votes
An error occurred while saving the comment This is actually a very nice idea - thank you, Neal!
-- Igor -
25 votes
An error occurred while saving the comment Hi Jonathan,
Thank you very much for your idea. So if I understood it correctly, what you suggest is a different view (of the same data model) where you would have all issues displayed as cards (say, as in JIRA Agile), and laid out in certain way: top level and 2nd level issues are laid out horizontally to represent the time, 3rd level issues are laid out vertically under their 2nd level parent issues. Is that correct?
This is an interesting idea but I don't think we'll have the resources to work on it in short term. (This could actually be done by any other developer - Structure provides the necessary data through the API.)
Kind regards,
Igor -
12 votes
An error occurred while saving the comment Hello Blair, there's no update yet. As you can see, this feature request has received very few votes, compared to others. As we cannot do everything at once, we need to prioritize.
Sorry for no news on this. On the other hand, we're finalizing our work on "issue preview" panel on the Structure Board, which will let you scroll the usual issue view, including the attachments.
Igor
An error occurred while saving the comment Jose, thanks for your comment!
In defense of the Images column (notwithstanding the need for a paperclip icon) I can suggest that it can be minimized to a tiny column to just let you see that there's something there. You can select that issue and tap "i" twice to see the images in lightbox.
Igor
An error occurred while saving the comment Great, thanks - marked as planned!
An error occurred while saving the comment Got it now. Ok, what if an issue with attachments had a small "paperclip" icon in the beginning of a row, like in an e-mail client? And pop-up preview to see the details.
(It's not a problem to add another Files column, I'm just trying to figure out the best design.)
An error occurred while saving the comment Angell, thanks for your idea. If we had an issue preview panel that would pop up and let you see full issue details, including the attachments and download button, would that address this need too?
-
2 votes
waiting for clarification
An error occurred while saving the comment Hi Travis,
I'm not sure I fully understood the configuration you've described, but Links synchronizer's scope can certainly be limited with "Parent JQL" and "Child JQL" options. If an issue (whether it's in the structure or not) does not satisfy the JQL, it will be completely ignored - which lets you cut out sub-tasks from links synchronization.
More details in the docs: https://wiki.almworks.com/x/lwBg
Kind regards,
Igor -
3 votes
planned as the Structure Board with preview
An error occurred while saving the comment Thanks for the feedback.
It is indeed possible if you click on the next/previous issue in the Structure panel on the issue page. You might need to un-pin the widget so it shows the full structure.
If you're asking about a keyboard shortcut, like "n" and "p" that JIRA has for going through a list, then it would be a good improvement. But we're addressing it slightly differently - we're currently working on the "preview" panel for the Structure Board, so you can see the structure and the issue panel at the same time - much like in the latest version of JIRA's Issue Navigator (details view). Navigation back/forth with work there, of course.
If that will not solve your request, please elaborate why you'd like this also on the standalone issue details page.
Thanks!
Igor -
3 votes
An error occurred while saving the comment Hi, thanks for your suggestion.
When you say "queries", do you mean something you can use in JIRA, like JQL, or do you mean reaching directly into the DB with SQL?
For the former, we do have S-JQL, which allows everything you mentioned and more - https://wiki.almworks.com/x/dIPE
As for accessing structure data with SQL, this is tricky. We do plan to move away from our own embedded Derby database to the same DB that JIRA uses. But that by itself wouldn't be much help, because the content of a structure is stored as one large BLOB. This utter denormalization is by design and for good reasons, not the least of them being performance. It's not possible to access it with SQL. The best we can do is provide a way to set up some "mirroring" of a structure into a quasi-normalized relational table.
However, there's an API for getting structures - see https://wiki.almworks.com/x/oYF7 with reference and examples.
Please let me know if this answers you question or if you have further details on this.
Thanks
Igor -
3 votes
requirements gathering
An error occurred while saving the comment Thanks for your suggestion!
Could you please elaborate, how in this scenario is the individual progress of an issue (that has no children) calculated? Because what you describe is exactly what happens when the progress is based on time tracking information - because we know that time measurements are absolute. But when it's based on, say, a "% done" field, I don't think there's much sense in aggregating those values based on how many children an issue has.
An example that you have in your mind would be great.
Thanks!
Igor -
1 vote
Will review after Structure 3.0 release
An error occurred while saving the comment Thank you for your suggestion!
Currently, there are "perspectives" that let you build an URL that defines the current view, including the search - https://wiki.almworks.com/x/foH4
This is not exactly what you're asking for, but the better version is coming with Structure 3.0, where we'll have generated/filtered structures. Another, more distant feature in our plans is quick filters.
Igor
-
0 votes
also tracked as https://jira.almworks.com/browse/HJ-1365
An error occurred while saving the comment Chris, thanks for your suggestion. A feature request like that is also tracked as https://jira.almworks.com/browse/HJ-1365
The tricky part here is in the details, as usual. How should this query work for issues that match in structure A and don't match in structure B? For issues that match in structure A and are absent in structure B? What if some user creates a structure for himself, but for some reason shares it with everyone, and then places some issues such that they stop satisfying your query?
This is in our plan, but so far we don't see a good solution. We'll come back to it later, after Structure 3.0 is released.
Igor
-
4 votes
An error occurred while saving the comment Chris, thanks for your follow-up. We'll need to think about the final design of the updated multi-selection, but we'll take everything into consideration for sure. (And believe me, a lot of time went into designing the current multi-selection!)
I should also say that this is not something we'll be able to address soon. We're now working on Structure 3.0, which will have large implications on the UI as well. Perhaps we'll fit the update to multi-selection there, but we can't make any promises as of now.
Kind regards,
IgorAn error occurred while saving the comment Chris, thanks for your feedback.
I understood the scenario that you described and how retained multiple selection gives trouble, however, I doubt that the solution you propose (holding Ctrl or Shift to add to selection) is the best one we could go with.
The little circles that indicate issue selection are like checkboxes. Checkboxes are usually independent items in a list, and selecting one checkbox does not clear other checkboxes. I think many users expect that.
We'll think about how to approach this in the best way. Right now we have an indicator in the footer area that tells you "N issues selected". Maybe we should add another visual indicator that some of the selected issues are not visible due to scrolling, with an option to clear the selection on them. Maybe we could add specific logic that resets the selection if you start selecting new issues after you've made a certain operation with the previous selection.
Thanks again for the detailed description of the problem.
Igor
Hi Fred, thanks for the explanation. I think we'll have a basic project hierarchy in 3.0 and then build on top of it. There's no ETA right now, unfortunately. Please check back in a couple of months.
Kind regards,
Igor