Add an "hide_always" option to Hide Rule

[Rob Guttman]

This is an enhancement extracted from defect #7561

The current way to always hide a field is:

alwayshidden.show_when_type = invalid_value

This works but is a bit hacky from an interface perspective. Also, there's a feature request to always hide fields in other views such as:

• Always hidden fields are still shown in the custom query view
• Always hidden fields still appear in Trac emails

An "always_hide" option could replace the alwayshidden.show_when_type = invalid_value approach with a cleaner interface and enable the always hiding of fields in other views.

[Rob Guttman]

(In [9667]) refs #7729: added "hide_always" option to Hide Rule which also hides field on custom query page

[Rob Guttman]

The dynfields plugin will now hide always-hidden fields in the customer query view (/query). You can also specify a field to always hide using a new rule syntax:

alwayshide.hide_always = True

(The old-style 'hacky' syntax will also still work.)

[Rob Guttman]

Note that I did not yet handle hiding fields in Trac emails - a candidate future enhancement.

[Steffen Hoffmann]

(In [9690]) DynamicFieldsPlugin: Merge changeset [9667] to 0.12 branch, refs #7729.

This removes the unsane "invalid_value" in favor of a clearer "hide_always" option which also hides field on custom query page now. Fixes small errors in post_process_request methode of the DynamicFieldsModule component too and stricter follows PEP8, especially when writing logic 'and'/'or' before a line-break.

_Beware:_ This version is non-functional yet and need more changes, so please stick to previous versions, if you're not developing yourself.

[sue.sml2006@…]

Customers_impacted field is set to hide_always, and it's not visible in the columns, but is visible in the drop-down menu

[sue.sml2006@…]

My organization is finally getting around to upgrading trac and plugins. I am attempting to use the hide_always setting, but it's not working for me. In the screenshot attached, customers_impacted is set to hide_always, and is not visible as a column, but is in the drop down. Additionally, the Component field is set to hide_always and it is visible in both places. Not sure what could be wrong, any pointers would be great.

[Rob Guttman]

Replying to sue.sml2006@gmail.com:

My organization is finally getting around to upgrading trac and plugins. I am attempting to use the hide_always setting, but it's not working for me. In the screenshot attached, customers_impacted is set to hide_always, and is not visible as a column, but is in the drop down. Additionally, the Component field is set to hide_always and it is visible in both places. Not sure what could be wrong, any pointers would be great.

Sue, what version of Trac are you using? I believe I see the problem in Trac 0.12.2 which I will now fix.

[Rob Guttman]

(In [10270]) refs #7729: fixed hide_always for Trac 0.12.2

[Rob Guttman]

Sue, if you're using Trac 0.12.2, please try the latest version of the 0.11 branch. (Yes, the 0.11 branch.)

[sue.sml2006@…]

I'm not quite sure how to upgrade my plugins. this has always been a bit of a mystery to me. I tried updating the rules.js that looks like the only file that changed, but maybe I'm not doing it right. I'm on vacation until 6/27. I'll try it again when i get back. any pointers on plugin upgrading would be excellent! i haven't found good documentation on it anywhere.

[Steffen Hoffmann]

Replying to sue.sml2006@gmail.com:

I'm not quite sure how to upgrade my plugins. this has always been a bit of a mystery to me.

There're certainly others around on the web, but edgewall.org is still the reference, so you could read about ​Installing a Trac Plugin in the Trac wiki.

[Rob Guttman]

Sue, Steffen (hasienda) provides good general advice above. One specific tip is that you may sometimes need to manually remove the older version of the plugin from the site-packages or dist-packages dir. A sample command to help find the existing egg/dir location:

% sudo find / -name TracDynamicFields*

Then rm -rf the old found dir above before installing the new one (e.g., sudo python setup.py install as one way to install). This isn't always necessary to upgrade but can help the plugin find and use the correct resources.

[Steffen Hoffmann]

To make it even more complete:

Watch out for any egg-cache, where decompressed eggs are stored, typically when not using tracd but a real webserver to power Trac. I've struggled to see the new plugin code working in such a Trac instance some time ago. After removing the egg-cache it was re-generated on next webserver start (or needed to be regenerated before that?), and then it worked as expected.

[Rob Guttman]

This feature was implemented some time ago.