Hello Thanks, we should always attempt to make our job easy and if something is happening along with community standards than its fine. But always it's not applicable and we go with local customisation. Main thing is our data which must not be affected because GUI is not an issue, if your database is fine than simply install new version and restore it. As far as plugins are concerned that also need to be updated if something changed in the future. DSpace is an example which is customized locally at files level and after update you need to check the things, there are no DSpace community who bother about your customized codes as i understand it. It will be really very nice if some standard plugin can be made where each library can define there own fields else i feel there is no other option than local customisation by experts. I learn if a separate table is created it will never be affected even after update and new columns will have also no any impact unless table itself not changed, this can be clarified by Dr Saiful. Thanks a lot for sharing ideas. On Thu, 8 Sep, 2022, 17:44 Shamprasad Pujar, wrote:

Dear All,

Greetings!

I completely agree with Dr. Saiful that changes to the original code base of Koha will create a problem in Koha updates and should be avoided. It is always good to work around keeping the original code intact. I appreciate the efforts of Mr. Vinod, but it should be in tandem with the development of Koha's upgrades so that his work is acknowledged by developers/others.

Regards,

S M Pujar Chief Librarian IGIDR, Mumbai ==============

On Thu, Sep 8, 2022 at 9:56 AM Dr. Saiful Amin wrote:

...

Greetings,

The process described in the link suggests exactly the things that one must avoid while customizing any software.

There are several issues with this approach:

1. Altering database schema is a sacrilege and must be avoided. Future upgrades will probably destroy all the database changes and the accumulated data. It can even prevent applying updates in the future.

2. Changing application code (*.pm|pl) is another thing to avoid for the same reasons as above. However, it is possible to keep a record of the changes in a patch file and applied to the code after every upgrade. But if a future software update changed the same file, then the patch needs to be updated as well. As one can understand that it is not trivial and very time-consuming. Hence, this approach is suitable only for very minor changes of a few lines.

3. Template file (*.tt) changes are another area that has a high chance of breaking after the upgrade. Same suggestions as the point 2 applies here.

4. The "*.3pm" files do not need to be changed at all. These are documentation/manual generated automatically from the code. The effort to change these files is redundant.

I understand that there might be a pressing need to make such changes for local requirements or compliances. Calculate the cost/effort of maintaining a separate code-base and backup of the altered database and syncing it after every update. Make sure that the cost/effort is worth it.

There are two approaches that I can suggest in such a scenario:

1. The recommended process is to submit these changes as patches to the Koha Community Bug Tracker system. Speak to the developers in the forums to get it approved to be made a part of the core software. It however takes time since the developers need to prioritize critical changes over general improvement ones.

2. Write a Koha Plugin which de-couples the code from core Koha software and can be maintained separately. It is less likely to break during the upgrades.

Best regards, Saiful Amin Semantic Consulting Services Pvt. Ltd. Bangalore

On Tue, Sep 6, 2022 at 10:14 AM vinod mishra wrote:

...

Dear all Wish you all a very happy teachers' day! It's my pleasure to share one of my desire and requirement of many libraries to customize the Koha ILMS online purchase suggestion form is fulfilled today. I could able to customize the same and the entire process is shared with the community on auspicious Teacher's Day. Hope this will be utilized by many libraries to make their library purchase suggestion online. Your feedback is highly appreciated and some more development is underway.

http://itshelp.co.in/2022/09/customization-of-koha-online-purchase-suggestio...

...

...

