Bug: plugin OCS NG 1.03 (and upwards) + workaround

bpavlinic · 2014-09-10 14:48:58

Update: I changed topic from "Error somewhere in Enable the financial and administrative information" to "Bug...", because the original topic title is not the error/bug, it is "just" a very very very negative behavior (lost 2 computers and restored it from backup) of the plugin-bug.

Read last post first. (with workaround)

Hello,
I updated from 0.84.5 to 0.85.7 five days ago, no error on update.

Now, I cannot enable the financial info under Computer->Management (global setting is off, I do not need it for all computers).
There is an error: not allowed.
So I changed to Root entity (I use 14 sub entities)
tried again, no error, but: an other computer, from a different entity has now the same attributes as the computer I have enabled financial info.
All is changed, name, software, components, serial... all! On the historical tab I have a list of all the changed attributes, (roll back seems impossible, list is long).
A different computer with enabled financial info are ok, (I can edit and save the financial info).

I looked into the SQL base,
under glpi_infocom i have a new ID (332) and item ID (777).
the computer ID that I tried to enable is ID 777, and the computer that got all attributes changed is ID 332. bug? item_id and id mismatch?

The source of infocom (front and class) are not changed. So where to watch to track down the error?

Best regards,
Boris.

Last edited by bpavlinic (2014-09-16 08:36:42)

yllen · 2014-09-10 17:37:16

Do you have a recursive profile from root entity?
Look at your profile if you have write rights on financial information.
Do you have error in debug mode? in /file/_logs/php-error.log ? sql-error.log?

bpavlinic · 2014-09-10 18:52:46

Yes I have users with recursive from root, entity only and sub entity recursive.
The computer got only changed if I have rights on both entities.

Yes, I have write rights.

