Not logged in. · Lost password · Register
Forum: General Help and Support Plugins RSS
Malworking of auto-increment of bureaucracy/structured-data
Avatar
virk #1
Member since Aug 2008 · 608 posts · Location: Aachen, Germany
Group memberships: Members
Show profile · Link to this post
Subject: Malworking of auto-increment of bureaucracy/structured-data
We are running dokukwiki (Greebo) on our own computer here (Macmini Sierra) We use "structured data plugin" and "bureaucracy-plugin" for accounting purposes. We make use of the following:

++++
Rechnung eintragen|<form>
action template wiki:templates:factuur_uit_tpl "projekte:6300:buchhaltung:facturen_uit::@@documentnr@@"

number "documentnr"
number "Factuurnr" ++ 0000000
date "date"
number "project"
textbox "debiteur" !
textbox "omschrijving" !
textbox "bedrag-ex-btw-uit" !
textbox "btw-uit" !
textbox "bedrag-inc-btw-uit" !
date "betaaldatum" !
hidden "type" ="facturen_uit"
textbox "link" !
submit "Create Factuur uit"

</form>++++

Line "number "Factuurnr" ++ 0000000" provides us with an autoincremented invoice-number each time we submit.

Now/recently a problem has occurred: One user sees on his browser "2018049" as next number while  two others see "2018048" as next number, while "2018048" has already been used. This behaviour has already created double invoice numbers, which needs to be avoided.

1) As far as I remember this has never happened the years before but appeared two times within the last weeks. Can this be related to a bug of one of the plugins?
2) Has anybody of you got some similar experience?
3) Where is this number "2018048" stored within dokuwiki? Is this value cached somehow? Can I edit this value?
4) Can anybody come up with a solution or a workaround?
5) Is it okay to work from different computers with the above template/action or am I misusing it and it is only allowed to make use of it from one and (always) the same computer?
This post was edited on 2018-12-18, 10:52 by virk.
Avatar
Michaelsy #2
Member since Jun 2015 · 922 posts · Location: Düsseldorf, Germany
Group memberships: Members
Show profile · Link to this post
This is likely a problem of the concurrency of two processes. In this case, the processes are that two or more users (more or less) simultaneously create an invoice: https://en.wikipedia.org/wiki/Concurrency_(computer_science)

As far as I remember this has never happened the years before but appeared two times within the last weeks.

Probably you were just lucky. Have any changes been made in the organization? If there is no parallel access to the invoice number, then there is no problem.

A very simple workaround could be that every employee who writes invoices claims its own invoice number range. He can then manage this area independently (e.g. handwritten).

Another relatively easy option would be to synchronize the invoice number assignment via a manually-managed DokuWiki page. These are already protected against parallel access.
By Patreon.com a few eurons can be fed into the code phasers of
the DokuWiki engine. Besides, Andi's posts are worth reading.
This post was edited on 2018-12-18, 11:43 by Michaelsy.
Avatar
virk #3
Member since Aug 2008 · 608 posts · Location: Aachen, Germany
Group memberships: Members
Show profile · Link to this post
Quote by Michaelsy:
Probably you were just lucky. Have any changes been made in the organization? If there is no parallel access to the invoice number, then there is no problem.
Yes, changes have been made; but none of them I consider to be responsible for that.

Quote by Michaelsy:
A very simple workaround could be that every employee who writes invoices claims its own invoice number range. He can then manage this area independently (e.g. handwritten).
That is what we just want to avoid. Tax authorities have got some difficulties with missing invoice numbers, etc. And the last years this worked perfectly :-)

Quote by Michaelsy:
Another relatively easy option would be to synchronize the invoice number assignment via a manually-managed DokuWiki page. These are already protected against parallel access.
This is something I perhaps will think about; currently each invoice is noted on an individual page of which the data name is a 5-digit-auto-increment number from the numbering plugin :-) I could change it in a way that the page will be named after "2018048" f.e.. By this I could guarantee that no double numbering can occur. But up to now I cannot oversee the possible consequences; I could correct the mistake today, reported the procedure in our wiki and still hope to get some information, how this could have happened at all.

While I am thinking about this I have the following assumption:
- Computer A opens the wiki page, where he can create invoices by clicking this "submit"-button. The invoice number is shown as "2018047". But the user A is not doing anything.
- Computer B opens the wiki page, where he can create invoices by clicking this "submit"-button. The invoice number is shown as "2018047". The user now creates one invoice; "his" number increases to "201848" and he creates the 2nd invoice.
- Now user A creates an invoice, WITHOUT HAVING RELOADED THE PAGE (and by this flushing the cache or whatever, no idea), and BOOOOMMMMMHHHH, or?

