Bug 14049 - Ability to add custom fields to OPAC purchase suggestion form
Summary: Ability to add custom fields to OPAC purchase suggestion form
Status: RESOLVED DUPLICATE of bug 21329
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-22 16:17 UTC by Pablo AB
Modified: 2019-06-02 15:34 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pablo AB 2015-04-22 16:17:37 UTC
Before using Koha we were using a local develop for purchase suggestion requests («desiderata»). Now I'm trying to extend/add suggestion fields to add some data we were asking in the form and Koha doesn't include, something like what ExtendedPatronAttributes syspref does with patron fields.
First I naively tried to add to opac-suggestions.tt
  <li><label for="newField">Extrafield:</label><input type="text" id="newfield" name="newfield" maxlength="40" /></li>

and  on submit:
  onsubmit="this.note.value=this.note.value+' - '+this.newfield.value; return true;"

to concatenate extended fields (yeah, dirty) but it seems Suggestions.pm do a foreach walk over form ids: 
Software error: DBIx::Class::ResultSet::create(): No such column alum on Koha::Schema::Result::Suggestion at /usr/share/koha/lib/C4/Suggestions.pm line 450

Koha should let staff user to extend suggestions fields, maybe with a ExtendedSuggestionFields sysfref.
Comment 1 Katrin Fischer 2019-06-02 08:35:50 UTC

*** This bug has been marked as a duplicate of bug 21329 ***
Comment 2 Pablo AB 2019-06-02 15:26:49 UTC
Shouldn't always newer bugs marked duplicated of older ones, instead of the other way around? At least unless the newer have much more info.

Marking older bugs duplicate of newer ones give the wrong impression that this request is recent.
Comment 3 Katrin Fischer 2019-06-02 15:34:56 UTC
(In reply to Pablo AB from comment #2)
> Shouldn't always newer bugs marked duplicated of older ones, instead of the
> other way around? At least unless the newer have much more info.
> 
> Marking older bugs duplicate of newer ones give the wrong impression that
> this request is recent.

You are right Pablo that this is the general rule. Tbh, I was not sure if this was active and picked the other for the recent activity on it. It sure is debatable.