Custom menu configurations and db update files

[dalers]

Given the file name syntax of a DB update files and that the db update number and db update filename is managed by the webERP project, what should the workflow be for creating, managing and updating custom menu systems? I.e. adding new modules, changing existing menu items, and follow any menu updates from the webERP project (so long as they don't conflict with customizations).

Related discussion #754 (comment)

It seems (without knowing) that the custom db update file must be numbered one higher than the existing db update files to be executed, yet at any time the webERP project could issue a dbupdate file with the same number as mine. Or should I number my db update files in some other way?

Does anyone have a system that works for them? There could be a recommended procedure in the Wiki.

[timschofield]

Hi Dale, Sorry, I meant that the DB update system should be used for changes intended to be committed back to the project.
For local changes I would just amend the menuitems table. That's what my menu editor will do.

Thanks
Tim

[dalers]

I see, that was my thinking before wondering if there was a better way...

What will happen when webERP project issues a db upgrade file with menu changes? Will they overwrite my local changes? How do I preserve my local changes but also benefit from menu updates issued from the webERP project? (e.g. better structure unrelated to my customization, corrections in required security permissions, etc.)

(edit) as a follow-on, if I was customizing webERP for a particular company (adding scripts, menu items and possibly a module, and possibly adding table colums or even a table, and possibly modifying menu item visibility), im thinking perhaps the best workflow would be to create a script similar to a db update file but saved in a different directory and executed manually. This may be the simplest way to adapt when changes are made by the webERP project. What do you think? What is your workflow in this situation?

[dalers]

Unless someone has a better procedure, it seems to me the only practical way to make custom menu changes is to use a custom update script with existing menu management functions (e.g. create an update file n+1.php). However, that will result in a conflict when the webERP project issues a new update file.

I think the following workflow will support custom update scripts. Does anyone see any issues or has a better solution?

(edit: updated drawing for clarity)

[dalers]

I submitted PR #795 for some menu cleanup, and it struck me that I was using an update not to modify the schema but only to change the configuration of some menu items, which is something many companies may likely do or want to do.

How should a company manage their "custom" menu configuration when the project makes changes? In this case (issue #795), if a company has modified their [Utilities > Maintenance ] sub-menu, it seems they will have to re-implement their changes after updating to update 32 (update 32 assuming the PR is accepted).

Anyone have any comments or recommendations? Should the update system be used only for schema changes, and "recommended" or "default" configuration managed seperately in some other way?

[timschofield]

The database update system is for changes to the database that will be distributed with webERP. If you are changing your local database that is down to you.

Tim

[dalers]

The trouble is there is no good way for me to manage my own updates while still wanting to pull from upstream. I have a couple ideas but nothing good yet.

I think it would be a huge benefit to companies considering adopting webERP if we had a process that could be followed to create customizations. We have already discussed elsewhere iirc that a plugin abstraction likely not technically possible nor is it desired. The API is available as an abstration if the effort to develop a new application is justified.

[pakricard]

How should a company manage their "custom" menu configuration when the project makes changes? In this case (issue #795), if a company has modified their [Utilities > Maintenance ] sub-menu, it seems they will have to re-implement their changes after updating to update 32 (update 32 assuming the PR is accepted).
The trouble is there is no good way for me to manage my own updates while still wanting to pull from upstream. I have a couple ideas but nothing good yet.

@dalers : I have been in that position for almost 15 years now. There is no good or easy way (at least, that I know).

As soon as you start modifying your code or your DB, you need to juggle between “standard webERP” and “my own webERP”. Depending on the number of script customizations or DB modifications, it will be more or less complicated, but the best workflow for me is to keep standard webERP and my own webERP as updated as possible. Merging every time there are new commits in standard webERP (almost daily for the last couple of years), and checking in detail every change that might affect my modified scripts or DB.

Using Beyond Compare as a Diff tool connected to SourceTree makes this straightforward.

Anyone have any comments or recommendations? Should the update system be used only for schema changes, and "recommended" or "default" configuration managed seperately in some other way?

IMO, it works OK as it is. It would be a developers' nightmare to try to satisfy everyone. I think the way it is done now, it covers most cases.

R