I think that perhaps this could have happened.

I think that this would not have happened, if user A would have reloaded the page because in that case "he" would have been informed that number has increased in between to "2018049". If it is like this then I consider this as a bug in that function. This could/should be fixed by means of a lock, etc. What is others opinion about this?
Avatar
Michaelsy #4
Member since Jun 2015 · 922 posts · Location: Düsseldorf, Germany
Group memberships: Members
Show profile · Link to this post
I think that perhaps this could have happened.

The first and most important step in troubleshooting software issues is to reproduce the malfunction. That means you should verify your theory. Maybe within a test installation.

I think that this would not have happened, if user A would have reloaded the page

You should keep in mind that this only reduces the likelihood that the problem will occur. But it is not completely excluded by this (if the cause determination is correct).
By Patreon.com a few eurons can be fed into the code phasers of
the DokuWiki engine. Besides, Andi's posts are worth reading.
This post was edited 2 times, last on 2018-12-19, 15:24 by Michaelsy.
Avatar
virk #5
Member since Aug 2008 · 608 posts · Location: Aachen, Germany
Group memberships: Members
Show profile · Link to this post
This topic is still unsolved but in my spare time I try to investigate :-)

Question: Where is the ++-counter of the bureaucracy-plugin stored? If I f.e. open the page from a completely new location (no caches, no cookie, etc.) where does the browser get the current number of this counter from?
Avatar
Michaelsy #6
Member since Jun 2015 · 922 posts · Location: Düsseldorf, Germany
Group memberships: Members
Show profile · Link to this post
Quote by virk:
Question: Where is the ++-counter of the bureaucracy-plugin stored?

In the metadata of the page.

You can edit the metadata via the Metaeditor Plugin. (Please note that the same value is in the metaeditor twice. Once under "current" and once under "persistent." I have always changed both entries ​​in my tests. I do not know what these two entries ​​are all about.)

You can also simply enter any value in the appropriate form field. This is then also adopted as an auto-increment value (after submitting).

Furthermore: Indeed the implementation is not multi-user capable. In case of concurrent use, number duplicating is not prevented. At least that is the result of my tests.
By Patreon.com a few eurons can be fed into the code phasers of
the DokuWiki engine. Besides, Andi's posts are worth reading.
This post was edited 3 times, last on 2018-12-28, 20:49 by Michaelsy.
Avatar
Michaelsy #7
Member since Jun 2015 · 922 posts · Location: Düsseldorf, Germany
Group memberships: Members
Show profile · Link to this post
Quote by Michaelsy:
You can also simply enter any value in the appropriate form field. This is then also adopted as an auto-increment value (after submitting).

This means nothing else than that any quantity of numbers could be duplicated in this way. Assuming a person calls the form page without submitting, hibernates his computer and goes on a four-week vacation. In this four weeks 20 invoices are written by his colleagues. He comes back and submitted the form page. In this case the auto-increment value is setted to a four week outdated value and as a result up to 20 numbers will duplicated.

That's it.

Edit: Meanwhile I have verified my theory by tests.
By Patreon.com a few eurons can be fed into the code phasers of
the DokuWiki engine. Besides, Andi's posts are worth reading.
This post was edited on 2018-12-29, 06:46 by Michaelsy.
Avatar
virk #8
Member since Aug 2008 · 608 posts · Location: Aachen, Germany
Group memberships: Members
Show profile · Link to this post
If it was only this, this could be worked around by updating the page prior to submitting. What I experience here is worse; even, if you update the page, the number is not updated. I assume there is an incompatiblity with one plugin etc.. That is why I wanted to know where the ++-counter is stored.
I will have a look into the meta data like you informed me about!
1) When does a page read this metadata? Is it possible that a 2nd browser does not read meta data due to "valid" caches or whatever?
2) In any case I consider this to be a bug or at least something which could be improved. What do you think about that?
Avatar
Michaelsy #9
Member since Jun 2015 · 922 posts · Location: Düsseldorf, Germany
Group memberships: Members
Show profile · Link to this post
even, if you update the page, the number is not updated.

As far as I've noticed, this behavior is caused by the DokuWiki cache. (Presumably DokuWiki assumes that the page was not changed and a change in the metadata is not registered because not checked.)