I tried now with the my ultimate admin profile, recursive, all inclusive rights. Same thing.
After enabling the financial info for computer ID 777 i got the "successful" message with a target link /glpi/front/computer.form.php?id=332 (wrong one!, that's the same ID from glpi_infocom.id and should be the same from glpi_infocom.item_id)
I enabled debug mode, only the php-error.log with text "Test" was created. No other log is created. On on screen SQL-Request does not mention ID 332, only ID 777.

The computer are all with OCS plugin created. I recently updated from 1.02 to 1.03. The Computer with ID was created with ocs-plugin 1.02, is the computer with ID 777 corrupted? With the old GLPI 0.84.5 was no problem with enabling Financial.

Update:
I added manually a computer, there is no problem with enabling financial. I can save without errors or strange changes. After enabling some other financial on computers (the new ID in glpi_infocom.id was in these cases not a valid computer.ID in my base) I got it enabled, but cannot save any changes in financial Error: "field not found". There are nod debug-infos in that page (no SQL), just the error.

Last edited by bpavlinic (2014-09-11 00:00:08)

bpavlinic · 2014-09-12 01:56:23

Hi,
i traced some hours... and:
on the computer ID 777 is the FORM tag in the final html missing!
So if I click on save the financial info its sending the update to:
form name="form" method="post" action="/glpi/front/computer.form.php"
instead of form name="form_ic" method="post" action="/glpi/front/infocom.form.php"

The html form tag is only missing when I select "Management" tab and the computer is an OCS imported (db:glpi_computers.is_dynamic=1). When I select "ALL" and scroll down to the financial info, the form html tag is there and I can edit/enable the financial info normally.

if I manual switch in SQL glpi_computers.is_dynamic for this computer to "0", all works well.
Does anyone has a clue where to look why the computer.form.php is not sending the right form if its and OCS computer?

Update: it seems that all TABs under computer are not adding the form tag, only ALL is working. I traced source-code infocom.form.php and computer.form.php, no change from 0.84.5.
In the code from infocom is a $canedit value, under it "IF $canedit then show: form tag" (that's ok), and lower there is "if $canedit then show: save and delete". thas OK, but why the heck this form-tag is missing in the final html? After enabling debug and showing "Display only tab for debug" the form-tag is visible! Only tabbed not!

Where to look? CSS? AJAX? extjs? some timeout error? Glass of beer?

Please can someone check if the form tag is missing on an OCS imported computer?
Go to Computer->Documents right click on "Add new file" -> inspect element. go up to div class="firstbloc"
direct under it there must be a form tag. If not: welcome to the club.

Last edited by bpavlinic (2014-09-12 03:29:11)

bpavlinic · 2014-09-12 09:29:51

After a long night...
If the selected computer is an OCS imported computer, the first formblock after the computer itself is without "form post tag".
So I am also missing the the form-tag in the html source under Computer->ALL
That is the "component" block, so I do not need id, but where is the bug???

I'm trying to find the enable-all-debug-option in Apache, GLPI, MySQL and will report...

Last edited by bpavlinic (2014-09-12 09:33:00)

yllen · 2014-09-12 11:00:49

in database,
- in glpi_computers, what is the value of entities_id for ID 777?
- in glpi_infocoms, what are values of ID, itemptype, entities_ID and is_recursive for items_id = 777?

bpavlinic · 2014-09-12 11:26:58

- glpi_computer.entities_id=3
- glpi_infocoms:
ID = 332
items_id = 777
itemtype = Computer
entities_ID = 3
is_recursive = 0

I think the SQL data is correct, I there any navigation_tab erro? (js?) or maybe something in tte php.ini settings (force flush?).

I will upload sam screenshots... maybe it will help.

bpavlinic · 2014-09-12 12:14:31

screen shot of my computer id 777 under Assets-Computer-ALL:

For the third block and all other is the form-html-tag present.

If I set the glpi_computer.is_dynamic to 0, the html source contains the form-tag under class="spaced":

<div class="alltab">...</div>
div class="spaced">
  <form id="form_device_actionXXXXXXX" name="form_device_actionXXXXXXXX" action="/glpi/front/item_devices.form.php" method="post">

if I delete the row with id 777 in the plugin - ocs relationship table, the form html tag is also always visible. Where does the computer.php going if is_dynamic is true? which tables to check?

yllen · 2014-09-12 12:22:34

I don't understand: you have a problem with financial information but you put a screen shoot of components.

bpavlinic · 2014-09-12 19:48:37

I thought that too!
But it is on every single tab in /glpi/front/computer.form.php
I does not matter if is Management, Components etc...
It is always the "second block" where the form-html-tag is missing and if the computer is an OCS computer.
On the last tab "ALL" is the second block by default "components", so there is no form-html-tag.

Last edited by bpavlinic (2014-09-12 19:49:29)

yllen · 2014-09-12 20:21:57

I have no problem with standard version of glpi.
You don't use a standard version (colours are different in your screen shoot) this is perhaps the explanation.

bpavlinic · 2014-09-12 21:31:06

I tried that first, i reverted to original CSS files, that does not matter.

Here is the original colored GLPI, with the same missing form tag:
(saved, rebooted and still same).

Whats fascinating is that the <form..> AND </form> are missing...
Only I set is_dynamic set to 0, <form..> and </form> are there!
see:

So if you have no clue where could this error come from: I am doomed.
I will try from scratch, new server, fresh install, OCS_import and then test for this error. If there is no error I will restore the SQL dump into the new one... wish me luck!

bpavlinic · 2014-09-13 10:03:42

Hello,
bug still there.
I started from scratch.
I did not restore any settings from my running GLPI.

What I did:
new webhost, new sql.
I downloaded GLPI 0.84.7 and OCS import pluging 1.03.
added an sub root entity, setup OCS import plugin to connect to OCS-SQL, added rule to assign the OCS items to the sub-entity. Run the OCS import.
After that I added manually a computer.
Result: all form-html-tags are missing as described in my previous posts on all OCS imported computer. Form-html-tags on the manually added computer are working normal.

Last edited by bpavlinic (2014-09-13 12:32:42)

bpavlinic · 2014-09-13 14:47:22

I think there is an error in the plugin OCS. When you look on my blue screen shot, you see the OS Inventory NG tab (down right).
When it is not there, the form-error does not appear. I have no clue how plugins are working, nor how they manipulate the computer.php...

bpavlinic · 2014-09-13 19:56:58

Got it!
Its not an GLPI bug in "Assets->Computers"

It is an OCS NG plugin fault:

GLPIROOT\plugins\ocsinventoryng\inc\ocslink.class.php

disable line 103 with adding /* ... */ (and line 157):

/* echo "<form method='post' action=\"$target\">"; */

and disable line 157:

/* Html::closeForm(); */

this fixes the HTML error with "form"-html-tag...

As i parsed the source-html I got the error that a form-html cannot be placed into form-html.
And this does OCS plugin 1.03.

Revision 336 trunk/inc/ocslink.class.php added the form-html-tag. Do you need that? I breaks html-rules.

The screenshots are from "Google inspect", so I did not saw the error in html-formatting because Google throws all errors away...

Best regards,
Boris.

Last edited by bpavlinic (2014-09-16 08:39:42)

tsmr · 2014-09-19 15:02:30

Ticket opened :

https://forge.indepnet.net/issues/5060

t_roloff · 2015-05-22 10:52:41

A note to users, which are still using 0.84.x:

If you apply the patch manually, be sure to change function showSimpleForItem accordingly:
https://forge.indepnet.net/projects/ocs … rev_to=336

Best regards,
Torsten.

p.s.
Dear glpi-developers,

we use your software for ~400 systems and are very happy with it. Thanks for the very good work!

But if there is a bug which silently corrupts your database (i.e. changing data in an unexpected way, randomly and hardly to recognize for one of the main objects which are stored within the database), wouldn't it be a good idea to have a statement in a prominent place of your website, as you would do for security issues? Ok, the bug is within a plugin, but it affects the whole system...

Forum GLPI-Project

Announcement

#1 2014-09-10 14:48:58

Bug: plugin OCS NG 1.03 (and upwards) + workaround

#2 2014-09-10 17:37:16

Re: Bug: plugin OCS NG 1.03 (and upwards) + workaround

#3 2014-09-10 18:52:46

Re: Bug: plugin OCS NG 1.03 (and upwards) + workaround

#4 2014-09-12 01:56:23

Re: Bug: plugin OCS NG 1.03 (and upwards) + workaround

#5 2014-09-12 09:29:51

Re: Bug: plugin OCS NG 1.03 (and upwards) + workaround

#6 2014-09-12 11:00:49

Re: Bug: plugin OCS NG 1.03 (and upwards) + workaround

#7 2014-09-12 11:26:58

Re: Bug: plugin OCS NG 1.03 (and upwards) + workaround

#8 2014-09-12 12:14:31

Re: Bug: plugin OCS NG 1.03 (and upwards) + workaround

#9 2014-09-12 12:22:34

Re: Bug: plugin OCS NG 1.03 (and upwards) + workaround

#10 2014-09-12 19:48:37

Re: Bug: plugin OCS NG 1.03 (and upwards) + workaround

#11 2014-09-12 20:21:57

Re: Bug: plugin OCS NG 1.03 (and upwards) + workaround

#12 2014-09-12 21:31:06

Re: Bug: plugin OCS NG 1.03 (and upwards) + workaround

#13 2014-09-13 10:03:42

Re: Bug: plugin OCS NG 1.03 (and upwards) + workaround

#14 2014-09-13 14:47:22

Re: Bug: plugin OCS NG 1.03 (and upwards) + workaround

#15 2014-09-13 19:56:58

Re: Bug: plugin OCS NG 1.03 (and upwards) + workaround

#16 2014-09-19 15:02:30

Re: Bug: plugin OCS NG 1.03 (and upwards) + workaround

#17 2015-05-22 10:52:41

Re: Bug: plugin OCS NG 1.03 (and upwards) + workaround

Board footer