search

snipe / snipe-it

A free open source IT asset/license management system
https://snipeitapp.com
GNU Affero General Public License v3.0
10.94k stars 3.16k forks source link

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

Closed AlexanderWPapyrus closed 2 years ago

AlexanderWPapyrus commented 2 years ago

Debug mode

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

jFsKiX8YK1 pIZ69bGBw0

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

snipe commented 2 years ago

We're still working on this issue btw

snipe commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

What browser are you using?

snipe commented 2 years ago

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

fredbotfred commented 2 years ago

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

AlexanderWPapyrus commented 2 years ago

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).

https://user-images.githubusercontent.com/80526133/159654768-27a338e4-ee13-4dcb-a93e-110321cb18eb.mp4

AlexanderWPapyrus commented 2 years ago

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. image chrome_oKELWYAp8V

fredbotfred commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

~~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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

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 https://github.com/snipe/snipe-it/pull/9529

So in our case upgrading is always a hassle 😅

Robert-Azelis commented 2 years ago

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.

image

snipe commented 2 years ago

@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 commented 2 years ago

@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): image

image

uberbrady commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 1 month ago

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 commented 1 month ago

@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.