Content
New frontend for managing work packages build with AngularJS and API v3 for OpenProject 4.0 -> Please give us feedback
Added by Niels Lindenthal over 10 years ago
Dear OpenProject community,
The current work packages table has some usability and design challenges.
- Updating the description of a work package, especially the description.
- Changing the type of a work package.
- Saving queries (save).
- Copy changed queries (save as).
- Adding queries to the sidebar.
- Finding the filter options.
- Finding the options to group work packages.
- Context menu in the toolbar by right click, e.g. for bulk update.
- Finding the export options.
- and some more.
Additionally there are couple of important new features we want to develop.
- Inline editing
- Drag & Drop
- Seeing details of work packages without leaving the work packages table.
- Combine the
We therefore spent some time to rethink the entire architecture. After a long evaluation and decision phase within the OpenProject Foundation, spikes and performance tests we decided to build an entirely new frontend using AngularJS and a new REST-API.
There are a lot of tricky questions in both areas. We therefore want to ask you for feedback on this approach.
The API v3 is currently discussed and specified here:
The UX and design team also prepared some mockups here:
So if you have any ideas for improvements in both areas. Let’s talk. We appreciate your feedback and comments.
Thanks
Niels
Replies (18)
Hi Niels,
This is looking like a move in the right direction as AngularJS will open up more UX options.
There are two features we would find very useful for managing work packages.
Quick Creating Work Packages
Similar to how “Asana”http://www.asana.com/ works, we are looking for the ability to quickly press the enter key to create a new work package and then press tab to create a child work package. This would drastically improve the usefulness of OP to our workflow. At the moment, we work with clients to create line-by-line change requests. Due to the cumbersome nature of entering them in OP, we create overall deliverables in OP and then link to Google Spreadsheets with the finer details. Ideally, however each request would be a work package, so it can have it’s own timeline, comment thread etc.
Ideally, the next work package created would use the same properties as the previous work package, but start with a blank subject. Perhaps you could right click on a settings column to set the other default work package settings for newly created items.
Re-scheduling
Timelines do change from time-to-time, so the ability to move work packages forward X days is another important feature. This could be handled via a bulk update so that work packages can be selected and then the move applied to those packages. Ideally an option to move recursively which moves all child work-packages would be best.
Cheers,
Chris
Chris Were wrote:
+1
We should also consider linking this to the filter and grouping settings of the respective table. E.g. if you have filtered for Bugs assigend to a specific version, it is very likely that the next created work package is a bug that has the same version.
That is tricky. For real scheduling we need concepts such as resources and availabilities. It also needs to be linked with priorities of a backlog, dependencies and so on. That will habe to be build rather sooner than later. Before that we will focus on making it easier to change dates manually, e.g. by drag & drop and inline editing.
Cheers
Niels
Thanks Niels.
Agree that is tricky. Drag & drop would be a huge plus and help alleviate the issue in the short term.
The new workpackage view is great, however I miss one feature. OP 3.0 introduced the really useful possibility to quickly change some important properties (as introduced here). Are there any plans to get it back?
It’s significantly quickter to execute than with the new (old “classic”) way. Just to illustrate the difference when changing the target version:
OP 3.0 way:
-> 2 mouseclicks and done
Classic way:
-> 5 mouseclicks and two additional page-loadings
This change has had a huge negative impact on us also. The quick right click and change properties on WP was very useful, but now we have to do the extra process as outlined by Patrick.
It’s also not possible on the WP view to right click on a subject to open a new tab which we frequently do. If it was possible to “inline edit” the WP when it appears in the right hand side of the WP list that would alleviate this problem.
Hello Patrick, hello Chris,
thanks for your feedback.
You are right: This is really a temporary set-back in the available functionality.
The reason for this lies in the fact that we had to re-build the context menu in order to be compatible with AngularJS which we use for the work package page.
As soon as we re-built the bulk-edit screen / functionality with Angular we can also re-introduce the additional bulk-edit options.
@Chris: You can still open a work package in a new tab by pressing Ctrl / Command and left clicking on the work package subject / ID.
We are currently working on in-place edit functionality which allows users to quickly change attributes via the split-screen (#13701).
(You can have a look at the dev branch to see the current stage of development.)
Sorry for any inconvenience.
Thanks,
Robin
Hello Robin
Thanks for your reply. Is there a workpackage for the rightclick functionality? #7066 is somewhat general (and on hold).
Thank you, regards
Patrick
Hello Patrick,
this is the relevant work package: #17531.
Thanks for pointing this out.
Best regards,
Robin
Thanks Robin, that information is greatly appreciated.
OpenProject is a fantastic piece of software, so keep up the great development work.
Out of interest, was there a mention in the changelog regarding the temporary set-back in functionality? I don’t recall seeing it mentioned, as it probably would have delayed us upgrading.
Hello Chris,
thanks! :)
You are right, the temporary feature reduction in the context menu was not mentioned in the release notes.
We added it now: https://community.openproject.org/projects/openproject/wiki/Release_Notes_OpenProject_40_-_Work_package_details_pane
Sorry about any inconvenience.
As mentioned we will re-implement these features (#17531).
Best,
Robin
Chris wrote
Niels Wrote
Do you know which version drag and drop will be integrated into? Also, if/when you would have the recursive integrated?
Thanks
Brian
As others have said, getting back the right click functionality is essential to me. When I saw it was missing, it was depressing and made me not want to use OpenProject. I’m glad to see it’s coming back. Hopefully, it will be snappy and responsive. I’ve always hated waiting while it makes the changes and sends e-mails.
One feature we’d really like to see is the ability to create a group of work packages in one fell swoop. We have many different processes which have set list of steps we need to follow, and creating all the work packages manually is too time consuming. Currently, we list them in a wiki and make them off textually. Some of the process lists can be followed in a day or two, but others last for months. We would LOVE to have a way to create a group of work packages (either in the root or as the child of a specific and/or new work package) which is a copy of a named template of work packages. Even if we had to manually select them and edit details like the due date, target version, assignee, etc., it would be far better than what’s available to do it now. It would especially be great if there were both global and per-project templates for this. We often have per-project checklists to go through before creating a build for release, and it’s critically important to not miss a detail (we work on embedded, so once a build is deployed, if we missed a single detail, hundreds of units may come back as returns (thousands if we’re not lucky) if the detail is missed before shipping since the embedded systems usually can’t be field updated). Being able to have a maintainable checklist of workpackages template that can be used to generate the needed workpackages for testing a release would be incredibly helpful to reduce the stress associated with these releases. Likewise, having the ability to generate the workpackages for following the steps associated with any project would allow us to see the progression on the gantt chart without having to spend a lot of time to create, or copy in and modify, the workpackages for each project would be a huge time saver.
We would also very much like to have a finished date associated with any work package, or a datestamp associated with any change in status, so that we can see how it progressed over time.
It would also be nice to have a feature like Flow has, which allows you to see all of the people on a project and the tasks on their plates, and drag tasks from one person to another to reassign them. This would really help with load balancing across a team.
Mike Dean wrote:
+1
I’m just starting to implement OpenProject in our society and at this point this is the point wich cause us the more trouble, this would be really really usefull to have the ability to create a group of work packages from a template!!
Else thanks for the great job on this software!!
Hello Michael, hello Mike,
thanks for your feedback.
![](/api/v3/attachments/6606/content)
![](/api/v3/attachments/6607/content)
In order to create a group of work packages from a template, currently the easiest way would be to create a version “Template” (or similar) and assign the work package templates to this version. Then you can filter for them from the work package list (by selection the filter “Version is {Template}”).
The templates can be easily copied by selecting all the work packages (click on the check mark in the column header), right clicking on one of the lines and selecting “Copy” from the context menu.
Then you can (optionally) make some changes to the work packages (such as choosing a different version) and create the copied work packages:
@Mike: Drag and drop does not yet exist in the work package list but you can easily create a list with work packages assigned to the users in a project by going to the work package list and grouping by the “Assignee”.
![](/api/v3/attachments/6608/content)
).
You can then easily change the assignment by opening the split screen and changing the assignee of the work packages.
Drag and Drop is however planned for the work package list (see
Best,
Robin
Hello Robin,
this is a nice way to copy some work packages. But if you have a hirarchy with sub task this wont work! Because all sub task get as parent the old main task. But if this would get fixed it would be possible to create templates this way very simple!
I’ve introduced Open Project in our company for about two weeks, Open Project makes a good impression on our employees. I hope this project develops even further in the next time.
with kind regards
Hello Marc,
thanks for your answer.
Yes, you are right: Work packages in the hierarchy (child / parent work packages) will not be copied automatically along with the copied work packages. However, if you assign the work packages in the hierarchy to (e.g.) the same version and then filter for the version in the work package list, they will be displayed as well and they will be copied as well.
Great to hear you use OpenProject at your company!
For an overview of the current and upcoming OpenProject feature development you can take a look at the development timeline (which is constantly updated).
Best regards,
Robin
Hello Robin,
thanks for your reply. I think i dont understand exactly in which way it helps to copy work packages, when i’m assigning a version before copying. I’ve tried that, but the result is the same to me. The copied subtask had the same parent as before. It could be useful if you would be able to change the version in the copy-mask.
But is this still a wanted behavior that the same parent remains in the copied work packages?
—
I’m already following the activitys and the devlopment timeline. I am also willing to contribute to the project by reporting bugs and feature requests ;)
I’ve already did so far. But no response till now, May you can have a look at them. May I did something wrong?
#21268 , #21217 (This was a problem which is caused by the unuseful error messages you get in some cases. The error messages should be improved! New users cant figure out what they have done false and in this cases i’ve to find out what they did wront and how they have to do it right. this costs much time…) May i open another request for that?
Best regards,
Marc
Hello Marc,
sorry, I misread your message.
You are right: The parent work package is not changed for the copied child work packages. In a way this makes sense (e.g. when only one or more child work packages (without their parent) are copied).
However, when copying the parent and the child work packages it may make more sense to remove this old relationship.
Could you open a feature request in the Wish List for this behavior?
Thanks for your work packages.
I responded directly in the work packages to keep the conversation in one place.
Best regards,
Robin