Opened 14 years ago
Closed 10 years ago
#7561 closed defect (fixed)
Copy From feature not working on built-in fields in some places
Reported by: | 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
comment:3 Changed 14 years ago by
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
comment:5 Changed 14 years ago by
comment:6 Changed 14 years ago by
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
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: 10 Changed 14 years ago by
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: 11 Changed 14 years ago by
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 Changed 14 years ago by
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 Changed 14 years ago by
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
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
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: 16 Changed 14 years ago by
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
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 follow-up: 17 Changed 14 years ago by
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 Changed 14 years ago by
Summary: | «Always hidden» feature not working on built-in fields in some places → 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 14 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Assuming this issue is resolved - closing.
comment:19 follow-up: 20 Changed 12 years ago by
Keywords: | copy_from added; hide rule removed |
---|---|
Priority: | normal → high |
Resolution: | fixed |
Severity: | normal → major |
Status: | closed → 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
comment:20 Changed 10 years ago by
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 10 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
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?