ns_job_modify currently triggers a re-arm, but does not make this clear to the user.
As a result, after a ns_job_modify, you may not longer access the job.
There are cases where you may want to access a job after modify though,
ns_job_modify should be altered to not re-arm the job automatically.
The logic in ns_job_modify for re-arming to a queue, should move to ns_job_rearm.
attachment 0004-Ticket-52-ns_job_modify-should-not-rearm.patch
I think this affects 389-ds-base code, as well. We need to make 389-ds-base and nunc-stans in sync, right? In such a case we may want to open a 389 ticket to mention it...
I have already examined the DS code. It does not use nor rely on this behavior. So no changes to DS needed.
Thanks fro the confirmation! Relieved. :)
commit 7a4ce78 Compressing objects: 100% (25/25), done. Writing objects: 100% (27/27), 50.14 KiB | 0 bytes/s, done. Total 27 (delta 20), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/nunc-stans.git 7ef7ec1..7a4ce78 master -> master
Login to comment on this ticket.