Forum Replies Created
-
AuthorPosts
-
ppmtParticipant
This would be a start definitely but I understand if that is not a priority.
I have no idea what kind of massive effort it would require but may be have a configuration where you could select what and in which order to display various filed would be a good idea?
Again I can see that it it is not a priority
ppmtParticipantI have thought about it after each upgrade but I hitting a wall with my other user (wife) who got used to the way I “designed” it.
Is there a way to make it so that the description field is always displayed rather than hidden by default?
If I can convince her it for sure would make my life easier.
My next tasks will be to redo the template as it doesn’t seem to be compatible with the new version anymore.
Thanks for your time
ppmtParticipantI attached a zip file instead
Attachments:
ppmtParticipantHello,
I have attached a tar.gz from the custom/default_templates/invoicesThere are from the version I am still using until I adapt to master-2020
Version is:
version.update_date = 20181012 version.name = 2018.1.3
Yes very old….
ppmtParticipantHi Richard,
In case you missed it 🙂
October 22, 2019 at 12:58 pm in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #701ppmtParticipantThe “old” method makes more sense. It is not often that you need to go back through your old invoices.
I am sure Richard had his reason to change it
October 22, 2019 at 12:06 pm in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #699ppmtParticipantyes that is indeed a lot but I am not sure that anything can be done on the database side. I mean Mysql/Mariadb are very efficient database that can handle much more request that 4440 query.
I would think it is the processing of these queries that takes a lot of time
October 22, 2019 at 8:13 am in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #697ppmtParticipantI have about 200 invoices I think. It can be a bit slow as well but since I am only testing it at the moment it is not on the fastest machine. It takes about 10 seconds for me to load the invoices pages
October 22, 2019 at 7:44 am in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #694ppmtParticipantRichard seems to be away at the moment. He is really the one that would be able to help you.
October 22, 2019 at 2:51 am in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #692ppmtParticipantNo PDF export does work for me. The issue I had was my templates would not display properly with things all over the place.
I found that mpdf which Richard is using has some limitation with some CSS attributes.Once knows the templates can be adapted
On my side I am using a bit of strange config.
I have a docker container running:
– linux Alpine rev 3.10.2
– PHP 7.3.9 with PHP-FPM
– Nginx 1.16.1in another container I have Mariadb (rev 10 I think)
October 22, 2019 at 2:31 am in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #690ppmtParticipantGlad you got it sorted.
For the PDF I feel for you. It is not as easy as one would think to export to PDF. I have been struggling myself with its limitations.
October 21, 2019 at 12:50 pm in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #681ppmtParticipantfor the php.log file what does the custom.config.php contains? Here is mine
debug.level = All debug.error_reporting = E_ERROR phpSettings.date.timezone = Europe/London phpSettings.display_startup_errors = 1 phpSettings.display_errors = 1 phpSettings.log_errors = 1 phpSettings.error_log = tmp/log/php.log
October 21, 2019 at 9:00 am in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #674ppmtParticipantwell if all of them are really set to 0 then you have a different issue than I did. I would still check the sqlbackup file to be sure.
And are you sure you don’t have a php.log file in your tmp/log directory?
October 21, 2019 at 8:52 am in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #670ppmtParticipantIs that all your product listed there? If you are like me then only a few were loaded..
I would suggest to check the sqlbackup file (it should be a text file) to make sure that the field default_tax_id_2 is really set to either null or 0 for all product.
- This reply was modified 5 years, 1 month ago by ppmt.
October 21, 2019 at 2:19 am in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #667ppmtParticipantcan you check the database dump file you have (the one you imported) and check that the table si_products.
If the field default_tax_id_2 is set to “” (empty) then it is the reason it was failing for me. The solution is to update the file to set the empty field to null and the reimport the database and restart the upgrade.
-
AuthorPosts
Recent Comments