As per this thread, changes to the parent field of a work item record triggers an event to be fired, but the parent data is not present in the payload changes object. We should also include any data about the parent in object_attributes.
Additional Notes
This update focuses on enhancing the work items experience without altering the legacy epics experience.
This feature doesn't exist in the legacy experience, but that's an oversight/gap that we need to resolve.
Ping to @johnhope and @gweaver as well. The ~"group::ecosystem" team doesn't have the capacity to add the functionality to every webhook. The individual groups should take care of this themselves. However we are more happy to help, if there are any questions, so please feel free to reach out to us.
Setting the group to Project Management, because it relates to issues.
Hi all, just wanted to drop in on this issue and advise that we are experiencing this issue directly on a self-hosted instance. I've included instance details below.
Results of GitLab environment info
Expand for output related to GitLab environment info
(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)
System information
System: Ubuntu 18.04
Proxy: no
Current User: git
Using RVM: no
Ruby Version: 2.6.6p146
Gem Version: 2.7.10
Bundler Version:1.17.3
Rake Version: 12.3.3
Redis Version: 5.0.9
Git Version: 2.28.0
Sidekiq Version:5.2.9
Go Version: unknown
GitLab information
Version: 13.5.1-ee
Revision: a4cc9d130dd
Directory: /opt/gitlab/embedded/service/gitlab-rails
DB Adapter: PostgreSQL
DB Version: 11.9
URL: [REDACTED]
HTTP Clone URL: [REDACTED]
SSH Clone URL: [REDACTED]
Elasticsearch: no
Geo: no
Using LDAP: yes
Using Omniauth: yes
Omniauth Providers:
GitLab Shell
Version: 13.11.0
Repository storage paths:
- default: /var/opt/gitlab/git-data/repositories
GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell
Git: /opt/gitlab/embedded/bin/git
Results of GitLab application Check
Expand for output related to the GitLab application check
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)
Checking GitLab subtasks ...
Checking GitLab Shell ...
GitLab Shell: ... GitLab Shell version >= 13.11.0 ? ... OK (13.11.0)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Internal API available: OK
Redis available via internal API: OK
gitlab-shell self-check successful
Checking GitLab Shell ... Finished
Checking Gitaly ...
Gitaly: ... default ... OK
Checking Gitaly ... Finished
Checking Sidekiq ...
Sidekiq: ... Running? ... yes
Number of Sidekiq processes ... 1
Checking Sidekiq ... Finished
Checking Incoming Email ...
Incoming Email: ... Reply by email is disabled in config/gitlab.yml
Checking Incoming Email ... Finished
Checking LDAP ...
LDAP: ... Server: ldapmain
LDAP authentication... Success
LDAP users with access to your GitLab server (only showing the first 100 results)
User output sanitized. Found 51 users of 100 limit.
Checking LDAP ... Finished
Checking GitLab App ...
Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... yes
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ...
7/3 ... yes
2/8 ... yes
7/9 ... yes
7/14 ... yes
7/18 ... yes
7/22 ... yes
7/23 ... yes
7/25 ... yes
2/28 ... yes
2/30 ... yes
44/31 ... yes
43/32 ... yes
7/34 ... yes
51/35 ... yes
51/36 ... yes
7/37 ... yes
7/39 ... yes
7/40 ... yes
7/41 ... yes
7/42 ... yes
7/44 ... yes
7/45 ... yes
95/46 ... yes
97/47 ... yes
100/48 ... yes
Redis version >= 4.0.0? ... yes
Ruby version >= 2.5.3 ? ... yes (2.6.6)
Git version >= 2.24.0 ? ... yes (2.28.0)
Git user has default SSH configuration? ... yes
Active users: ... 50
Is authorized keys file accessible? ... yes
GitLab configured to store new projects in hashed storage? ... yes
All projects are in hashed storage? ... yes
Elasticsearch version 6.x - 7.x? ... skipped (elasticsearch is disabled)
Contributions like this are vital to help make GitLab a better product.
We would be grateful for your help in verifying whether your bug report requires further attention from the team. If you think this bug still exists, and is reproducible with the latest stable version of GitLab, please comment on this issue.
This issue has been inactive for more than 12 months now and based on the policy for inactive bugs, will be closed in 7 days.
Thanks for your contributions to make GitLab better!
We didn't have a chance to get to this in %16.2, so going to move it to %16.3. We're still at the top of our allotment of typebug, so the offer to groupproduct planning still stands!
@gweaver@amandarueda We haven't had a chance to look at this yet, but I do think it's not going to be super trivial. Since this is something that will be changed with the move to work items, I'm going to move it to the backlog and we'll make sure to account for webhooks in the migration.
@kushalpandya we've confirmed that work item epics fire webhooks for Issue Events. Do you know if updating the Parent widget on a work item epic will trigger a webhook event?
I tested this and changing a Task's parent (or unassigning from a parent) triggers an event to be fired, but the parent data is not present in the payload changes object.
FYI @amandarueda this is related to the parent widget and something we'll want to resolve for work items. Specifically, when updating the Parent widget, we should include the changes in the webhook event payload. I also noticed that we do not include any data about the parent in object_attributes. We should ;)
I'm going to move this to groupproduct planning since it's epic/parent hierarchy related, but if we have the capacity to fix it prior to work itemsga-issues I'll move it back.
Thanks @gweaver for testing it and identifying missing features!
@amandarueda Since Web Hooks were never a designated Epics feature, this would be nice to have but should not be a top priority for work itemspost-ga-first unless we run out of other parity/performance items under that label.
Amanda Ruedachanged the descriptionCompare with previous version
changed the description
Amanda Ruedachanged title from Changes to the Epic field in an issue never fire the webhook to Changes to the parent field of a work item doesn't include appropriate data
changed title from Changes to the Epic field in an issue never fire the webhook to Changes to the parent field of a work item doesn't include appropriate data