Delete some Z_ scripts #281
Replies: 11 comments 3 replies
-
|
Hi @pakricard Do menu items exist for any of these scripts? Presumably all were created to solve some problem, but perhaps the problems were unique situations and possibly even only temporary. How about moving them into docs/scripts with a README saying they are for guidance only, not likely to run without changes, and should not be run on a live database without testing on a test database first. Moving the scripts would cleanup the main directory and someone could still benefit (and then delete entirely in another year if truly have no value). |
Beta Was this translation helpful? Give feedback.
-
|
Most of them do have a menu entry (at least in v 4.15.2). We seldomly use:
I am not sure why the name starts with "Z_" Being safe scripts we could probably use standard script names. All Z_Import files are most likely obsolete. I would not use them in my webERP without a meticulous check as can lead to inconsistencies, |
Beta Was this translation helpful? Give feedback.
-
Can anyone suggest a general way (i.e. bash script?) to determine exactly a) which php files have menu items, and b) which files are not included in or executed from other php files? I'm guessing all the files listed in PageSecurity.php would likely have assigned menu items, but I suspect there's nothing in place to require it (there could be files listed in PageSecurity.php that aren't in the menu, and there could maybe be php files in the menu that are not listed). @timschofield is this possible? |
Beta Was this translation helpful? Give feedback.
-
|
I think most of them can go. Many of them were done as a fix for problems
users were having - for instance at one time we were constantly asking
people to run Z_RePostGLFromPeriod.php when their TB went out of balance.
This is now redundant as I cured the underlying problem. Z_DeleteInvoice
and Z_DeleteCreditNote come from a time when users kept asking for this
functionality, and Phil and I were constantly saying it was bad accounting
practice. In the end somebody wrote them (not me) and they were given the
caveat that we don't support them.
A few of them are useful (such as uploading initial transactions).
People would be more likely to maintain these scripts if there were fewer
of them, so I would definitely encourage heavily pruning them. Maybe a
start would be to remove the utilities module altogether? The scripts would
still be available but users would either have to be directed there, or
know to look.
Dose anyone have any particular favourites they would like to keep?
…On Fri, 6 Dec 2024 at 23:25, Dale Scott ***@***.***> wrote:
*Most* of them do have a menu entry (at least in v 4.15.2).
Can anyone suggest a general way (i.e. bash script?) to determine a) which
php files have menu items, and b) which files are not included in or
executed from other php files?
I'm guessing all the files listed in PageSecurity.php would likely have
assigned menu items, but I suspect there's nothing in place to require it
(there could be files listed in PageSecurity.php that aren't in the menu,
and there could maybe be php files in the menu that are not listed).
@timschofield <https://github.com/timschofield> is this possible?
—
Reply to this email directly, view it on GitHub
<#281 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAL6LFSARYUMVGXGOA2BQD2EIW5JAVCNFSM6AAAAABTD3BFGKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNBZGA3TIMI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
My vote is to keep the Utilities menu, as it can be easily enabled/disabled via WWW_Users.php). Some of the scripts are "admin only" or seldomly used but practical, like the Z_Change* ones. Furthermore, deleting dangerous scripts should be a priority as their usage is not worth the risk. IMO, these will not be missed:
|
Beta Was this translation helpful? Give feedback.
-
|
Hi Ricard, my two pennorth below:
I am ambivalent about this one.
On Mon, 9 Dec 2024 at 02:00, pakricard ***@***.***> wrote:
My vote is to keep the Utilities menu, as it can be easily enables/disabled via WWW_Users.php). Some of the scripts are "admin only" or seldomly used but practical, like the Z_Change* ones.
The use of the utilities is relatively recent - I have a feeling I did
it originally. Before then the Z_ scripts existed, but users were
guided to them from the mailing lists.
The Z_Change scripts I can live with, but the accountant in me is
always nervous about such things.
Furthermore, deleting dangerous scripts should be a priority as their usage is not worth the risk. IMO, these will not be missed:
Z_DeleteInvoice
Z_DeleteCreditNote
Agreed with these 2, however they were introduced because users kept
asking for them. Basically it was a case of "QuickBooks lets you do it
why doesn't webERP?" I wouldn't have done them personally but they are
there.
Z_CreateCompany.php
I think this script, if implemented right is a good one. Imagine for
instance someone installs the demo data, plays around with it and
eventually decides to install it for their organisation. It would be
much neater for them to be able to create a new blank company for
production purposes, but keeping the demo for practising/training. I
know this can be done manually but it's so much nicer using the
script. Having said that the script needs work.
Z_CreateCompanyTemplateFile.php
I think this is obsoleted by the one above
Z_CurrencyDebtorsBalances.php
Z_CurrencySuppliersBalances.php
These two don't update anything, though I don't really see their
point. Why have you classed them as "dangerous"?
Z_DataExport.php
I think I agree here as well. Unless a developer is prepared to
regularly maintain this script it rapidly breaks. Someone who knows
what they are doing can easily export the DB if they know what they
are doing.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
Thanks
Tim
…--
www.weberp.org
@TimSchofield2
Blog: https://kwamoja.home.blog/
|
Beta Was this translation helpful? Give feedback.
-
|
I have created a wiki page -
https://github.com/timschofield/webERP/wiki/Utilities - where people
can put comments against scripts the pafrticularly want to
keep/scratch
…On Mon, 9 Dec 2024 at 11:54, Tim Schofield ***@***.***> wrote:
Hi Ricard, my two pennorth below:
I am ambivalent about this one.
On Mon, 9 Dec 2024 at 02:00, pakricard ***@***.***> wrote:
>
> My vote is to keep the Utilities menu, as it can be easily enables/disabled via WWW_Users.php). Some of the scripts are "admin only" or seldomly used but practical, like the Z_Change* ones.
The use of the utilities is relatively recent - I have a feeling I did
it originally. Before then the Z_ scripts existed, but users were
guided to them from the mailing lists.
The Z_Change scripts I can live with, but the accountant in me is
always nervous about such things.
>
> Furthermore, deleting dangerous scripts should be a priority as their usage is not worth the risk. IMO, these will not be missed:
>
> Z_DeleteInvoice
> Z_DeleteCreditNote
Agreed with these 2, however they were introduced because users kept
asking for them. Basically it was a case of "QuickBooks lets you do it
why doesn't webERP?" I wouldn't have done them personally but they are
there.
> Z_CreateCompany.php
I think this script, if implemented right is a good one. Imagine for
instance someone installs the demo data, plays around with it and
eventually decides to install it for their organisation. It would be
much neater for them to be able to create a new blank company for
production purposes, but keeping the demo for practising/training. I
know this can be done manually but it's so much nicer using the
script. Having said that the script needs work.
> Z_CreateCompanyTemplateFile.php
I think this is obsoleted by the one above
> Z_CurrencyDebtorsBalances.php
> Z_CurrencySuppliersBalances.php
These two don't update anything, though I don't really see their
point. Why have you classed them as "dangerous"?
> Z_DataExport.php
I think I agree here as well. Unless a developer is prepared to
regularly maintain this script it rapidly breaks. Someone who knows
what they are doing can easily export the DB if they know what they
are doing.
>
> —
> Reply to this email directly, view it on GitHub, or unsubscribe.
> You are receiving this because you were mentioned.Message ID: ***@***.***>
Thanks
Tim
--
www.weberp.org
@TimSchofield2
Blog: https://kwamoja.home.blog/
--
www.weberp.org
@TimSchofield2
Blog: https://kwamoja.home.blog/
|
Beta Was this translation helpful? Give feedback.
-
|
Hi @timschofield : Z_CurrencyDebtorsBalances.php and Z_CurrencySuppliersBalances.php are safe to run (confusing long sentence). Just I don't think they belong to Utilities. If they are useful to someone, they should be somewhere in Receivables or Payables menu.
Z_Change are mainly used against undetected typos in codes, or when standard coding changes, not on regular basis. All the Z_Update used to change DB versions are very old. Maybe someone is still using v 3.01 and wants to upgrade to v5 but... I really doubt it. Some old versions need to be discontinued at one point. To me, this is an exercise of mental sanity. The less old, unused, potentially dangerous scripts we have to maintain, the better. In fact, in my install I deleted almost all of them. |
Beta Was this translation helpful? Give feedback.
-
|
It seems there are a number of categories of "Z" scripts:
If the scripts can be suitably categorized, we could decide on an appropriate action for each category. For example, we could decide:
I would generalize @pakricard recommendation as:
Any thoughts for how to progress from discussion to action? Fwiw, a couple additional related thoughts (although they infringe on the general directory structure discussion in Redefining the directory structure (??) #189:
|
Beta Was this translation helpful? Give feedback.
-
|
Hi Dale,
On Tue, 17 Dec 2024 at 07:05, Dale Scott ***@***.***> wrote:
I would generalize @pakricard recommendation as:
The less ... scripts we have to maintain, the better.
Agreed, I think most developers (including me) forget to ask
themselves "Does this impact on a Z_ script?" meaning they quickly get
outdated.
Any thoughts for how to progress from discussion to action?
Fwiw, a couple additional related thoughts (although they infringe on the general directory structure discussion in Redefining the directory structure (??) #189:
I think the flat directory structure is actually a *featiure* of
webERP. It has been like it from day 1, and I wouldn't want to play
with that. The Z_ prefix was devised to group utility scripts together
in one place without the need for a separate directory.
scripts that do not have a menu entry but are invoked from a script that does are in the includes/ directory
Agree that scripts that are only included from others should be in the
includes/ directory. Do you have any in mind that aren't? However some
scripts are actually invoked from other scripts (from
SelectProduct.php, SelectCustomer.php, SelectSupplier.php for
instance) and these should remain in the main directory.
AddCustomerNotes.php and AddCustomerTypeNotes.php spring to mind as
examples of this.
"non-Z_" scripts that do not have menu entries or are not invoked from scripts with menu entries are renamed adding "Z_" prefix (e.g. rename LoggedInUsers.php to Z_LoggedInUsers.php)
LoggedInUsers.php does have a menu item for it and we are trying to
cut down on the Z_ scripts so I am not sure why we would add to them
unnecessarily.
provide a directory reserved for users to add their own scripts ("custom" scripts) to simplify maintenance of a site with custom scripts by not mixing them with "core" scripts.
In my experience most customisations are adaptations of existing
scripts rather than new scripts. Obviously we can't control where
users put custom scripts but I would encourage them to keep their
scripts in the main directory.
Thanks
Tim
…
|
Beta Was this translation helpful? Give feedback.
-
Agree, it's a feature of webERP that it is as close to bare metal (a businesses financial position) as you can get. Only enough structure to improve clarity and avoid absolute chaos...
Agree there is convenience. It seems "Z_" means Utilities if all scripts have a menu item. Is that right? Why not carry the strategy further and name all scripts with the prefix of their primary module (SA_ = Sales, MF_ = Manufacturing, PY_ = Payables, PC_ = Petty Cash...)?
Don't know if there actually are any but it's good to have a rule to apply if any are found. I've been noodling on how to run a report to find out whether all the files in the webroot do have menu entries and which scripts invoke scripts in includes/. I.e. something that would report deterministically, that can't be argued with, that can be run until it shows everying is "fixed" and could be run periodically to show fixed things are still fixed. Any ideas? I seem to recall NetBeans can analyze a PHP project and create a call tree / graph...
(e.g. AddCustomerNotes.php and AddCustomerTypeNotes.php are invoked from SelectProduct.php, SelectCustomer.php and SelectSupplier.php, iiuc) What is a rule we could decide on for files in the main directory? Can a rule be made for when exceptions are allowed?
Sorry, didn't realize it had a menu item. Ahh, you put it in Setup, I had expected Utilities.
Perhaps recommending a XX_ prefix? |
Beta Was this translation helpful? Give feedback.
-
|
Hi Dale,
On Tue, 17 Dec 2024 at 18:47, Dale Scott ***@***.***> wrote:
Why not carry the strategy further and name all scripts with the prefix of their primary module (SA_ = Sales, MF_ = Manufacturing, PY_ = Payables, PC_ = Petty Cash...)?
Some of them already are - PC and GL for instance. We should probably
have done it from the start, though with some scripts the line is
blurred - AP and Purchasing, or AR and Sales. I'm not sure we should
do a mass change like that now though.
LoggedInUsers.php does have a menu item
Sorry, didn't realize it had a menu item. Ahh, you put it in Setup, I had expected Utilities.
The setup module is misnamed really. It started out being for
parameter setup. It grew over the years to include anything used in
the admin of the project - which is what LoggedInUsers.php is.
Utilities is for scripts that should only be used by an expert, and
could well do damage if used incorrectly.
Tim
…--
www.weberp.org
@TimSchofield2
Blog: https://kwamoja.home.blog/
|
Beta Was this translation helpful? Give feedback.
-
|
My 2 cents:
I don't see an issue with that. I am not sure if a tree-like script structure helps us in any significant way.
100% agree
I have both. When a small change is needed, it is easier to keep the standard webERP script and do some mods here and there, while when a new functionality is needed, new scripts are coded and kept in the main directory. To locate them easily, I added a prefix “KL” as KLScriptName.php. Good enough for me.
That was my point when I started the discussion. If a script could “do damage”, it should be fixed or deleted. My vote is for deletion. IMO: the current code is still not PHP8 ready, has several bugs and we are a small team. I think that we should focus on getting what we have now working properly and, at a later stage, apply all improvements we might think of. Should we go (for now) for an "if it works, don't touch it" approach until v5? |
Beta Was this translation helpful? Give feedback.
-
|
On Tue, 17 Dec 2024 at 23:41, pakricard ***@***.***> wrote:
Should we go (for now) for an "if it works, don't touch it" approach until v5?
—
Agreed
…--
www.weberp.org
@TimSchofield2
Blog: https://kwamoja.home.blog/
|
Beta Was this translation helpful? Give feedback.
-
Hi all:
Some Z_ scripts are quite dangerous, and even some have the comment "STRONGLY RECOMMEND NOT USING THIS "
e.g.: Z_DeleteInvoice.php, Z_DeleteCreditNote.php
Some are most probably obsolete and inconsistent with current DB as the last substantial commit was done long ago (strong indicator no one is using them).
Should we get rid of these scripts because some are dangerous or most probably inconsistent for more than 10 years?
Beta Was this translation helpful? Give feedback.
All reactions