Bug 988276

I think this actually qualifies as a bug against 960302

The default assumption is that jobs are cloned for submission by the user doing the cloning, so "Owner" is not one of the cloned properties.

Nominating a separate owner for a job is a property of the act of submitting a job, not a persistent property of the job itself.

(In reply to Nick Coghlan from comment #3)
Point 1: If the owner add himself in the delegate list, then submit a group job for himself. Owner and delegate user is the same, but the original xml is still changed.

Point 2: If I was a customer, it's not a good interactive to change the original xml. For my point of view, the xml is user's input.

So I think this is a bug. Assign back this bug.

The problem is that the job attributes are more about a particular job *run* and less an inherent property of the job itself. As dcallagh noted on IRC, it may have been better if those attributes had all been passed as separate settings rather than being embedded in the XML, precisely to avoid this ambiguity on what it means to clone a job.

However, given the precedent set by the existing "group", "retention_tag" and "product" attributes, I'm willing to concede that preserving the "user" attribute is the right thing to do.

I don't consider it a blocker for 0.14, but we should address it for 0.15.

Current job attributes in the XML:

- user (sets the job owner to someone other than the submitter)
- group (sets group access for the job, job owner must be a member of that group)
- retention_tag (preserves the retention tag of the job as it currently exists, not as it was originally submitted)
- product (preserves the product of the job as it currently exists, not as it was originally submitted)

The latter 3 are all duplicated when cloning, the "user" setting currently is not.

Preserving all these is likely the right thing to do when a submitter clones and resubmits their own job.

Preserving retention_tag and product is likely wrong if they have been modified since the original submission.

Preserving user and group is likely wrong if the user doing the cloning isn't the original submitter.

If we nominate "clone and resubmit by original submitter" as the guiding use case for deciding the default behaviour of job cloning (with other use cases potentially requiring the deletion of unwanted attributes), then it makes sense to copy user as well.

(In reply to Nick Coghlan from comment #5)
> The problem is that the job attributes are more about a particular job *run*
> and less an inherent property of the job itself. As dcallagh noted on IRC,
> it may have been better if those attributes had all been passed as separate
> settings rather than being embedded in the XML, precisely to avoid this
> ambiguity on what it means to clone a job.
> 

So does that make it such that anything that is not 'inherent' to the job is no longer passed in XML? How do we decide what that is? 

> However, given the precedent set by the existing "group", "retention_tag"
> and "product" attributes, I'm willing to concede that preserving the "user"
> attribute is the right thing to do.
> 
> I don't consider it a blocker for 0.14, but we should address it for 0.15.

(In reply to Nick Coghlan from comment #6)
> Current job attributes in the XML:
> 
> - user (sets the job owner to someone other than the submitter)
> - group (sets group access for the job, job owner must be a member of that
> group)
> - retention_tag (preserves the retention tag of the job as it currently
> exists, not as it was originally submitted)
> - product (preserves the product of the job as it currently exists, not as
> it was originally submitted)
> 
> The latter 3 are all duplicated when cloning, the "user" setting currently
> is not.
> 
> Preserving all these is likely the right thing to do when a submitter clones
> and resubmits their own job.
> 
> Preserving retention_tag and product is likely wrong if they have been
> modified since the original submission.
> 

I think this is all a bit of a grey area and different people perhaps expect different things.

IMHO, if someone clicks on clone, they should expect to get a copy of that job as it is when they click on the clone button. That would be consistent and reasonably expected. I think what would be less expected is if someone (especially not the original submitter) came along and clicked on clone and got a job that was quite different from the one he thought he was cloning (i.e different retention tag, product, priority, cc, whiteboard etc....we would be preserving the original setting for all of these changeable fields right?)

Although we have open bugs about properties of jobs changing between submission and cloning, and the changed properties being part of the cloned job (i.e priority), and those bugs also seem valid.





> Preserving user and group is likely wrong if the user doing the cloning
> isn't the original submitter.
> 
> If we nominate "clone and resubmit by original submitter" as the guiding use
> case for deciding the default behaviour of job cloning (with other use cases
> potentially requiring the deletion of unwanted attributes), then it makes
> sense to copy user as well.

when I submit a job1 on behalf of user1, then job1 will be displayed on my job page, but the owner is user1, there is not any item of the job1 could indicate the relationship with me so that I could make sure the reason why it is on my job page, if the attribute 'user="user1"' could remain in the xml, then the xml could indecate that by cloning the job1.

also I could note it in whiteboard, but whiteboard could be changed by others sometimes, so I don't think it's an official way to indicate the relation between job1 and me.

or we could design a better way, then I could add another RFE bug.
thanks!

The lack of indication in the UI of who submitted a job is a different problem - the submitter ID should be displayed on the job details page. That's definitely a separate RFE, though.

On the "My Jobs" page, the *only* way for a job to appear with an owner other than yourself is if you submitted it on their behalf. (There may be a docs bug in that - I'm not sure we mention the possibility in the user guide. If the submitter ID was shown on the job details page, I expect that would be clear enough)

The reason I think cloning is murky for retention tags is that things like "audit" may be special - just because the results of the *previous* run are being kept around for auditing doesn't mean that the results of the *cloned* run should be kept.

Basically, I think there are four fields where it is somewhat dubious to keep them the same by default when cloning a job:

- user (the person submitting the cloned job may not be a submission delegate of that user)
- group (the person submitting the cloned job may not be a member of that group)
- priority (the priority should be the default priority)
- retention_tag (the default retention tag should be used)

*However*, and this is the important bit, I think the *precedent* that has been established is for them to be copied, even if doing so is a little dubious. Changing that for the three fields fields that are currently copied would risk breaking existing automation tools.

A potential third alternative might be to retain all these fields when a job is cloned by the original submitter or the job owner, but reset them to their defaults when a job is cloned by someone else.

Hi,

I'd

Current team agrees with what Nick has said. We might address this in the feature, but it isn't we'd like to pursue right now