[pmwiki-users] possible fix for wikiform issue

Asociacion de Robotica emarte at aiolosrd.com
Tue Oct 16 13:08:36 CDT 2007


Hi Jhon, thanks for replying so soon,

I did no expect that many questions from you (didn't see tem coming) so I
will give you some answers, more to come later one.

>1. Am I correct that -nnnnn is unique? That is, we can't have both 
>  Issues.Pname1-00001 and Issues.Pname2-00001. It's nicer if we can
>  use the existing "work out the next number to use" code. Or is it
>  the combination of {$name} and number that is unique?


In the Scheme I am thinking about Issues.Pname1-00001 and
Issues.Pname2-00001 can both co-exist. Issues.Pname1-00001 and
Issues.Pname1-00002 would be issues 1 and 2 for project 1 and
Issues.Pname2-00001 and Issues.Pname2-00002 would be issues 1 and 2 for
project 2. The Combination and number make them unique.


>2. Does it have to be Issues.P{$name}-00001 or could it be 
>   Issues.00001-P{$name}? I expect we could implement either scheme, but if
>   the latter is easier to code, is that acceptable?

In my case it would be no problem either case. What I am not yet 100%
pleased about is the fact of the creation of so many groups as I mentioned
before.


>7. What for you is the main benefit of including a prefix in the page name?
>   Specifically, why not use Issues.00001 and have {$name} as a field on
>   the issues form?

About this one below is what you wrote a year ago:

>Let's take Issue as an example, from which we can generalise to other
>project attributes. As I understand your data model, there is a one 
>to many relationship between a project and its Issues.
>So you have 2 options:

>a) the option above, where you make the project identifier part of
>   the group name and have separate Issue groups for each project;
>   thus P00001-Issue.00003 is issue 3 for project 1

>b) have a Project group and a single Issue group, and make the
>   project number an attribute of the issue; thus Issue.00001
>   may have an attribute Project.00002 and Issue.00002 may have
>   an attribute Project.00005

>I think option b is harder to maintain, because you have to
>know the project number whenever you create a new Issue.
>With option a, you navigate from (say) Project.00007 to
>P00007-Issues.NewIssue, so the next issue is automatically
>associated with the correct project.

In Another Post:

>I think the question you are asking is: "how do I create a new 
>issue or activity for the current project?"
>
>To do this, there are 2 options:
>
>- put "new issue" and "new activity" forms on each project page
>
>- provide a link on each project page to a suitable NewIssue and
>  NewActivity page
>

Then Far Below...

>(:wikiform project='value in the url from the project page':)
>
>Even if you could, we'd have to take care of the case where
>you get to the NewIssue page from somewhere else and don't
>know the project number.

I tried Option A and it works, it is just the matter of too many groups as
Projects grows. Option B, I thought about it and you were right, it is
harder to maintain and special care has to be taken whn somebody comes from
another page. So I came with using a prefix as you mentioned before.

Imagine the following escenario:

* A manufacturing company working with ISO-9000 model and managing all
documentation of all departaments and Intranet with wikiforms.

* So we have Departaments lets'say Engineering, Purchasing, Sales,
Production, Marketting , etc.

* Every Deapartament has their own documentation they share through the
intranet managed by wikiforms and some security and versioning policy.

So let's Say form Purchasing we have lets say the following:

Purchasing: Quotations, Envoices, Issues ,  ToDo List, etc
Sales: Quatations, Credit, Issues, Todo List, etc
Engineering: Projects, Issues, Tasks, Design, Test, etc
Stock Managament: Locations, Receiving Materials, etc

And Etc....

So in the big Picture we could have Eng-Issues.00001-P00001 (Issue 1 for
Project 0001 of Engineering).

Pur-PO.00007-P00005 (PO 7 (purchasing) for  for Project or product 0005 of
Purchasing).

It depends of how the people decide to manage the system. At the moment I am
working in and stock/location management and documentation system for our
business. I worked in a manafacturing company before and I believe this
could be easily implemented that way.

Do not get me wrong, we could do it with option B perfectly, what worries me
is the amount of group and folders created in the system.


So back to your questions we could manage a whole big system just with a few
groups, proportional to the departments.

Eng-Issues
Eng-Tasks
Purc-Issues
Purc-Tasks

I hope you can understand my point and sorry for any missleading english. :)

Regards,
Edwin Marte




More information about the pmwiki-users mailing list