Copy From feature not working on built-in fields in some places

What is 'tcf_component'? What kind of field and what's in it?

I believe you can only set Trac select fields to a value that exactly matches on of its options. Are you trying to set it to a non-existent option value?

( that was me, robguttman, who made that last comment )

Also, the CopyFrom? rule will only work if the target field is empty - i.e., it will not over-write an existing value. This is as-designed. Perhaps this is the problem? If so, then I can add an enhancement to give the option of overriding an existing value.

(In [8458]) refs #7561: added feature to optionally overwrite values when using the copy_from rule

(In [8459]) refs #7561: added feature to optionally overwrite values when using the copy_from rule

Sue, I added the overwrite option - seems like something others would want anyway. If this could solve your problem, please download the latest version and try again. If not, please respond to questions above. Thanks.

Hi Rob, Thanks for the quick reply! my tcf_component is a custom field, and I think the overwrite functionality will fix my issue! I will download it soon and test it out. Thanks again, Sue

Hi Rob, I finally got around to trying this, and it's not working for me. Perhaps I need to do more to "upgrade" a plugin to a new version. I simply downloaded the zip, unzipped on top of the old installation, and ran the install script again. I checked the rules.js file, and it has the new lines:

    if (spec.overwrite.toLowerCase() == 'false'){
        if (fld.val() != '' || fld.is(":hidden"))
            return;
    }

So, maybe I've done something wrong. The field I'm trying to overwrite is in fact hidden, and it actually seems to work fine if I unhide the value. Will continue debugging for a little while. Any help you can give would be great!

Sue

also, for the record, I'm using blackmagictweaks to hide the value, because the dynamicfields hide feature didn't hide the field from all form views, just the modify & new form views if i remember correctly.

Replying to anonymous:

Hi Rob, I finally got around to trying this, and it's not working for me. Perhaps I need to do more to "upgrade" a plugin to a new version. I simply downloaded the zip, unzipped on top of the old installation, and ran the install script again. I checked the rules.js file, and it has the new lines: if (spec.overwrite.toLowerCase() == 'false'){

if (fld.val() != ' ' fld.is(":hidden")) return; } So, maybe I've done something wrong. The field I'm trying to overwrite is in fact hidden, and it actually seems to work fine if I unhide the value. Will continue debugging for a little while. Any help you can give would be great! Sue

Sue, sorry you're still having problems. There is sometimes an egg cache file that needs to be deleted first before the new egg will work. (You're building a new egg and copying it to the plugins directoty, yes?) The egg cache file is usually in the trac project directory called something like ".egg-cache" (starts with a period). Delete that file and restart trac and see if that now takes the new code. You also may need to do a hard refresh (CTRL-SHIFT-R depending on browser) in the web browser to accept the new JS.

Replying to anonymous:

also, for the record, I'm using blackmagictweaks to hide the value, because the dynamicfields hide feature didn't hide the field from all form views, just the modify & new form views if i remember correctly.

Ah. What other views do you want the field to be removed from? Perhaps the custom query view? Email notifications? Others?

The feature works if I use the dynamicfields hide functionality as opposed to the blackmagic plugin, so I think I will use dynamicfields to hide. It would be nice to have it hidden from the ticket view (and all places really), since it just looks like the same field twice for the customization that I am implementing. But it's not an urgent feature request.

Ok, so perhaps some plungin conflict. What are the exact urls where dynfields is not hiding hidden fields but where you would like them hidden there, too?

Extracted from an email from Sue:

• Always hidden fields are still being shown in the top, read-only, yellow "header" section
• Always hidden fields are still shown in the custom query view
• Always hidden fields still appear in Trac emails

The first item above appears to be a bug. The second two are as-designed so I will take them as feature requests.

Sue, I moved the "always hide in other views" feature request to #7729.

I believe the only issue remaining is that you still see hidden fields in the top, read-only, yellow "header" section. Is this correct> If so, I suggest:

• Trying out the latest version of this plugin as that areas has changed a bit
• If that doesn't work, email me your ticket view's HTML source so I can diagnose further

If you no longer have this problem, then please close this ticket. Thanks.

Replying to robguttman:

Extracted from an email from Sue:
* Always hidden fields are still being shown in the top, read-only, yellow "header" section
* Always hidden fields are still shown in the custom query view
* Always hidden fields still appear in Trac emails
The first item above appears to be a bug. The second two are as-designed so I will take them as feature requests.

As I use AnnouncerPlugin to replace TracNotification, the email part requested may be even harder, if not out of control of the DynamicFieldsPlugin. And I try to make a better summary for this ticket, hope this helps a little more.

Replying to hasienda:

Replying to robguttman: ...

* Always hidden fields still appear in Trac emails

As I use AnnouncerPlugin to replace TracNotification, the email part requested may be even harder, if not out of control of the DynamicFieldsPlugin.

You may be right about the email part. The Custom Query field hiding is more sensible to keep in scope though - we'll see.

And I try to make a better summary for this ticket, hope this helps a little more.

Thanks although I recently created a new ticket for the "always hidden" feature - which was not the original problem Sue was having actually.

Assuming this issue is resolved - closing.

I'm having similar problems here. If I try to use the copy_from feature across 2 custom fields, then it works no problem ( although the 'overwrite option doesn't ever work - even on first population ), however as soon as I try to copy the Trac builtin field 'status', no dice. Is this field actually accessible ? If not, any other ideas on how I can do this would be appreciated.

status1 = text
status1.label = Custom status field 
status1.order = 290
status1.show_when_type = DEFECT
status1.copy_from = status