Redmine

It would be a good idea to have a more generic solution : custom field could be marked as "textilized", and benefit from all the text formatting rules if so. If not (maybe it could lead to unwanted spam?), they would show as they do now. Anyway, it won't be in stable branch before 1.1 I suppose.

Tell me what do you think, I'll provide a patch if this is ok.

That would be even greater!

I have applied the without_option patch (no choice: hosting only French-speaking projects on a French-speaking website... and not enough knowledge to hack that much the translations). And it works great!

Just a little thing that could be improved (maybe not so easily): after every custom tag, there is a new <p> block, which causes the value of the tag to be on the next line. It would be great if you could make this mark disappear (it is now actually not so good-looking: http://projets.developpez.com/projects/qextend, around "Licence").

+1

Jean-Baptiste Barth wrote:

I'd really like to read the opinion of some contributors about this functionality (optional or not).

I'd prefer the latter one(5794_git_without_option.diff). I think custom fields should be textilized by default like issue descriptions.

I tested the 5794_git_without_option.diff and it works perfectly. Great to have this, thanks~

Thibaut: do you have an idea of what we can do for that ?

Jean-Baptiste Barth wrote:

Thibaut: do you have an idea of what we can do for that ?

Well, I'd say to textilize by default the custom fields. That's the one I'm using and it's working perfectly - and I'm not the only one it seems.

Thibaut Cuvelier wrote:

Well, I'd say to textilize by default the custom fields. That's the one I'm using and it's working perfectly - and I'm not the only one it seems.

Yes, I was talking about the <p> tags around: I don't like the idea of stripping them manually, and it would be much more difficult to change our formatter to render text without them. I don't see if it is so annoying...

Jean-Baptiste Barth wrote:

Yes, I was talking about the <p> tags around: I don't like the idea of stripping them manually, and it would be much more difficult to change our formatter to render text without them. I don't see if it is so annoying...

It is not really clean to get rid of them that way; maybe the renderer could get updated to have one more option which would deactivate the <p> tags (this could be useful somewhere else). The only disturbing thing is that these tags force a return after the custom field text and the registered value for that field; it is not really a very important issue IMHO.

OK thanks, I'll have a look at that. And thanks to others who have tested this patch!

Jean-Baptiste Barth:

I started on a plugin to support url custom fields. I had it working so that each custom field type could say "HTML escape my value" or "don't escape my value" (escape_html? method). It worked but felt really insecure which is why I never finished it. I'm open to suggestions.

http://github.com/edavis10/redmine_url_custom_field

(This will also make it really easy to add custom fields for new data types. List of users, list of projects, list of versions, etc)

we're trying to use this plugin to be able to link our issues to google docs easily. As far as my poor ruby skills let me judge that, it's not possible at the moment unless you remove the h() call in issuess_helper.rb -> render_custom_fields_rows(), which apparently escapes the html from the link:

http://www.redmine.org/projects/redmine/repository/entry/trunk/app/helpers/issues_helper.rb#L95

Am i right with that, or is there another way to do this without hacking redmine core?

I just posted on #1358 before I realized this one was more recent. Here's my original comment:

We're just getting started with Redmine, and I've added a Custom Field on Issues called "URL" -- intended primarily for test cases. As a web developer, being able to link to a page where an issue is occurring or which is the starting point for a new feature would be a huge help -- but unfortunately, there's no way to auto-highlight that URL.

Can you folks please resurrect this issue and add a new custom field type "URL"? Would be very handy!

Thanks!

Is this going to be planned for some future release? Or will it be a plug-in? (It's just annoying to apply the patch each time I update Redmine...)

Thanks!

The "without option" patch, plus stripping "<p>" tags manually could be integrated imho. I think regarding the security we don't introduce any problem that is not present in standard notes on issues.

I'd like to have the opinion of other contributor before integrating it in trunk.

Maybe that would be safer to integrate the with_option patch and stick to 'plain text' default, because we can't know the values the custom fields around the world are filled in with ?

Is a one-line textilized text field really useful except for URLs ?

• Either add an option "Scan for URLs" to existing Text field type (see this note) or even make it a default behavior or add a new URL field type
• Add a distinct "Formatted text" field type (with a "multiline" option rendering a text area) ?

There is a global "Text formatting" setting which let to think that text could be formatted by some plugin or not formatted at all, but I'm unsure if it concerns only wiki or not (see #2025) ?

+Update : this setting looks to be used for formatting text everywhere : #2985.
Update 2 : update 1 is wrong :|

email addresses would be another "formatter" needed.

I think the other thing to consider would be adding some predefined regex validation for url or email fields. From a db perspective, they are just text fields still just a few extra bits of business & display logic.

This patch works in redmine 1.1.2 ?

how to use it?

Thanks

Thibaut Cuvelier wrote:

Custom fields can also be used to store URLs, but they are shown as simple text. E.g., here: http://projets.developpez.com/projects/odyssea-media-center; the forum line (we are using an independent forum, as it is the base of our community - we just started hosting projets in 2008).

What happens now: the URL is shown as text.
What I'm expecting to see: a <a href=""> markup around (ideally being able to configure separately the href and the text, or let the text empty so that Redmine is putting the link on the field name).

Now: "Forum: http://..."
Wanted: "<a href="http://">Forum</a>" or "Forum: <a href="http://...">our beautiful forum</a>"

Hi, I Applied the patch, can anyone tell me, how to use this custom field for URL?
what is the syntax type?

Hi, I Applied the patch, can anyone tell me, how to use this custom field for URL?
what is the syntax type?

I believe this is simply using the default wiki syntax (textualize) - which means that for a URL you should type:

"link to Google":http://www.google.com

link to Google

Hey guys,

I'm for the "by default" option as well.

There's only one thing more I could ask for on this, which may be a feature creep, but I sure know it would be useful for us: if the field contains an email address, it would be nice for the subject of the resulting mailto: link to contain the syntax necessary for redmine's email receipt feature to associate the email back to the issue, namely "[#123]" with the appropriate id of course.

Thanks Ian,

Hello again,

I applied the patch (without option) to the latest released redmine, and while there were several rejections, I was able to integrate them smoothly by hand. The patch appears to be functional here.

However, I do have a request, which would be to move the call to format_value in custom_fields_helper.rb to before the textilizing call.

The reason for this is that if done after, I get issues in using my own custom field formatter. It needs access to the raw value and wants to be textilized after it has had a chance to render itself.

The background is that I've implemented a custom formatter for email addresses, which I mentioned in my last post. I was able to do this using Redmine's facility for defining custom field formats, detailed here: http://theadmin.org/articles/2010/04/16/daily-refactor-extract-class-to-custom-field-format/

What it does is add a new custom field type, called "email", that allows the field to be rendered with a custom formatter. The custom formatter simply returns <a href=\"mailto:#{value}\">#{value}</a>, which creates a mailto link for whatever string email address is in the field. There's a few files that need to modified to do this, so message me if you'd like a patch.

The field won't actually render to a link by itself, which is why your patch was needed. However, when the patch was applied, the links would render but not properly. Instead of the correct mailto link, I'd get mailto:<p>email address</p> where the <p> tags came from the textilization in custom_fields_helper.rb.

I was able to fix it by moving the custom formatter prior to the textilization in that file. Here's a diff:

diff --git a/app/helpers/custom_fields_helper.rb b/app/helpers/custom_fields_helper.rb
--- a/app/helpers/custom_fields_helper.rb
+++ b/app/helpers/custom_fields_helper.rb
@@ -89,25 +89,26 @@ module CustomFieldsHelper
     end

   end

   # Return a string used to display a custom value

   def show_value(custom_value, options = {})

     return "" unless custom_value

     options = {:textilize => true, :simple_format => false}.merge(options)

     value = custom_value.value

+    value = format_value(value, custom_value.custom_field.field_format)

     if options[:simple_format]

       value = simple_format_without_paragraph(h(value))

     elsif options[:textilize]

       value = textilizable(value)

     else

       value = h(value)

     end

-    format_value(value, custom_value.custom_field.field_format)

+    value

   end

   # Return a string used to display a custom value

   def format_value(value, field_format)

     Redmine::CustomFieldFormat.format_value(value, field_format) # Proxy

   end

   # Return an array of custom field formats which can be used in select_tag

I'd ask that you consider making the same change in your code.

Thanks.

Is this already merged with stable ?

Hello All,

I absolutely love Redmine, but I have been trying to get this feature to work for my install of 1.1.3 stable and everything I try just ends up having it crash my install. I really need to try and get it to work if possible, and any help would be great!

plugin works fine but there's one inconvenience: field content is formated also in email notice. At least in Gmail.

I get:

Custom url field: <a href="http://foo.bar/">http://foo.bar/</a>

Custom url field: http://foo.bar/

can it be fixed?

"This plugin" can have some code usable too.

+1 to this feature
In out project we need to insert URLs in field, and it's much more convenient to "just click" to the link than copy it to the address field.

+1. Though I use the plugin to achieve this, I think this is really necessary feature to have.

Add another related issue - #2792. #2792 and #5794 are almost duplicates.

+1

+1 for this feature, it would be usefull for us.

+1. It would be a great feature.

After a few months working without this feature, the best functionnality would be to turn any url in a custom text field into a clickable hyperlink.