Some Columns (Vanilla) are not displayed even when saved in Cookie

[AlexanderWPapyrus]

Debug mode

• I have enabled debug mode
• I have read checked the Common Issues page

Describe the bug

Hi,
we updated to v5.3.6 and now some coulums are not displayed after a page reload. It seems like the cookie is saved (maybe wrong)
I just tested with ID, Company and Model Number (probably more coulumns are affected (custom work fine)).
I first tested on clean installed browsers on multiple machines, then checked the cookie with an addon.
It seems that the by default displayed/enabled coulumns are working fine.

Couldn't see any errors in debug mode.
Hope you can reproduce (No, actually I hope it's just us 😬)

Best wishes and thanks for this awesome project,
Alex

Reproduction steps

1.Reproducable also in demo with freshly setup windows client (Chrome, FF, Edge)
2.see GIF below

Expected behavior

Show selected coulumns after page refresh/change

Screenshots

Snipe-IT Version

v5.3.6

Operating System

Server Ubuntu, client Windows

Web Server

Apache

PHP Version

7.2.34-2+ubuntu18.04.1+deb.sury.org+1
upgraded to
7.4.27
(No difference regarding issue)

Operating System

Windows 10

Browser

Google Chrome, FireFox, Edge

Version

No response

Device

No response

Operating System

No response

Browser

No response

Version

No response

Error messages

None found in debug mode
I tried to change the "COOKIE_NAME=snipeit_session" but with no effect (also after cache reload etc)

Additional context

No response

[fredbotfred]

I'm seeing the same behavior on Safari running within Mac OS Monterey. I'm running Snipe It on Debian 11 with PHP 8.0.14.

[spartan117aut]

I noticed the same behaviour within my fresh install. (v5.3.8 - build 6619, Docker)
The purchase_date column is saved in the "assetsListingTable.bs.table.columns" cookie but not displayed after a refresh. Also reproducible on your demo site using different browsers!

[snipe]

We’re working on this issue. Thanks so much for your continued patience.

[snipe]

We're still working on this issue btw

[snipe]

We may have accidentally fixed this issue as we were fixing something else - can you pull from master and see if you can still reproduce this behavior?

[fredbotfred]

Just pulled and updated my instance (Version v5.4.1 - build 6746 (master)) and I'm still seeing this behavior on most columns.
The Device Image column remembers its state, but the rest don't seem to. As a test, I selected all the columns and refreshed the page. Only Asset Name, Device Image, Asset Tag, Serial, Model, Category, Status, Checked Out To, Location, Purchase Cost, Checkin/Checkout, Actions stayed after the refresh.

[snipe]

What browser are you using?

[snipe]

(I am unable to replicate the issue anymore on Chrome, Brave, Edge, and Safari - all MacOS.)

[fredbotfred]

Chrome 99.0.4844.82, Windows 10 Pro 21H2
Also had my colleauge test it on his Mac (Safari on Monterey 12.3)

[AlexanderWPapyrus]

Also in the demo "Check out a live, up-to-date version of the master branch of Snipe-IT." v5.4.1 build 6746 (g3e22dce11)
It doesn't work, neither on 2 company PCs (edge, Chrome), a clean windows sandbox, nor even on my private Phone Android Chrome. Also I tested here in Austria and on a colleges PC in Texas (to check location, language etc. variations).

Again, it's only the by default deactivated columns. Custom and default activated once work fine (on/off).

373d1b3b-c3d0-4dba-9454-6f0ef4355390.mp4

[AlexanderWPapyrus]

Hi there,
As a workaround I now set the "visible" => false to true in Snipeit/app/presenters/AssetPresenter.php
Now the field behaves normaly, it's checked by default and now I can reload the page with it remembering the old status.

confirms that it's the by default unchecked fields (except custom) (when I set false for custom fields, they have the same issue).
Hope this helps,
Alex

ps. I have slightly modified the design so people don't think it's phishing when they need to accept Assets 😉 but the issue is also on our vanilla test domain.

[fredbotfred]

I made AlexanderWPapyrus' change to Company, Model No., Purchase Date, Order Number, and Notes in my AssetPresenter.php and these columns now behave as expected.

[m4zl]

Tried the changes from @AlexanderWPapyrus and they are working like a charm for us, too - thanks! This could be also used for us to set a "default view" as many of other people requested here.

[Robert-Azelis]

Unfortunatelly problem still exist for v5.4.1 - build 6746 (master) and also for v6.0.0-RC-7 - build 6787 (develop), tested on Chrome 100.0.4896.60 and Edge 99.0.1150.55
Solution from @AlexanderWPapyrus it's working only for assets and relates to ID, Company columns, for People or Accesories it doesn't work, require additional changes for related files of xxxPresenter.php.

For me still working solution is to use for replace file snipe-it/public/js/dist/bootstrap-table.js from v5.3.3

[AlexanderWPapyrus]

For me still working solution is to use for replace file snipe-it/public/js/dist/bootstrap-table.js from v5.3.3
Thanks!
Dzięki!
Seems I just didn't clean a cache or something. Turns out it didn't work :/

[snipe]

@AlexanderWPapyrus In general, it's a bad idea to do this, as it can cause problems upgrading, and it's very likely we upgraded the version of bootstrap tables due to a security vulnerability in the JS library. (We don't generally just upgrade libraries for no reason.)

[snipe]

@AlexanderWPapyrus That sort of doesn't make any sense though...

https://github.com/snipe/snipe-it/blob/v5.3.3/package.json#L35

locks the version in at 1.19.1 for 5.3.3, which is the same as the one from 5.4.1:

https://github.com/snipe/snipe-it/blob/v5.4.1/package.json#L35

GitHub

snipe-it/package.json at v5.3.3 · snipe/snipe-it

A free open source IT asset/license management system - snipe-it/package.json at v5.3.3 · snipe/snipe-it

GitHub

snipe-it/package.json at v5.4.1 · snipe/snipe-it

A free open source IT asset/license management system - snipe-it/package.json at v5.4.1 · snipe/snipe-it

[AlexanderWPapyrus]

Hi @snipe ,
In general, it's a bad idea to do this, as it can cause problems upgrading
yeah I totally aggre, also after I changed the bootstrap, somehow I got the impression that it works, but it didn't so I changed back to the original and just left the modified vsible=true workaround.
Just in my case we always set up from scratch and migrate a backup (and compare the .env). We also modified the php artisan snipeit:user-inventory to be only send out to mobile device users and that only mobile devices are listed in the mail. Also we modified the email texts, barcode generator (before I commited the higher DPI adjustment), and that the acceptance signature field has only accept but no deny radio button.

Our next big modification will be that as soon the user signs an asset, we get the acceptance email again but with the signature, so we can print it out and hand it over to our HR department. I'm just waiting for #9529

So in our case upgrading is always a hassle 😅

[Robert-Azelis]

For me replace file snipe-it/public/js/dist/bootstrap-table.js from v5.3.3 it's working and file between 5.3.3 and newer one 5.3.8 / 5.4.1 is different.
It was tested in private mode (on Chrome and Edge) and on few different workstations, result was this same, older version works correctly. I also tested it on other server and got this same result.

[snipe]

@Robert-Azelis okay, but we literally are using the same versions in both, as I showed you - both of which are latest from bootstrap-tables.

[Robert-Azelis]

@Robert-Azelis okay, but we literally are using the same versions in both, as I showed you - both of which are latest from bootstrap-tables.

sorry to say, but content both files are different (compared 5.3.3 with 5.4.1):

[uberbrady]

Very weird and very interesting. When I check this out, this is what I see:

diff package.json v5.3.3/package.json

44c44
<     "jquery-ui": "^1.13.1",
---
>     "jquery-ui": "^1.13.0",

So maybe it's the locked packages?
diff package-lock.json v5.3.3/package-lock.json

4236c4236
<       "integrity": "sha512-yd9c5AdiqVcR+JjcwUQb9DkhJc8ngNr0MahEBGvDiJw8puWab2yZlh+nkasOnZP+EGTAP6rRp2JzJhJZzvNF8g==",
---
>       "integrity": "sha1-tcmMlCzv+vfLBR4k4UNKJaLmB2o=",
11633c11633,11634
<           "integrity": "sha512-q0M/9eZHzmr0AulXyPwNfZjtwZ/RBZlbN3K3CErVrk50T2ASYI7Bye0EvekFY3IP1Nt2DHu0re+V2ZHIpMkuWg=="
---
>           "integrity": "sha512-q0M/9eZHzmr0AulXyPwNfZjtwZ/RBZlbN3K3CErVrk50T2ASYI7Bye0EvekFY3IP1Nt2DHu0re+V2ZHIpMkuWg==",
>           "optional": true
14238a14240
>               "optional": true,
14252c14254,14255
<               "integrity": "sha512-6eZs5Ls3WtCisHWp9S2GUy8dqkpGi4BVSz3GaqiE6ezub0512ESztXUwUB6C6IKbQkY2Pnb/mD4WYojCRwcwLA=="
---
>               "integrity": "sha512-6eZs5Ls3WtCisHWp9S2GUy8dqkpGi4BVSz3GaqiE6ezub0512ESztXUwUB6C6IKbQkY2Pnb/mD4WYojCRwcwLA==",
>               "optional": true
16241,16243c16244,16246
<       "version": "1.13.1",
<       "resolved": "https://registry.npmjs.org/jquery-ui/-/jquery-ui-1.13.1.tgz",
<       "integrity": "sha512-2VlU59N5P4HaumDK1Z3XEVjSvegFbEOQRgpHUBaB2Ak98Axl3hFhJ6RFcNQNuk9SfL6WxIbuLst8dW/U56NSiA==",
---
>       "version": "1.13.0",
>       "resolved": "https://registry.npmjs.org/jquery-ui/-/jquery-ui-1.13.0.tgz",
>       "integrity": "sha512-Osf7ECXNTYHtKBkn9xzbIf9kifNrBhfywFEKxOeB/OVctVmLlouV9mfc2qXCp6uyO4Pn72PXKOnj09qXetopCw==",
18337c18340,18341
<       "dev": true
---
>       "dev": true,
>       "optional": true

Those seem to be relatively trivial changes between the two. Maybe it's some other strange artifact of the build? Like, we built the JS on 'too new' of a node.js version, or 'too old', or something?

[uberbrady]

okay, I re-read this entire thing from the beginning and re-tested it. And I can definitely confirm it's very much still broken. And I can also confirm that v5.3.3 works. So I just kinda need to bisect the code to find out where it broke. Easy peasy.

[Prodeguerriero]

Hi all.

Just wanted to let you know that while the issue appears to be gone when playing around within /hardware or in a specific asset model, I still experience a similar behavior when editing visible columns while looking at status labels (i.e. statuslabels/###

[shanemartin22]

This problem has re-appeared - seems to only be happening in Chromium based browsers (Chrome, Edge) but Firefox works fine.

Version: v7.0.11 build 15044 (g46ed07642)

[snipe]

@shanemartin22 We have not heard of any other reports of this issue. This issue is from 2022. Please create a new issue and fill in all of the questions in the new issue form. (When you reply to old, closed threads, it sends an email notification to everyone who ever participated in it, which can be pretty annoying to have happen on a thread that's been resolved for a while.) You can try switching to local storage instead of cookies, but I can't reproduce this.