Maybe you can improve it by using the ~~NOCACHE~~ option.

In any case I consider this to be a bug or at least something which could be improved. What do you think about that?

I think that's a matter of specification. The auto-increment function, as implemented, is suitable for single using, not for multi-user with concurrent use.

I think it's up to you to remedy this. You have the need and the financial benefit. You or your company should program a better solution or pay someone to do it: https://www.dokuwiki.org/faq:support#professional_support_…

I think it's not part of the core competency of a wiki that you can use it to write invoices in group work. But even if it were, DokuWiki is what it is and everyone who wants more needs to take care of it.

But who knows, maybe you can find someone to help you selflessly ...
By Patreon.com a few eurons can be fed into the code phasers of
the DokuWiki engine. Besides, Andi's posts are worth reading.
This post was edited on 2018-12-29, 10:03 by Michaelsy.
Avatar
virk #10
Member since Aug 2008 · 608 posts · Location: Aachen, Germany
Group memberships: Members
Show profile · Link to this post
I have added the ~~NOCACHE~~-option to that page. I will report whether I think it helped. If it is really related to caching purposes and solved by this ~~NOCACHE~~-option then it is fine for me; it just needs to be mentioned in the/our instructions how to handle the counter.
Avatar
Michaelsy #11
Member since Jun 2015 · 922 posts · Location: Düsseldorf, Germany
Group memberships: Members
Show profile · Link to this post
In reply to post #9
Quote by Michaelsy:
even, if you update the page, the number is not updated.

As far as I've noticed, this behavior is caused by the DokuWiki cache. (Presumably DokuWiki assumes that the page was not changed and a change in the metadata is not registered because not checked.)

Maybe you can improve it by using the ~~NOCACHE~~ option.

I must correct myself. For the normal (that means without the Metaeditor plugin) use of the auto-increment function there is no benefit to use ~~NOCACHE~~. The reason is the increment of the value is executed after submitting. Only then does the value change. Therefore you see no change if you update the form page on a browser of a second user. You can see a change after the first user have submitted the form page.

Only when you use the Metaeditor Plugin the ~~NOCACHE~~ option is helpful. Because then the via the plugin edit value will be shown on the updated form page, otherwise not.

Edit: Sorry for the chaotic editing. I checked it again and then it did not work as described.
By Patreon.com a few eurons can be fed into the code phasers of
the DokuWiki engine. Besides, Andi's posts are worth reading.
This post was edited on 2018-12-29, 16:29 by Michaelsy.
Avatar
virk #12
Member since Aug 2008 · 608 posts · Location: Aachen, Germany
Group memberships: Members
Show profile · Link to this post
Correct me, if I am wrong:

1) First user creates 2018045, then "keeps page open" (his form shows 2018046 as next number) but goes on holidays for 4 weeks (This is a nice period of holidays)
2) Second user on a different computer creates 2018046, 2018047, 2018049. As far as I have learned 2018050 is now stored in the meta data of that particular form page.
3) Four weeks later: If first user just submits the form he would create 2018046; this would cause this number having appeared twice. But the first user reloads the form page, "sees" the ~~NOCACHE~~-option, reads the metadata, where 2018050 can be seen and thus he submits 2018050 as new number.

Isn't that correct and/or where is my mistake?
Avatar
Michaelsy #13
Member since Jun 2015 · 922 posts · Location: Düsseldorf, Germany
Group memberships: Members
Show profile · Link to this post
Quote by virk:
Correct me, if I am wrong
Please correct yourself by doing your own experiments. I do not understand why you ask me about things that you can easily explore yourself. (I do not know more about this software than you do. Everything that I have written in this thread, I first researched or tested myself. And of course, you do not have to wait four weeks of vacation to end up your test. ;-) )

No offence! - Michael Sy.
By Patreon.com a few eurons can be fed into the code phasers of
the DokuWiki engine. Besides, Andi's posts are worth reading.
This post was edited on 2018-12-30, 15:43 by Michaelsy.
Close Smaller – Larger + Reply to this post:
Verification code: VeriCode Please enter the word from the image into the text field below. (Type the letters only, lower case is okay.)
Smileys: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Special characters:
Go to forum
Imprint
This board is powered by the Unclassified NewsBoard software, 20150713-dev, © 2003-2015 by Yves Goergen
Current time: 2019-06-17, 03:00:29 (UTC +02:00)