Igor Sereda
My feedback
151 results found
-
3 votes
collecting requirements — see comments
An error occurred while saving the comment -
3 votes
collecting requirements — please see comments
An error occurred while saving the comment Hi Matthew,
Thanks for suggestion! This is definitely something that we can implement without a lot of effort -- the supporting architecture is there. My only question is how you track risk, with some custom field? Do you know what type of custom field is that? We need to understand how to compare risk values.
Kind regards,
Igor -
3 votes
An error occurred while saving the comment Stefan, thanks for the clarification!
An error occurred while saving the comment Hi Stefan,
Thanks for the feedback! Those are really great ideas.
1. We also had the idea of combining several transformations into one, but it involved creating a higher-level concept like "Recipe". It's recorded in our list of future improvements.
2. I understand that you'd like to change the quick transformations that are shown for queries. Would you like to have the transformations that you set up shared with other users?
The reason Quick Transformations are currently not adjustable for queries is that the the transformations settings are attached to the structure and use structure's permissions -- only admins of a structure can set up quick transformations for it, and they will be shown to all users.
When we allow adjusting quick transformations for queries, the simplest thing we could do is to allow each user to have their own set of transformations. But then you wouldn't be able to share it with other people. Is that ok?
Kind regards,
Igor -
2 votes
Considering the feature — please see the comments.
An error occurred while saving the comment Hi Mike,
Thanks -- that is an interesting idea, but, I have to say, far from the current plans. There would be a lot of questions if we try to write down the spec for this, considering that the content is dynamic and may change with time.
I can suggest the following instead. Suppose you have labeled the "sticky" issues using JIRA's "Labels" field. Then you can add a _second_ sorting using "Transformations" panel, and make it by Labels. All marked issues will be placed together at the top or at the bottom.
The same can be done with some other fields too. Of course the drawback is that other users can see these marks too, but this thing works right now!
Kind regards,
Igor -
1 vote
collecting requirements — see comment
An error occurred while saving the comment Hi Olivier,
Thanks for posting this request! I understand the problem.
One thing we had in mind for a while is to somehow make generated and manually added rows different -- for example, adding some colored marking for generated rows. That way you can see what kind each row is.
Another idea is to have on/off switch for a generator, so you can temporarily disable all generators -- then all that's left is going to be manually added items.
If we implement both of these ideas, would you still need additional filtering?
Kind regards,
Igor -
3 votes
see comments for details
An error occurred while saving the comment Stefan, thanks for the kind words! We're doing our best.
I hear you about folders -- we have plans to make them more flexible and add some properties, but we wouldn't go as far as making them comparable to issues in complexity. If you need that much, it's probably better just to create a special issue type.
Kind regards,
IgorAn error occurred while saving the comment Hi Stefan,
This is a great idea, thanks! We thought about something like that too, where it comes to comparing top-down estimates with bottom-up. We'll see what we can do!
Kind regards,
Igor -
1 vote
analysis — see comments
An error occurred while saving the comment Hi Greg,
Thanks for describing your case. This is a known limitation in the current feature set and we're thinking about how to improve it in the best way. Automation is already quite complicated and we're trying to contain the complexity.
With the current functionality, there are some workarounds that can be done. For example, one could use a grouper after the extender, and group by Label or a custom field, adding another level between Epics and Stories. Stories will still be attached to epics without duplicates. Using Labels has an additional benefit of allowing multiple labels per issue.
Kind regards,
Igor -
19 votes
An error occurred while saving the comment Hi Raghu,
Could you please send an email to support@almworks.com and describe in more detail, what are your actions, what is the observed result (a screenshot would be nice) and what is the expected results?
Thanks,
IgorAn error occurred while saving the comment Hello. What I'm trying to explain is that you need to use two existing features in combination. Feature 1: create a full copy of the template structure. Feature 2: copy/paste between structures.
You can check out those in the links earlier in the comments or on this video: http://www.youtube.com/watch?v=j4Rx60Xf9qc
If you still need help with those, please send an email to support@almworks.com to avoid sending many emails to other subscribers of this improvement request.
Thanks!
IgorAn error occurred while saving the comment Please check the documentation article I mentioned earlier about copying full or partial hierarchy from one structure to another: https://wiki.almworks.com/x/cwBy
Basically, it's Ctrl+A, Ctrl+C, switch structure, select parent, Ctrl+Shift+V.
An error occurred while saving the comment The idea is that first you create new, unique issues, using Copy+Clone operation. It creates a new temporary structure. Then you move those new, unique issues into the structure you want them in.
An error occurred while saving the comment Yes, I understand that - the approach I offered in my first comment was to create a full clone of a structure and then copy/paste the new issues (with a limited number of keystrokes or mouse actions) to the target structure.
Would that work for you?
An error occurred while saving the comment In fact there is bulk cloning of the whole structure in Structure now, with cloning every issue - have you discovered it yet? Check out https://wiki.almworks.com/x/6Aqf and https://wiki.almworks.com/x/8gqf
If that doesn't work for you, please let me know how it's different from what you need.
Thanks,
IgorAn error occurred while saving the comment Thanks for your suggestion! We'll be working on improving bulk-cloning in the future.
But currently, you can combine full copy-clone of a structure with a multiple copy/paste functionality: you can select multiple issues in one structure and insert them into another - see https://wiki.almworks.com/x/cwBy
Something like: (a) copy the template into a temporary structure TEMP; (b) use copy-paste to copy all issues from TEMP into your target structure at the desired place; (c) delete structure TEMP.
Hope that helps!
Igor -
1 vote
An error occurred while saving the comment Hi Cash,
Thanks for your suggestion! I apologize for replying so late; ironically, a notification from uservoice got lost in the way!
This does make a lot of sense. There are some technical details -- as you mentioned, this wouldn't work with generated content (unless there's an active component that, say, checks and compares generated content once a day).
I also imagine this would require digest mode from notifications and, therefore, some delay, because otherwise one might get a load of emails from a busy structure.
Kind regards,
Igor -
1 vote
Collecting requirements — please see comments.
An error occurred while saving the comment Hi Willem,
Thanks for your request! Currently it's possible to place the whole structure under a folder and configure "total" columns to show the totals for that folder. Did you discover these features? Does this solution not work for you?
The result we didn't put totals so far is that for a large structure, it would incur additional load on JIRA server all the time, while sometimes the totals are not needed.
Kind regards,
Igor -
2 votes
Collecting requirements – please see comments.
An error occurred while saving the comment Nora, thanks for the feedback! It's helpful. No promises on dates, but we'll definitely look into that idea.
Igor
An error occurred while saving the comment Hi Nora, thanks for the idea!
It has been suggested several times already. We certainly can do that in the same way we integrated Confluence with Structure.Pages.
I have the following questions for you to understand how solution might work:
* Would you be able to install an additional (free) plugin on the external JIRA?
* Would it be ok if remote issues could show only standard JIRA fields (no custom fields)?
* Would it be ok if remote issues could be only viewed, but not edited? And no way to create issues on the external system.
* Would it be ok if you had no way to search on the external system? Only pick issues by issue key or through a remote issue link (via extender, for example).
* Would you need to connect to more than one external JIRAs? How would you like to differentiate between them if you have local issues and remote issues from different sources in the same grid?Thanks!
Kind regards,
Igor -
86 votes
An error occurred while saving the comment Hi Simon and all supporters of this feature,
There was a ton of great things we wanted to put into Structure 3. Unfortunately it turned out to be impossible to do all of them and still release Structure 3 in reasonable time. We had to postpone a lot of great stuff, including this feature. Structure 3 is still a great upgrade -- even without the features that got postponed, it took us more than 2 years to bring forward automation, various item types, multi-parent relationships and many more improvements. We'll continue building on the platform that we have and we have all this features in scope.
As for specific dates, I cannot provide an estimate for limiting parent-child relationship right away, sorry. It's not planned for the nearest releases. From what I understand, the need for this feature has gone down a bit with the introduction of generators. However, we still consider it important for manually crafted structures.
Please check back in the beginning of 2017 for an update.
Kind regards,
IgorAn error occurred while saving the comment Hello Jonathan, and everyone waiting for this feature.
We're considering this as a part of our massive remake and extension of Structure, which is going to be version 3.0. There are no estimates yet, but we're actively working on 3.0 features now. Even if this feature does not make it into 3.0, it will be much more feasible by then and we'll likely implement it in a 3.x version.
Igor
An error occurred while saving the comment Niels, thanks for keeping in touch. No updates so far, sorry - this is one of the big features we have planned, and it's at the top of the list, but it is massive, considering the implications across the whole product. We're getting closer to it by working on other features who will provide the foundation for this improvement.
An error occurred while saving the comment Dear Sri Kanth,
No this feature is not implemented yet. We cannot promise any dates, but this feature is on our current list of things to be definitely done.
Igor
An error occurred while saving the comment Mike, thanks for an excellent feedback! Seems like there are two distinct features:
- one is enforcing a specific structure of... a structure - what issues can be where in the hierarchy, regardless of who does the changes
- the other is hierarchy-based permissionsAn error occurred while saving the comment Hey Guy! Good feedback!
Yes, using projects and types in the restriction set is a more complete solution - we'll have it. Different permissions at different structure levels have been also requested, I'm not sure yet if it's a different feature or the same, but it has a jira issue here: http://jira.almworks.com/browse/HJ-434
Cheers!
IgorAn error occurred while saving the comment Martin, thanks for describing your use case!
An error occurred while saving the comment Walter, thanks for the comment. We plan to have Project/Type field selectors when you create a new issue in the Structure - this should address the UX.
I guess this feature is more about keeping a strict process, not allowing arbitrary parent-child relationships.
An error occurred while saving the comment Further improvement: enforce configuration of types set up by the user. For example, if it's configured that an issue of type A always has a parent issue of type B, enforce this when a new issue of type A is created.
-
6 votes
An error occurred while saving the comment Hi Simon,
Sorry about the delay with the reply. For future questions / support requests, please use our JIRA at http://jira.almworks.com
Regarding this configuration, "all sub-issues are equal" mean that each child of the parent is treated equally. Thus, (50% + 75%) / 2 = 62.5%.
I understand that does not make sense with the structure you have. Clearly, if you have status-based progress and grouping by status, there should be a way to aggregate the progress. We'll need to add aggregation weight based by the number of sub-items. I have entered an improvement request into our development JIRA and I will update this idea accordingly, if you don't mind.
Kind regards,
IgorAn error occurred while saving the comment Hello Simon,
Thanks for raising this question. Could you please make a screenshot of the Progress column settings?
Thanks
Igor -
1 vote
An error occurred while saving the comment Hi Aggelos, thanks!
The groundwork for multiple Confluence connections is already there, we'll just need to add some UI stuff. Coming soon!
Igor
-
1 vote
Reviewing options – please see comments
An error occurred while saving the comment Hugh, no problem, thanks for speaking your mind! We value feedback very much.
There's no current plan to address it, since we have started talking about it 5 minutes ago, but we'll review this on our next UI planning session.
As for workarounds, there are no setting in Structure, but a JIRA admin armed with JavaScript could do that by clearing "window.almworks.structure.installCreateIssueHandler" property after scripts have loaded, but before this function is executed.
For example, you can set up an "Announcement Banner" in JIRA (in System settings) like this:
<script>try { window.almworks.structure.installCreateIssueHandler=null; } catch (e) {}</script>
However, that would add an unneeded banner stripe on every page (unless you have other banner there).
Other ways to inject that code in the right place could be used.
Hope this helps!
IgorAn error occurred while saving the comment Hugh, thanks for your comment!
I'm sorry if overriding Create button's behavior is an inconvenience. I myself often click "Do not add to Structure" at the bottom of the dialog after I have clicked "Create".
However, this functionality, as far as I remember, was added specifically to address other customers' requests. And it was also justified by non-technical users having difficulties in adding issues to a structure, since they were accustomed to clicking the blue Create button.
We'll obviously need to find some middle ground here.
Kind regards,
Igor -
3 votes
please see the comment for an alternative setup
An error occurred while saving the comment Alternatively, you can try using an Agile Board inserter to insert stories (pick "Insert issues except Epics"), and then add "Epic" grouper to group by Epic. Then issues will be movable between epics and "No Epic" folder.
An error occurred while saving the comment Hi Nora,
Thanks, that's a great suggestion! We'll try to implement this in the nearest future.
Kind regards,
Igor -
1 vote
An error occurred while saving the comment Hi Wolfgang,
Yes, we have. It's a tricky subject. Let me pass your suggestion to Eugene and he'll write you to discuss the details.
Thanks!
Igor -
7 votes
-
3 votes
An error occurred while saving the comment Thanks for the clarification! Now I see what you mean.
Yes, we should work on that, thanks!
Igor
An error occurred while saving the comment Hello,
Thanks for sending us feedback. Unfortunately, I cannot understand exactly what you are suggesting, except that there's some confusion with the structure names on the issue page.
Could you please rephrase, stating what are your actions, what is the observed result and what is the expected result?
Kind regards,
Igor -
4 votes
waiting for clarification
An error occurred while saving the comment Hi Erwin,
Thanks for bringing our attention back to this request. As you can see, it's been posted for a long time. There are a few reasons we didn't get to it so far: a) most of our users seem to be fine without the "breadcrumbs" information at the top; b) there's "Structure" section on the issue page, which shows you the same information, and more – including Summary of the parent issues and some values; c) for larger structures with many nested layers (we've seen setups with 10+ depth), the breadcrumbs will really be an overload for the user interface.
That is not to say that we won't work on this, but the priority has been on the low side these years. Please let us know how critical is this request to you. If it is, could you please describe a bit, how are you using Structure, and why this improvement is important for you?
Thanks!
IgorAn error occurred while saving the comment Thanks for the clarification - you can send a screenshot to structure@almworks.com or support@almworks.com
From what I understand, you might take advantage of the "sub-task synchronizer", which automatically places all the subtasks into the correct position in the structure in case the parent task is there. Use "Structure | Manage Structure | Import | Sub-tasks".
An error occurred while saving the comment Bob, thanks for your idea. Could you please elaborate a bit, do you mean that JIRA sub-tasks should have their parent Key in the Summary, or any sub-issue in the Structure should have their parent Key (or parents Keys) in the Summary field? What's the use case anyway? It seems that this is additional information that may confuse sometimes.
Thanks!
Igor
Hi Tyler,
Thanks for your suggestion! That makes a lot of sense, but in order to check the progress against time, we need to understand the start and the end dates of a task or a task group. What's more, we'll need to understand the work calendar to exclude weekends and holidays.
A part of this feature is coming soon with Gantt Chart extension, where a progress will be clearly seen on the time line. After that we'll see if we can show the "on time / delayed" marker in the table too.
Thanks!
Igor