Error when trying to view documents from client portal

Self-Hosted | v5
#1

I am testing a newly installed self-hosted system (v5.3.67-C77) on Ubuntu/PHP 7.4.3/Apache and am running into the following error when clicking the “View” link on both quotes and invoices from the Client portal:

# Call to a member function exists() on null (View: /invoiceninja/resources/views/portal/ninja2020/components/entity-documents.blade.php) (View: /invoiceninja/resources/views/portal/ninja2020/components/entity-documents.blade.php)

I am able to download the PDF versions of the documents without any issues. storage/logs/invoiceninja.log and Apache logs yield nothing.

Any thoughts?

#2

Hi,

Thanks for reporting this!

Note: the latest version is now v5.3.68

cc @david

#3

@hillel, thank you. I updated to the latest version and the issue is resolved. Thanks!

#4

Glad to hear it, thanks for the update!

#5

Hi there,

I’m facing the same issue with the latest version (v5.3.75-L77) as of today after docker down, pull and up from the previous version (first time self-hosted install, whitelabeled).

Also took care of cache via docker exec -ti dockerfiles-app-1 php artisan optimize.

Error persists. Any chance I can debug this further?

The laravel.log shows an exception occurring during

<?php if($entity->documents->count() > 0 || $entity->company->documents->count() > 0 || ($entity->expense->exists() && $entity->expense->invoice_documents)): ?>

in the view being called.

The PDFs are available via the back-end but not the client portal. Client portal is active but without client registration enabled.

Thanks
cng

(Edits for version details, errors and configuration settings)

#6

@aegidel

That looks like old code, are you sure you have pulled in the latest docker image?

5.3.75 should show

($entity->expense && $entity->expense->invoice_documents)
#7

@david

I checked to make sure and docker image inspect gives back

       "Env": [
            "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
            "PHPIZE_DEPS=autoconf \t\tdpkg-dev dpkg \t\tfile \t\tg++ \t\tgcc \t\tlibc-dev \t\tmake \t\tpkgconf \t\tre2c",
            "PHP_INI_DIR=/usr/local/etc/php",
            "PHP_CFLAGS=-fstack-protector-strong -fpic -fpie -O2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64",
            "PHP_CPPFLAGS=-fstack-protector-strong -fpic -fpie -O2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64",
            "PHP_LDFLAGS=-Wl,-O1 -pie",
            "GPG_KEYS=42670A7FE4D0441C8E4632349E4FDC074A4EF02D 5A52880781F755608BF815FC910DEB46F53EA312",
            "PHP_VERSION=7.4.26",
            "PHP_URL=https://www.php.net/distributions/php-7.4.26.tar.xz",
            "PHP_ASC_URL=https://www.php.net/distributions/php-7.4.26.tar.xz.asc",
           "PHP_SHA256=e305b3aafdc85fa73a81c53d3ce30578bc94d1633ec376add193a1e85e0f0ef8",
            "INVOICENINJA_USER=invoiceninja",
            "INVOICENINJA_VERSION=5.3.75",
            "BAK_STORAGE_PATH=/var/www/app/docker-backup-storage/",
            "BAK_PUBLIC_PATH=/var/www/app/docker-backup-public/",
            "IS_DOCKER=true",
            "APP_ENV=production",
            "LOG=errorlog",
            "SNAPPDF_EXECUTABLE_PATH=/usr/bin/chromium-browser"
        ],

The back-end also shows v5.3.75-L77 on the info tab.

I’ve also deleted the locally cached image, pulled it again (my docker-compose.yml is vanilla with regard to the invoiceninja service and should pull the latest v5 anyway), no change.

Any other idea? Thank you for looking into this.

EDIT: I’ve manually changed the code in the generated view for now, it fixes the problem. I’m afraid to be using an old code-base though.

#8

@aegidel

I’m not sure here, I just pulled in the latest via docker-compose and I can see the correct code, so I am baffled as to how you are seeing this.

#9

Thanks @david ,

I’m also rather confused. It does look like a clean install will be my best option. I’m new to invoiceninja and don’t know the sources enough to trust just overwriting the framework files from source to catch all inconsistencies.

I’ll wait for the next update and observe what’s happening in the container, maybe comparing ctimes and changes to the framework files before taking this approach.

My.install is standard apart from supervisor and MySQL backup configuration.

If anything pops up I’ll report back.

#10

This has been solved. The error was on my side due to a syncing issue on a distributed file system not honoring docker specifics. My bad, thanks!

#11

Glad to hear it’s working, thanks for the update!