Bug #5778
closed
dynflow task locks are left after updating user via api
Description
id | task_id | name | resource_type | resou
rce_id | exclusive
------+--------------------------------------+------------+---------------+------
-------+-----------
5654 | 8d06d9b6-7f26-4585-b7b0-386b68c1999a | task_owner | User |
1 | f
5655 | 8d06d9b6-7f26-4585-b7b0-386b68c1999a | read | User |
65 | t
5656 | 8d06d9b6-7f26-4585-b7b0-386b68c1999a | write | User |
65 | t
After updating users via api, there are many locks in foreman_tasks_locks table.
Updated by Thomas McKay over 9 years ago
- Bugzilla link set to https://bugzilla.redhat.com/show_bug.cgi?id=1098730
Updated by Dominic Cleal over 9 years ago
- Project changed from Foreman to foreman-tasks
- Category deleted (
Orchestration)
Updated by Ivan Necas over 9 years ago
- Status changed from New to Assigned
- Assignee set to Ivan Necas
Updated by Ivan Necas over 9 years ago
The problem occurres, when the password is being changed with Katello in place, as it
triggers the orchestration just when there is something in `changes` attribute.
However, the `changes` attribute is updated by a before_update callback (setting
the salt and hashed password), leading to a situation when the task is planned
but never executed.
Updated by Ivan Necas over 9 years ago
- Status changed from Assigned to Ready For Testing
Updated by Ivan Necas over 9 years ago
- Status changed from Ready For Testing to Closed