Modify

Opened 4 years ago

Last modified 21 months ago

#7561 reopened defect

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

Reported by: sue.sml2006@… Owned by: robguttman
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 (19)

comment:1 Changed 4 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 4 years ago by robguttman

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

comment:3 Changed 4 years ago by robguttman

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 4 years ago by robguttman

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

comment:5 Changed 4 years ago by robguttman

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

comment:6 Changed 4 years ago by robguttman

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 4 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 follow-up: Changed 4 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 follow-up: Changed 4 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 4 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 4 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 4 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 4 years ago by robguttman

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 follow-up: Changed 4 years ago by 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.

comment:15 Changed 4 years ago by robguttman

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 ; follow-up: Changed 4 years ago by hasienda

  • Keywords hide rule added
  • Summary changed from Copy From feature not working on built in fields to «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 4 years ago by robguttman

  • Summary changed from «Always hidden» feature not working on built-in fields in some places to Copy 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 4 years ago by robguttman

  • Resolution set to fixed
  • Status changed from new to closed

Assuming this issue is resolved - closing.

comment:19 Changed 21 months ago by phooper0001@…

  • Keywords copy_from added; hide rule removed
  • Priority changed from normal to high
  • Resolution fixed deleted
  • Severity changed from normal to major
  • Status changed from closed to reopened

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 

Add Comment

Modify Ticket

Action
as reopened .
Author


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

 
Note: See TracTickets for help on using tickets.