Adding Types to the "Add Record" Form

  • mlapl1

    mlapl1 - 2009-05-25

    Hello Everyone/Matthias

    I would like to add a couple of extra Types as defaults in the users' "Add record" Form.

    I have added them to the file and I have also added them to the "types" table - making sure that the order_by field is correct for each item in the table. I have given each a base_type_id but to be  honest I am not sure what the base_type_id does. I thought it was meant to give a weighting for each item in terms of value.

    When I create a new user the following happens:

    Not all of the new items appear. There should be 18 but only 17 show as default (the 18th is in the listbox and can be added manually - but it is not a default). Actually, I have added 2 items in addition to the 16 already there.

    Any hints would be gratefully received.

    Thank you

    • Matthias Steffens

      Hi Andrew,

      > I would like to add a couple of extra Types
      > as defaults in the users' "Add record" Form

      Which types are you missing?

      Note that while you can add new resource types to the refbase 'types' table, support for the newly added resource types must be added incode to correctly enable citation output as well as export and import functionality. This is currently not really straightforward since it requires changes at quite a few places in the code.

      W.r.t. adding new types, please see these forum threads:

      > I have given each a base_type_id but to be honest
      > I am not sure what the base_type_id does

      The 'base_type_id' is meant to provide for a fallback system for citation output, but it's not yet fully implememeted in refbase-0.9.5. The "base type" should point to one of the refbase core types that most closely resembles your new type. If no support is available for your new type in code, this base type would be used for citation output etc. Howver, as mentioned, this hasn't been fully implemented yet.

      > Not all of the new items appear. There should
      > be 18 but only 17 show as default

      Without seeing any of your code/MySQL tables, it's hard to say what's wrong.

      Feel free to post your 'types' and 'user_types' tables as well as the specification of variable '$defaultUserTypes' so that we can take a look.


      • mlapl1

        mlapl1 - 2009-05-25

        Hi Matthias

        Yes... I understand the nature of the citation problem - of course you are right.

        Having said that I will try to adapt.

        I wonder if you can shed some light on the following:

        When the "Add Record" form is displayed but no one is logged in, ALL the types (including the new ones I have added) appear in the dropdown box.

        However, when someone is logged in, only 17 of the 18 types are displayed by default (even for users added after the new types were added).

        In the case of the admin (maybe others too - I have not checked in detail) it is possible to add the 18th field by hand by editing the account options.

        Any clues?


    • Matthias Steffens

      Hi Andrew,

      Please post your 'types' and 'user_types' tables as well as the specification of variable '$defaultUserTypes'. Without that info it's hard to tell what could be wrong.

      Also, if your refbase installation is publicly available, it might be helpful if you could create a temporary account for me and send me the login info via private mail.

      In any case, you should be able to login as admin and enable the missing type for all of your users manually. The type should then be available on the individual user options pages.

      Best, Matthias

  • TLane

    TLane - 2012-07-17

    I am curious about getting control over Types. I have already updated the db table. However, I want to retain full functionality with the new types. I noticed that the 2007 forum post made mentioned the SVN version of the time had some fixes. Were these fixes dropped from before the current 0.9.5? 

    Given the clues my only option appears to be to start editing the php. Therefore, would you be so kind as to give the locations of the needed changes. I do apologize, but I do not have time to go line by line, and even if I did, I don't want the risk of missing something since it is not my baby. Any other pitfalls before I start editing would be great. Thank you very much!


  • Matthias Steffens

    Hi Thomas,

    what kind of types are you missing specifically?

    The SVN "fixes" mentioned in the previously linked thread were not dropped, they got fully incorporated into the current version (0.9.5).

    While it's relatively easy to add new types to the refbase MySQL database, enabling full functionality for these new types is a completely different story. This is by no means an easy task and requires quite a bit of work, testing and inside knowledge to get it right. To achieve full functionality, the new types must be fully supported in *all* export, import and cite functions. To give you a full list of lines to be changed, I'd need to sit down (probably for hours) and dig into this myself. And even then, sound testing would be required to ensure that no parts have been ignored. Unfortunately, I don't have this time right now, sorry.

    To find pieces of code that deal with the refbase types, you could search the code for strings like these:

    Journal Article
    Book Chapter (or any of the other type names)

    Of course, not all of the found code pieces would need to be changed. The amount of work depends on the nature of your types and on what level of support you'd like to achive.

    What would be the most important functionality, that you'd need to work with your new types?


  • TLane

    TLane - 2012-08-04

    Thank you for the information and time, and I apologize for the delay getting back. I have been letting things pile up.

    In this particular case, we are wanting “Conference Paper/Presentation” & “Conference Poster”. However, we realize our nature may require this list to expand thereby requiring the need for future customization.  

    As for functionality, the same issue exists. If a function exists in refBase and adequate treatment of custom dated is not possible, we prefer to be aware and prepared for this prior to inserting custom data. However, to answer your question, there is no particular king of the hill, but I assume exporting, reports, and citing are of most concern to us.

    Regarding the changes required, we were afraid the rabbit hole would be this steep and will  not attempt to go down it. Otherwise, refBase is a solid solution. At the present time we are weighing our flexibility requirements against its available solutions. If it is of interest, I can return to tell our final solution. Either way, you have been most kind, or we thank you!



Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks