Content Management Functionality

[dalers]

PR #980 (originally) included changing the link text for the existing wiki integration in SelectProduct.php which initiated a discussion in the PR comments on how to best provide content management functionality in webERP in general.

That discussion has been moved here to allow the PR discussion to focus on the PR itself.

@dalers said:

I anticipate replacing (link text) "Wiki Product Knowledge Base" with "Documents, Drawings and Files" may invoke discussion.

For my users, "Notes" are in webERP and are used to share information between users while the wiki interface ("Documents, Drawings and Files") is used for controlled files (e.g. PDFs, ZIPs, Word Docs, Spreadsheets, etc.). Imho this creates a clean separation of function (made possible by the recent addition of Item Notes) and is simple for users to understand. The Wiki provides a simple document management system when an approval workflow isn't necessary but still provides traceability to the user that provided the file with a timestamp.

However, perhaps not everyone will want to name the Wiki interface "Documents, Drawings and Files", and configuring the link text in [ Settings > System > Wiki Interface ] may be preferable.

@pakricard said:

... agree with the configurable text, as for some users "drawings" makes no-sense, but "Extra information" would make more sense to the users.

@timschofield said:

is a link to a wiki the best way to store this info? Phil is a big fan of Wikis and I understand this, but is it not better just to have a means of storing assorted files such as PDFs or MDs?

[dalers]

Many if not all of the ERP systems I have used have included some level of "attachments" functionality and something similar could certainly be added to webERP.

However, given the wiki integration feature has been in webERP for many years and its benefit has been extolled by at least one active user of the feature (@efeoli iirc), my preference is to keep the wiki integration and not invest the effort to develop our own "attachments" system. I would only propose to make the wiki link text used in webERP configurable so that a company can use the wording that best fits their use (which in my case is "Documents, Drawings and Files").

[timschofield]

We actually have attachments already with the stock images. I did once write a system to attach PDF specifications to a BOM. Attachments and a wiki don't have to be mutually exclusive.

[dalers]

We actually have attachments already with the stock images.

True, but much of the functionality desirable even in a basic EDMS would still have to be implemented.

Attachments and a wiki don't have to be mutually exclusive.

True but providing more ways to do the same thing doesn't necessaraily make life easier for users.

What are you proposing TIm? Are you saying that, although the existing wiki integration could be used to store documents, you would prefer it not be used for that purpose and instead create new EDMS functionality to use instead?

For me, the existing WackoWiki integration provides the necessary functionality without any effort to design, code, verify, validate and maintain equivalent functionality in webERP and see no need to re-invent the wheel at ths time.

[timschofield]

What are you proposing TIm?

I don't think I am proposing anything. The wiki links came up in discussion and I said I think there is a better way of doing it, which I believe there is. Just adding a comment to a discussion.

[dalers]

Iiuc, Tim, you implied (or at least I got the impression that you had implied... ;-)) that a better and preferred way of storing documents such as PDFs or MDs would be to duplicate the stock images pattern from Stocks.php and support uploading a general file to the system and referencing it from an Item. Something like that?

To simplify requirements, the files could be stored in the same directory (different from the stock items picture directory) using their original filenames. If a user attempts to upload a file with an existing name, it is their responsibility to investigate and rename their file if necessary.

There would likely need to be a maintanence script to:

• list where a file is used (i.e. linked from)
• delete a file (which could require deleting all links to the file first).
• change links on a page or all pages from file "A" to file "B"
• replace a file with a corrected file (intended content stays the same)

Coding the basics might not be that hard and I would certainly expect the result to be no worse than some propriety software I've used. Someone passionate could probably bash out an "80%" solution in a long weekend! ;-)

However, if the basics aren't enough and the system needs to be more of a real file/document management system, requirements move closer first to existing wiki software e.g. WackoWiki. What is the payback for you? To me, the payback is a) system/server simplification from not having to install a wiki, and b) branding. I don't see the simplification is enough to justify the development effort, given the user must have some level of expertise or they couldn't have installed webERP in the first place.

Strictly from a level-of-effort perspective, if anything more than the most basic features are needed, I suggest the best solution would be to partner with an existing project. If only traceabilty and basic control is needed, then WackoWiki. However, if an arbitrarily approval workflow is needed, then SeedDMS (another php project similar in a vein to WackoWiki and webERP).

Fwiw, I got the impression that WackoWiki thinks its' an embedded wiki-engine as much if not more than it's a stand-alone wiki. Embedding WackoWiki in webERP (making it a sub-project) is another option but in my mind, the first step would be to wire-frame or at least bullet-point the new UI.

[timschofield]

If I were to make a proposal, it would be to add an additional option in the 'Wiki application' drop down for uploading files directly (can't think of the exact wording). This way existing wiki users could carry on as they currently do, but users get the option of a better system.

Tim

[dalers]

add an additional option in the 'Wiki application' drop down for uploading files directly

That seems reasonable. Eventually I would want to also add 'SeedDMS' to the drop down when implementing an ad hoc workflow is required (unless you've added it to webERP by then).

I don't want to infer too much but it seems if a system was configured to "upload directly", then the "Wiki Knowledge Base" link would open the files management script (e.g. Files.php) to show the files "attached" to a selected stock item (or customer or supplier) and let users open or download a file or add a new file. If called directly, Files.php could provide a generalized view of the files in the system including file names, who uploaded the file and when, what the files are linked to and the other functions I listed earlier for a maintenance script,

That might be enough to not need an external Wiki for strictly basic EDM so long as Wiki pages aren't useful for giving context for a file or for other purposes - such as a QSM.

Btw, I forgot to include not having to login to a seperate app to the payback list for including EDM functionality in webERP.

1. System/server simplification from not having to install a wiki.
2. User simplification from not having to login seperately to create/edit pages.
3. Increased WebERP value because of increased built-in functionality (I originally called this "branding" meaning the value of the webERP brand but a poor word choice).