search

snipe / snipe-it

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

Check-out/ Check-in Asset Picture Missing #8601

Closed jmartins1 closed 4 years ago

jmartins1 commented 4 years ago

Please confirm you have done the following before posting your bug report:

Describe the bug Email notifications: asset picture missing only displaying place holder. Setting to include/not include asset picture in notification missing from notifications settings.

I've run php upgrade.php

To Reproduce Steps to reproduce the behavior: Normal process to check out an item

Expected behavior Asset picture appears or option not to or to include picture available under email notifications settings.

Server (please complete the following information):

Snipe-IT Version: 5.0.1
OS: [e.g. Ubuntu, CentOS] Server 2012 R2
Web Server: [e.g. Apache, IIS] WAMP Server 3.2.3
PHP Version tried 7.1.33 and 7.2.33

Desktop (please complete the following information):

OS: [e.g. iOS] Windows 10 X64, version 2004 OS build 19041.572
Browser [e.g. chrome, safari] Same error on Firefox and Chrome
Version [e.g. 22] latest
snipe commented 4 years ago

asset picture missing only displaying place holder

Not sure what you mean exactly? What placeholder?

What's your APP_URL in your .env? What's the URL of the image it's trying to load?

jmartins1 commented 4 years ago

2020-10-23_8-35-07

APP_URL=https://ARPSINV1

pic

snipe commented 4 years ago

Does that file actually exist there?

jmartins1 commented 4 years ago

no, it exists here C:\wamp\www\snipe-it\public\uploads\models

I do not have this directory directory

snipe commented 4 years ago

no, it exists here C:\wamp\www\snipe-it\public\uploads\models

That's where it should be, and that's where that URL should be trying to find it.

jmartins1 commented 4 years ago

Yes, but the images are not appearing in the emails notifications.

snipe commented 4 years ago

I'm not able to reproduce this locally.

Screen Shot 2020-10-23 at 9 23 14 AM
snipe commented 4 years ago

Do you have the "Show images in emails" setting turned on in your Admin > Settings > General

jmartins1 commented 4 years ago

Yes 2020-10-23_10-36-51

jmartins1 commented 4 years ago

Maybe this might help?

I re-ran the following commands; in this order:

composer dump-autoload composer clear-compiled php artisan config:clear php artisan view:clear php artisan cache:clear php artisan route:clear php update.php

Here are the results: cmd

snipe commented 4 years ago

I can't fathom why it wouldn't be able to find the update.php file. It's definitely checked into the source...

snipe commented 4 years ago

What happens if you run git pull?

jmartins1 commented 4 years ago

It's indeed odd. I was on 5.0.1 and ran these commands except php update php. Then I submitted an issue that I was receiving a 500 server error. One of the users then advised me to run php update.php, which I did. There didn't appear to be any issues running the command and it cleared the 500 error. Today I updated to 5.0.2 (although the missing notifications issue existed in 5.0.1), I then tested the notifications email and had the same issue. I again ran all the commands this time to include the php upgrade.php but the issue still exists.

jmartins1 commented 4 years ago

I attempted git pull. Here is the result. Please note I run this on Windows Server 2012 R2. SnipeIT is hosted on a WAMP Server.

2020-10-23_13-18-42

snipe commented 4 years ago

Ah, this wasn't installed via git then? In your first post, you mentioned you ran update.php, but now you can't anymore?

jmartins1 commented 4 years ago

Correct. If you look at #8583 that might help.

jmartins1 commented 4 years ago

Attempted to start from scratch using instructions on: https://snipe-it.readme.io/docs/wamp

When attempting to run: composer install --no-dev --prefer-source

Received the following errors (small snapshot): 2020_10_25_11_15_53_C_WINDOWS_system32_cmd exe_composer_install_no_dev_prefer_source

I ran composer update, which fixed this issue.

I then ran php update.php, because I was still getting the 500 server error.

These two actions appears to fix both issues. However, after importing my database and necessary files (uploads, etc.) the inventory system indicates total assets greater than zero. Running a custom report, indicates there are items in the inventory system. I am able to search for an asset tag and bring it up, but nothing appears in the All Assets, Recent Activity, etc.

