Feature #5794

URL custom fields

Added by Thibaut Cuvelier over 7 years ago. Updated almost 4 years ago.

Status:ClosedStart date:2010-07-01
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Custom fields
Target version:-
Resolution:

Description

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>"

5794_git_with_option.diff Magnifier (11.5 KB) Jean-Baptiste Barth, 2010-07-08 06:32

5794_git_without_option.diff Magnifier (7.54 KB) Jean-Baptiste Barth, 2010-07-08 06:32


Related issues

Related to Redmine - Feature #1358: Link_to for Custom Field Closed 2008-06-03
Related to Redmine - Feature #1179: Optionally allow Text and Long Text custom fields support... Closed 2008-05-05
Related to Redmine - Feature #2906: Refine the custom fields display for projects New 2009-03-05
Related to Redmine - Feature #2083: CustomField of type "external-link-to" with configurable ... Closed 2008-10-24
Related to Redmine - Feature #5250: Custom Fields may allow full text transformation Closed 2010-04-06
Related to Redmine - Feature #2792: allow title on any link New 2009-02-20
Related to Redmine - Feature #15228: Custom field - provide link custom field Closed
Related to Redmine - Feature #13708: External related issues Closed
Duplicated by Redmine - Feature #6755: Wiki field format for type for custom field Closed 2010-10-27
Duplicated by Redmine - Feature #7391: Html link as custom field Closed
Duplicates Redmine - Feature #5697: Add new custom field - URL - type for users Closed 2010-06-16
Duplicated by Redmine - Feature #7859: Custom field type URL Closed 2011-03-14
Duplicated by Redmine - Patch #3651: New URL custom field option Closed 2009-07-22

History

#1 Updated by Jean-Baptiste Barth over 7 years ago

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.

#2 Updated by Thibaut Cuvelier over 7 years ago

That would be even greater!

#3 Updated by Jean-Baptiste Barth over 7 years ago

On second thought, I wonder if the option is useful : I was thinking about unwanted spam, but it's exactly the same for the description of the issue. So maybe those fields should be textilized by default.

So I leave 2 patches, one with the optional thing (implying a migration and a new locale key..), the other without the option (much more simple).

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

#4 Updated by Thibaut Cuvelier over 7 years ago

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!

#5 Updated by Jean-Baptiste Barth over 7 years ago

  • Status changed from New to 7
  • Assignee set to Jean-Baptiste Barth

I'm french too ;) It's really easy to edit those files, just look at the english translation file, you just have to add the same key to "config/locales/fr.yml" with the same spaces before key, and your translation after ":". Anyway, if the second patch works for you it's OK !

#6 Updated by Thibaut Cuvelier over 7 years ago

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").

#7 Updated by Yuki Kita about 7 years ago

+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.

#8 Updated by Dylan Yee about 7 years ago

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

#9 Updated by Jean-Baptiste Barth about 7 years ago

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

#10 Updated by Thibaut Cuvelier about 7 years ago

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.

#11 Updated by Jean-Baptiste Barth about 7 years ago

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...

#12 Updated by Thibaut Cuvelier about 7 years ago

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.

#13 Updated by Jean-Baptiste Barth about 7 years ago

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

#14 Updated by Eric Davis about 7 years ago

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)

#15 Updated by Robert Gruendler almost 7 years ago

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?

#16 Updated by Brian Lacy almost 7 years ago

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!

#17 Updated by Thibaut Cuvelier over 6 years ago

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!

#18 Updated by Jean-Baptiste Barth over 6 years ago

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.

#19 Updated by Etienne Massip over 6 years ago

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 ?

#20 Updated by Etienne Massip over 6 years ago

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

Can't we :
  • 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 :|

#21 Updated by Ryan Cross over 6 years ago

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.

#22 Updated by Luis Serrano Aranda over 6 years ago

This patch works in redmine 1.1.2 ?

how to use it?

Thanks

#23 Updated by sandeep sp over 6 years ago

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?

#24 Updated by Ian Epperson over 6 years ago

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

to get

link to Google

#25 Updated by Ted Lilley over 6 years ago

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.

#26 Updated by sandeep sp over 6 years ago

Thanks Ian,

#27 Updated by Ted Lilley over 6 years ago

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.

#28 Updated by Rodrigo Toledo over 6 years ago

Is this already merged with stable ?

#29 Updated by Scryth Pervious about 6 years ago

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!

#30 Updated by Jarosław Rencz almost 6 years ago

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>

instead of expected:
Custom url field: http://foo.bar/

can it be fixed?

#31 Updated by Terence Mill almost 6 years ago

"This plugin" can have some code usable too.

#32 Updated by Jean-Baptiste Barth over 5 years ago

  • Assignee deleted (Jean-Baptiste Barth)

#33 Updated by Boris Tsema almost 5 years ago

+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.

#34 Updated by Jean-Philippe Lang almost 5 years ago

  • Status changed from 7 to New

Assigned issue with no assignee back to New status.

#35 Updated by Dipan Mehta over 4 years ago

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

#36 Updated by Dipan Mehta over 4 years ago

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

#37 Updated by Maxim Krušina over 4 years ago

+1

#38 Updated by Frédéric Géraud about 4 years ago

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

#39 Updated by Diego Álvarez about 4 years ago

+1. It would be a great feature.

#40 Updated by Mischa The Evil almost 4 years ago

  • Related to Feature #15228: Custom field - provide link custom field added

#41 Updated by Frédéric Géraud almost 4 years ago

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.

#42 Updated by Jean-Philippe Lang almost 4 years ago

  • Status changed from New to Closed

2.5.0 adds "Link" custom fields and support for optional textile support on text and long text custom field.

#43 Updated by Toshi MARUYAMA over 3 years ago

  • Related to deleted (Patch #3651: New URL custom field option)

#44 Updated by Toshi MARUYAMA over 3 years ago

  • Duplicated by Patch #3651: New URL custom field option added

#45 Updated by Toshi MARUYAMA over 3 years ago

Also available in: Atom PDF