Project

General

Profile

Actions

Feature #5794

closed

URL custom fields

Added by Thibaut Cuvelier over 13 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Custom fields
Target version:
-
Start date:
2010-07-01
Due date:
% Done:

0%

Estimated time:
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>"


Files

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

Related issues

Related to Redmine - Feature #1358: Link_to for Custom FieldClosedJean-Philippe Lang2008-06-03

Actions
Related to Redmine - Feature #1179: Optionally allow Text and Long Text custom fields support wiki formattingClosedJean-Philippe Lang2008-05-05

Actions
Related to Redmine - Feature #2906: Refine the custom fields display for projectsNewJean-Philippe Lang2009-03-05

Actions
Related to Redmine - Feature #2083: CustomField of type "external-link-to" with configurable URL prefixClosedJean-Philippe Lang2008-10-24

Actions
Related to Redmine - Feature #5250: Custom Fields may allow full text transformationClosed2010-04-06

Actions
Related to Redmine - Feature #2792: allow title on any linkNew2009-02-20

Actions
Related to Redmine - Feature #15228: Custom field - provide link custom fieldClosed

Actions
Related to Redmine - Feature #13708: External related issuesClosed

Actions
Has duplicate Redmine - Feature #6755: Wiki field format for type for custom fieldClosed2010-10-27

Actions
Has duplicate Redmine - Feature #7391: Html link as custom fieldClosed

Actions
Is duplicate of Redmine - Feature #5697: Add new custom field - URL - type for usersClosed2010-06-16

Actions
Has duplicate Redmine - Feature #7859: Custom field type URLClosed2011-03-14

Actions
Has duplicate Redmine - Patch #3651: New URL custom field optionClosed2009-07-22

Actions
Actions #1

Updated by Jean-Baptiste Barth over 13 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.

Actions #2

Updated by Thibaut Cuvelier over 13 years ago

That would be even greater!

Actions #3

Updated by Jean-Baptiste Barth over 13 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).

Actions #4

Updated by Thibaut Cuvelier over 13 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!

Actions #5

Updated by Jean-Baptiste Barth over 13 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 !

Actions #6

Updated by Thibaut Cuvelier over 13 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").

Actions #7

Updated by Yuki Kita over 13 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.

Actions #8

Updated by Dylan Yee over 13 years ago

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

Actions #9

Updated by Jean-Baptiste Barth over 13 years ago

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

Actions #10

Updated by Thibaut Cuvelier over 13 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.

Actions #11

Updated by Jean-Baptiste Barth over 13 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...

Actions #12

Updated by Thibaut Cuvelier over 13 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.

Actions #13

Updated by Jean-Baptiste Barth over 13 years ago

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

Actions #14

Updated by Eric Davis over 13 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)

Actions #15

Updated by Robert Gruendler over 13 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?

Actions #16

Updated by Brian Lacy about 13 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!

Actions #17

Updated by Thibaut Cuvelier about 13 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!

Actions #18

Updated by Jean-Baptiste Barth about 13 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.

Actions #19

Updated by Etienne Massip about 13 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 ?

Actions #20

Updated by Etienne Massip about 13 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 :|

Actions #21

Updated by Ryan Cross about 13 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.

Actions #22

Updated by Luis Serrano Aranda about 13 years ago

This patch works in redmine 1.1.2 ?

how to use it?

Thanks

Actions #23

Updated by sandeep sp about 13 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?

Actions #24

Updated by Ian Epperson about 13 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

Actions #25

Updated by Ted Lilley about 13 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.

Actions #26

Updated by sandeep sp about 13 years ago

Thanks Ian,

Actions #27

Updated by Ted Lilley about 13 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.

Actions #28

Updated by Rodrigo Toledo over 12 years ago

Is this already merged with stable ?

Actions #29

Updated by Scryth Pervious over 12 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!

Actions #30

Updated by Jarosław Rencz over 12 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?

Actions #31

Updated by Terence Mill over 12 years ago

"This plugin" can have some code usable too.

Actions #32

Updated by Jean-Baptiste Barth almost 12 years ago

  • Assignee deleted (Jean-Baptiste Barth)
Actions #33

Updated by Anonymous over 11 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.

Actions #34

Updated by Jean-Philippe Lang about 11 years ago

  • Status changed from 7 to New

Assigned issue with no assignee back to New status.

Actions #35

Updated by Dipan Mehta about 11 years ago

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

Actions #36

Updated by Dipan Mehta about 11 years ago

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

Actions #37

Updated by Maxim Krušina almost 11 years ago

+1

Actions #38

Updated by Frédéric Géraud over 10 years ago

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

Actions #39

Updated by Diego Álvarez over 10 years ago

+1. It would be a great feature.

Actions #40

Updated by Mischa The Evil over 10 years ago

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

Updated by Frédéric Géraud over 10 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.

Actions #42

Updated by Jean-Philippe Lang over 10 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.

Actions #43

Updated by Toshi MARUYAMA almost 10 years ago

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

Updated by Toshi MARUYAMA almost 10 years ago

  • Has duplicate Patch #3651: New URL custom field option added
Actions #45

Updated by Toshi MARUYAMA almost 10 years ago

Actions

Also available in: Atom PDF