I am also now unable to roll-back php below 7.2.33.

The WAMP Installation No Workie.

snipe commented 4 years ago

You should never ever be running composer update. It means your composer.lock file and ours will be out of sync, and that can cause problems for you down the line (and potential bugs that we won't be able to reproduce.)

Without knowing why those package installs failed, it's tough for us to know that's going on here.

jmartins1 commented 4 years ago

Understood. I ran this on a test installation to try to get past the error.

On Oct 26, 2020, 3:36 PM, at 3:36 PM, snipe notifications@github.com wrote:

You should never ever be running composer update. It means your composer.lock file and ours will be out of sync, and that can cause problems for you down the line (and potential bugs that we won't be able to reproduce.)

Without knowing why those package installs failed, it's tough for us to know that's going on here.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/snipe/snipe-it/issues/8601#issuecomment-716837528

snipe commented 4 years ago

Try running (on the instance you didn't composer update on):

composer install --no-dev --prefer-source --verbose

This can hopefully give you a more verbose output for your composer install process.

jmartins1 commented 4 years ago

2020-11-10_8-21-50

snipe commented 4 years ago

Can you run:

php --version
which php

and tell me the output? (That second one might not work on windows...not sure, I don't use windows.)

I've never seen composer fail like that with no actual specific error messages. I'd have to guess it's a PHP extension issue or a version issue.

jmartins1 commented 4 years ago

php

which php is not recognized

jmartins1 commented 4 years ago

I run ( composer install --no-dev --prefer-source --verbose ) on a new installation of WAMP Server. After installing WAMP, I downloaded Snipeit version 5.0.6 as per https://snipe-it.readme.io/docs/wamp.

php-extensions

php-settings

snipe commented 4 years ago

What about php -m?

jmartins1 commented 4 years ago

php-m

snipe commented 4 years ago

(Can you just paste it in? It makes it difficult to command+f to search on the page and compare with what you should have)

jmartins1 commented 4 years ago

[PHP Modules] bcmath bz2 calendar Core ctype curl date dom exif fileinfo filter gd gettext gmp hash iconv imap intl json ldap libxml mbstring mysqli mysqlnd openssl pcre PDO pdo_mysql pdo_sqlite Phar readline Reflection session SimpleXML soap sockets SPL standard tokenizer wddx xml xmlreader xmlrpc xmlwriter xsl zip zlib

[Zend Modules]

snipe commented 4 years ago

Thanks - I know it's dumb, but it makes my life easier vs scrubbing through images.

I don't see anything funny in there - nothing obvious missing, I mean.

I'm honestly stumped. As I mentioned, I've never seen such a weird error from composer before. :-/

jmartins1 commented 4 years ago

I would not question your greatness... :)

snipe commented 4 years ago

LOL well you probably should....

I haven't given up on this, but I'd love it if other folks who may have seen this before could chime in.

jmartins1 commented 4 years ago

Hopefully you guys can figure this out. I've been religious about updating Snipe-IT since 3.something.

snipe commented 4 years ago

I'm sure we will. Just hang tight. I'm nothing if not stubborn.

uberbrady commented 4 years ago

So I guess I'm wondering if this is something about permissions? Wouldn't make sense that you can create the image file, but then can't display it. That's unusual.

Another thought - the URL that you're using is definitely only accessible from the inside of your corporate network. So long as you're testing your emails and whatnot from the inside, it should definitely work.

Something else to try - what if you grab the attempted URL of both the logo image and the model image, and try and view those just in a web browser inside your network?

Also, I'm seeing https:// as your protocol, but you're using a hostname that probably isn't going to be able to be issued a conventional certificate - maybe something wonky there?

The other thing I'm thinking is that. maybe WAMP has itself configured to send URL's correctly to PHP, but not to be able to browse regular files? That'd be weird, because that's basically how Apache tends to work, by default.

jmartins1 commented 4 years ago

Hi uberbrady, thanks for the feedback.

Another thought - the URL that you're using is definitely only accessible from the inside of your corporate network. So long as you're testing your emails and whatnot from the inside, it should definitely work.

Yes, this is the case. Our inventory system is accessible internally only.

Something else to try - what if you grab the attempted URL of both the logo image and the model image, and try and view those just in a web browser inside your network?

I've attempted to view the images in a browser and only a placeholder is provided. I don't think it's a permissions issue as it worked through multiple SnipeIT versions. Permissions have not been modified.

Also, I'm seeing https:// as your protocol, but you're using a hostname that probably isn't going to be able to be issued a conventional certificate - maybe something wonky there?

Since our inventory system is for internal use only, we use a self-signed certificate (we use LDAP) This was true since version 4.9.4. The break was at version 5.0.0.

The other thing I'm thinking is that. maybe WAMP has itself configured to send URL's correctly to PHP, but not to be able to browse regular files? That'd be weird, because that's basically how Apache tends to work, by default.

Not sure here.

I created a test SnipeIT installation. Installed WAMP, Composer and SnipeIT, but when I ran composer install --no-dev --prefer-source I had nothing but failures. I thought it might be my web filter, so I turn it off temporarily. I also tried doing the install at home. In both cases I still received failures.

Thank you again!

snipe commented 4 years ago

@uberbrady also we embed images in the emails, so even if the Snipe-IT install isn't accessible to the outside world, they are attached to the email inline.

uberbrady commented 4 years ago

Okay, let's test things one-by-one here. First, drop a plain text file in your public/ directory at the base of your Snipe-IT install. Try to browse to https://arpsinv1/yourfilename.txt

Do you 404? or do you see the contents?

If you see the contents, then I think we might have some permissioning issues on the other directories (uploads/models, etc, etc). If not, then maybe it's a web-server config issue.

jmartins1 commented 4 years ago

dir

test

uberbrady commented 4 years ago

okay, good! so we have basic files that we can look at, here.

Do also check https://arpsinv1/test.txt as well, it's absolutely possible that we have some http/https config issue here.

If that checks out, play around with moving your test file up into ./uploads and then even into some of the subdirectories under uploads. (Then test https://arpsinv1/uploads/text.txt, etc).

I feel like we're at least kinda getting somewhere now - and I now at least have a theory that could make sense, which is a good start!

snipe commented 4 years ago

Have you tried this btw? https://github.com/snipe/snipe-it/issues/8701#issuecomment-724653350

jmartins1 commented 4 years ago

Uberbrady, I receive a 404 error when moving the file to the suggested location(s).

jmartins1 commented 4 years ago

The .ENV settings are already in place env

uberbrady commented 4 years ago

@jmartins1 So do you get that 404 via https:// as well as when you move into those directories?

If the https:// test failed, then there's probably something in your apache config - we might want to at least eyeball that. If you can throw it into a gist and paste the link here we can take a look.

Directory configs - look at the permissions in the ./public directory and compare them to the ./public/uploads as well as ./public/uploads/models. If you have any directories that work for images, definitely compare those too. If you see anything glaringly different, mess around with those permissions and see if that gets you anywhere?

uberbrady commented 4 years ago

Oh, and do try a php artisan config:clear in there too, just in case.

jmartins1 commented 4 years ago

Incidentally, I do see the images in SnipeIT. I just don't see them in the emails.

assets

uberbrady commented 4 years ago

Well that's weird. huh. we did do some major changes to the storage subsystem in v5, maybe we missed something in the email-image embedding system?

When you hover over those device image URL's, what're the URL's for those images?

snipe commented 4 years ago

@uberbrady again, I'm unable to reproduce this tho :(

jmartins1 commented 4 years ago

pic

jmartins1 commented 4 years ago

Before you ask :), yes the jpg is in this directory.

jmartins1 commented 4 years ago

Just curious, have you tried installing a WAMP server and walk through the steps in your documents? I tried multiple times and cannot get composer install --no-dev --prefer-source to run without error. I'm happy to backup SnipeIT and start over but I can't get past the Composer install to make it to the pre-flight page.