I strongly feel that the update process is sacrosanct (more so for a system like Koha, which provides frequent updates) and we must not disturb it. Database operations are like surgery, especially in a live system. Disasters are waiting to happen, even with a small misstep. Hence, they should always be the last resort. Altering the database schema in a live system is a dangerous idea. You can, however, create your own table without disturbing the updates. Although I would prefer doing so in a separate database altogether as per industry best practices. I am sure most are aware that, unlike DSpace, Koha allows customization of both UI and other functionalities without touching the underlying code. For example: 1. You can inject custom JavaScript/jQuery into both staff and OPAC interfaces (OPACUserJS and IntranetUserJS). You have many examples on this page: https://wiki.koha-community.org/wiki/JQuery_Library 2. UI customizations are possible using the parameters OPACUserCSS and IntranetUserCSS. The combination of custom JS/jQuery and custom CSS can be very potent. 3. The Reports module allows JSON export. With JSON reports and custom JS/jQuery you can build powerful tools. 4. Authorized values allow you to create a controlled list of terms, which are useful in many modules. 5. There are HTTP APIs available to interface with Koha from your custom code or custom JS/jQuery. 6. HTML customizations (under Tools) allow you to modify various sections of the OPAC interface. None of the above methods requires any code change. Koha saves these customizations in the database, not in the file system. The database backup will include all those customizations (no need for a separate backup). We should exhaust all options listed above before thinking of a custom Koha plugin or a separate application. Best regards, Saiful Amin Semantic Consulting Services Pvt. Ltd. Bangalore On Thu, Sep 8, 2022 at 5:44 PM vinod mishra wrote:

Hello

Thanks and what I learned from this email is confirmation of my doubt that point number 4 ( The "*.3pm") is not required to be changed. The rest of the things are known to me and really it is not recommended for novices. Your suggestion of two approaches is possible but again it's very difficult practically because there is much variation in book Indent form of libraries.

Such changes are only recommended if someone is dedicated to working on these types of works in a library.

With Regards,

Vinod Kumar Mishra, Assistant Librarian, Biju Patnaik Central Library (BPCL), NIT Rourkela, Sundergadh-769008, Odisha, India. Mob:91+9439420860 URL: http://vinod.itshelp.co.in/ ORCID ID: http://orcid.org/0000-0003-4666-7874 Scopus ID: 57223138343

*"Spiritual relationship is far more precious than physical. Physical relationship divorced from spiritual is body without soul" -- Mahatma Gandhi*

On Thu, Sep 8, 2022 at 9:56 AM Dr. Saiful Amin wrote:

...

Greetings,

The process described in the link suggests exactly the things that one must avoid while customizing any software.

There are several issues with this approach:

1. Altering database schema is a sacrilege and must be avoided. Future upgrades will probably destroy all the database changes and the accumulated data. It can even prevent applying updates in the future.

2. Changing application code (*.pm|pl) is another thing to avoid for the same reasons as above. However, it is possible to keep a record of the changes in a patch file and applied to the code after every upgrade. But if a future software update changed the same file, then the patch needs to be updated as well. As one can understand that it is not trivial and very time-consuming. Hence, this approach is suitable only for very minor changes of a few lines.

3. Template file (*.tt) changes are another area that has a high chance of breaking after the upgrade. Same suggestions as the point 2 applies here.

4. The "*.3pm" files do not need to be changed at all. These are documentation/manual generated automatically from the code. The effort to change these files is redundant.

I understand that there might be a pressing need to make such changes for local requirements or compliances. Calculate the cost/effort of maintaining a separate code-base and backup of the altered database and syncing it after every update. Make sure that the cost/effort is worth it.

There are two approaches that I can suggest in such a scenario:

1. The recommended process is to submit these changes as patches to the Koha Community Bug Tracker system. Speak to the developers in the forums to get it approved to be made a part of the core software. It however takes time since the developers need to prioritize critical changes over general improvement ones.

2. Write a Koha Plugin which de-couples the code from core Koha software and can be maintained separately. It is less likely to break during the upgrades.

Best regards, Saiful Amin Semantic Consulting Services Pvt. Ltd. Bangalore

On Tue, Sep 6, 2022 at 10:14 AM vinod mishra wrote:

...

Dear all Wish you all a very happy teachers' day! It's my pleasure to share one of my desire and requirement of many libraries to customize the Koha ILMS online purchase suggestion form is fulfilled today. I could able to customize the same and the entire process is shared with the community on auspicious Teacher's Day. Hope this will be utilized by many libraries to make their library purchase suggestion online. Your feedback is highly appreciated and some more development is underway.