#1540 RFE - New meta-data custom field type of "URL"
Closed: Fixed 7 years ago Opened 7 years ago by mreynolds.

Currently when you add a custom field to the meta-data of an Issue you can choose "text" or "boolean". It would be great if there was a new type of "URL", or "Link", that the html renderer could convert into a clickable link.


This is looking good but a few things:

  • the type is link while you split on commas, so it supports multiple links,
    maybe we could rename it to links instead? Or just drop having multiple
    links in that field which in a way sounds more appealing to me (also cf below
    about validation)
  • I had to make few adjustments to get it working:
diff --git a/ pagure/templates/issue.html b/ pagure/templates/issue.html
index a5a0ea7..639ac7a 100644
--- a/ pagure/templates/issue.html      
+++ b/ pagure/templates/issue.html      
@@ -324,13 +324,15 @@
             <label><strong>{{ field.name }}</strong></label>
             <div id="{{ field.name }}_plain">
               <p>
-                {% if field.key_type == 'link' %}
-                  {% for link in knowns_keys[field.name].value.split(',') %}
-                    <a target="_blank" href="{{ link }}">{{ link }}</a>
-                    <br>
-                  {% endfor %}
-                {% else %}
-                  {{ knowns_keys[field.name].value if field.name in knowns_keys }}
+                {%  if field.name in knowns_keys %}
+                  {% if field.key_type == 'link' %}
+                    {% for link in knowns_keys[field.name].value.split(',') %}
+                      <a target="_blank" rel="noopener noreferrer" href="{{ link }}">{{ link }}</a>
+                      <br>
+                    {% endfor %}
+                  {% else %}
+                    {{ knowns_keys[field.name].value }}
+                  {% endif %}
                 {% endif %}
               </p>
             </div>
diff --git a/ pagure/templates/settings.html b/ pagure/templates/settings.html
index f5cb450..c9bc445 100644
--- a/ pagure/templates/settings.html   
+++ b/ pagure/templates/settings.html   
@@ -951,6 +951,7 @@ $('#new_custom_field').click(function(e) {
            <select name="custom_keys_type" class="form-control"> \
             <option value="text">text</option> \
             <option value="boolean">boolean</option> \
+            <option value="link">link</option> \
           </select> \
         </div> \
       </div>'

Mind adding this to your commits? Or do you prefer me putting it on the top of
it?

I was also wondering if there should be some validation in this case, maybe
something using validators.URL() from wtforms? I do not know if that
validator would work well for our current input since we allow multiples URLs to
be passed (one argument in favor of allowing just one URL imho).

We will also need to adjust the issue_ev.js once we're merged the PR allowing to
live refresh the values of the custom fields based on notifications from the SSE
server.

This is looking good but a few things:

the type is link while you split on commas, so it supports multiple links,
maybe we could rename it to links instead? Or just drop having multiple
links in that field which in a way sounds more appealing to me (also cf below
about validation)

I'll change it to links. We need to "link" multiple bugzilla's to a single issue. So it needs to be multi-valued. More on this below.

I had to make few adjustments to get it working:

Odd, perhaps the code base changed since I attached my patch? It was fully functional in my dev env a few days ago.

diff --git a/ pagure/templates/issue.html b/ pagure/templates/issue.html
index a5a0ea7..639ac7a 100644
--- a/ pagure/templates/issue.html
+++ b/ pagure/templates/issue.html
@@ -324,13 +324,15 @@
<label>{{ field.name }}</label>



- {% if field.key_type == 'link' %}
- {% for link in knowns_keys[field.name].value.split(',') %}
- {{ link }}
-

- {% endfor %}
- {% else %}
- {{ knowns_keys[field.name].value if field.name in knowns_keys }}
+ {% if field.name in knowns_keys %}
+ {% if field.key_type == 'link' %}
+ {% for link in knowns_keys[field.name].value.split(',') %}
+ {{ link }}
+

+ {% endfor %}
+ {% else %}
+ {{ knowns_keys[field.name].value }}
+ {% endif %}
{% endif %}



diff --git a/ pagure/templates/settings.html b/ pagure/templates/settings.html
index f5cb450..c9bc445 100644
--- a/ pagure/templates/settings.html
+++ b/ pagure/templates/settings.html
@@ -951,6 +951,7 @@ $('#new_custom_field').click(function(e) {
<select name="custom_keys_type" class="form-control"> \
<option value="text">text</option> \
<option value="boolean">boolean</option> \
+ <option value="link">link</option> \
</select> \
\
'

Mind adding this to your commits? Or do you prefer me putting it on the top of
it?

No problem I'll do that and attach another patch.

I was also wondering if there should be some validation in this case, maybe
something using validators.URL() from wtforms?

I thought about this before, but since it was just a custom field it didn't seem critical. But "we" need it to be multivalued. I know of several other projects who are thinking of coming from trac to pagure who also need to link with multiple bugzillas (downstream).

Perhaps we can open another Issue to investigate if validation is practical, etc? Your call.

I do not know if that

validator would work well for our current input since we allow multiples URLs to
be passed (one argument in favor of allowing just one URL imho).
We will also need to adjust the issue_ev.js once we're merged the PR allowing to
live refresh the values of the custom fields based on notifications from the SSE
server.

We could investigate if we can call the validator in a loop, or maybe just check its sources to see if we can re-implement it locally if needed.

I wonder if we couldn't just use a simplified version of https://github.com/kvesteri/validators/blob/master/validators/url.py instead of adding a new dependency. Or maybe just re-use the validator from wtforms since we already depend on that one.

What do you think?

@mreynolds changed the status to Closed

7 years ago

Metadata Update from @lslebodn:
- Issue tagged with: IDM

7 years ago

Login to comment on this ticket.

Metadata