Modify

Opened 14 years ago

Closed 9 years ago

#7561 closed defect (fixed)

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

Reported by: sue.sml2006@… Owned by: Rob Guttman
Priority: high Component: DynamicFieldsPlugin
Severity: major Keywords: copy_from
Cc: Trac Release: 0.11

Description

I am trying to use dynamicfields plugin to copy in a component value from another custom field with the dynamic fields plugin, but it's not working at all. The plugin is enabled and i can see it in the plugins admin interface, but it's having no effect on the component field at all. I'm using the syntax: component.copy_from = tcf_component What am I missing? Thanks in advance for any help.

(I can overcome this by using chainedfields plugin but would rather get this plugin working for other purposes)

Attachments (0)

Change History (21)

comment:1 Changed 14 years ago by anonymous

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?

comment:2 Changed 14 years ago by Rob Guttman

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

comment:3 Changed 14 years ago by Rob Guttman

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.

comment:4 Changed 14 years ago by Rob Guttman

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

comment:5 Changed 14 years ago by Rob Guttman

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

comment:6 Changed 14 years ago by Rob Guttman

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.

comment:7 Changed 14 years ago by anonymous

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

comment:8 Changed 14 years ago by 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

comment:9 Changed 14 years ago by 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.

comment:10 in reply to:  8 Changed 14 years ago by anonymous

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.

comment:11 in reply to:  9 Changed 14 years ago by anonymous

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?

comment:12 Changed 14 years ago by anonymous

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.

comment:13 Changed 14 years ago by Rob Guttman

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?

comment:14 Changed 14 years ago by Rob Guttman

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.

comment:15 Changed 14 years ago by Rob Guttman

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.

comment:16 in reply to:  14 ; Changed 14 years ago by Steffen Hoffmann

Keywords: hide rule added
Summary: Copy From feature not working on built in fields«Always hidden» feature not working on built-in fields in some places

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.

comment:17 in reply to:  16 Changed 14 years ago by Rob Guttman

Summary: «Always hidden» feature not working on built-in fields in some placesCopy From feature not working on built-in fields in some places

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.

comment:18 Changed 14 years ago by Rob Guttman

Resolution: fixed
Status: newclosed

Assuming this issue is resolved - closing.

comment:19 Changed 12 years ago by phooper0001@…

Keywords: copy_from added; hide rule removed
Priority: normalhigh
Resolution: fixed
Severity: normalmajor
Status: closedreopened

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 

comment:20 in reply to:  19 Changed 9 years ago by Ryan J Ollos

Replying to phooper0001@…:

however as soon as I try to copy the Trac builtin field 'status', no dice. Is this field actually accessible ?

#8400 discussed limitations of the status field.

comment:21 Changed 9 years ago by Ryan J Ollos

Resolution: fixed
Status: reopenedclosed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Rob Guttman.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.