Closed paula-w closed 6 years ago
ADDED
IMPROVED
FIXED
REMOVED
Hi @paula-w
First of all CONGRATULATIONS - its obvious so much work has gone in to this (as always).
Just downloaded and installed upgrade without any problems, thought mine would cause many issues having customised it so much. Will now start testing it and feed back any issues/bugs.
Looks amazing - loving all the new 'unexpected' features. Well impressed 👍 Cannot wait to explore more.
Installation went ok, the custom modules made in 4.2 not working any more. Must inspect tomorrow. Otherwise seems fine. Great.
I too am finding a couple of small issues. I use the Competition module for another purpose and this no longer works - I get an error of:
Incorrect request ERR_NOT_ALLOWED_VALUE
When I click on the menu link for the module.
I too will investigate properly tomorrow and check other parts of the system too
Some feedback on the RC version. Install went well if PHP timeout is set long enough. Checking the version number still gives 4.2.514 in the footer after the update. Checking the modules, the Roundcube lib needs updating, pressed the button and it became red (from yellow) needed to download. Pressed the download button but nothing happened. Did a manual download here from github and tried to install as file but failed. (Module does not contain default language (en_us).) Custom module not working anymore Our filter issues still there.
Well the custom modules works ok, the menu not, remowing "&mid=359&parent=0" from the menu address "index.php?module=OSSEmployees&view=List&mid=359&parent=0" opens it. Otherwise
@kpaulaha
how were you able to test that your custom module worked ok? Is it just the menu links that don't work in your case? I am setting some time aside later (or first thing tomorrow) to go through my update and feed back.
Same here. Removed and added the menu but keep getting: Incorrect request Incorrect value detected, please contact your administrator
@PercyP I made a widget on the home page viewing records of the custom module, and it did show them. Opened from that a record and the list view. Have 4 custom modules and all works fine, only the url from menu does't work, not even if you make a new menu item.
Hi, it appears the problem is only with main links in the side menu. If you move a link to a sub menu it works. For example I had the Email link as a main menu item but then I moved it under Contacts and it opens fine. Other Links that have no sub-menus i.e. they are opened direct from the menu produce the same error - see attached screenshot
As an example when I click on the Dashboard menu link the url ends with: /index.php?module=Home&view=DashBoard&mid=45&parent=0
It seems to be the ones with no parent item that fail
I just tested on developer version.
I created a new menu item called Test Account and added it to the bottom of the menu. Then I tried to open it and get the following error message: Incorrect request Incorrect value detected, please contact your administrator
u_yf_browsinghistory
(userid
, date
, title
, url
) VALUES (5, '2017-11-19 11:49:18', 'Accounts List', 'index.php?module=Accounts&view=List&mid=152&parent=0') || yii\db\Command::executeSee attached screenshot of the same:
Thank you all a lot for all the errors you found, and for all the effort you put into finding them during the weekend. Could we ask you to open separate issues for each of these errors, with a description how to replicate them and error logs? You can add in the description that these errors popped up after the update and you can reference this issue to avoid duplicates. It's going to make it much easier for us to track and solve the issues.
@zebrahosting Roundcube update should work now, thanks!
Please don't get me wrong, but this are too much (fundamental) changes in a minor version update.
This time are a lot of code breaking changes inside. If you have custom modules, there is no way to follow all those steps. Those step to replace code "old style" to "new style" should be documented, so anyone can follow without reading thousands of commits. At least when inside a minor version number update.
I know and understand most of them are because of security reasons, but that deserves a major version step and so a "real" update plan to get up with code changes.
Fundamental functions, that no longer exists should get a "deprecated" time frame. So a update from 4.x to 4.y would not harm an existing installation.
Sometimes less is more.
This is @bpabiszczak's answer:
If the updates are too frequent or too hard for some people then they can update their system less frequently [eg. every 2 – 3 versions] or order the update from someone who can do it for them. You have to remember that each change in the system affects us more than anybody else because we update several dozen systems. However, we think these changes are good and necessary - this is why we make them.
no, not less, better more frequent. Right now even fatal error will only be "official" fixed after 3-4 month. Of course you can patch your system for yourself and have it fixed immediately. But that's quite hard to follow if you are not the reporter of the failure/fix.
And yes: it will if affect you even more. So with more and more success to this product, this problem will become greater and greater.
And even more yes: these changes are necessary - absolutely. The code base is grown over years, From the code itself you can see ancient stuff, bad stuff and many lines you would never ever code like this. There is a clean-up needed - no question. The problem is not the improvement itself, it's the way how you can get it. Maybe on possible solution is to rethink the release cycle itself, to make more intensive use of the git branches possibility, so that such a "fatal fix" can be (auto-) released within a day to the stable branch and you continue to work on the "next" branch. Sa the server's will updates themselves or can be updated by a simple click to the latest stable. Instead a big update a lot of small updates.
All I want to say is, that its quite hard to follow the development. And I also know how hard it is to communicate the current development actions to other (remote) developers. That's one of the core problems each open source project has.
E.g. Can we have "developer chat hour" once in a month? Or Can we have a reference module, so others can see what is the "state of the art" access to the e.g., fields? How should lists return the display value? How to access request parameters (like after one of those security enhancements)? Like a living coding documentation: What is the current reference implementation (and that one covered by unit-tests).
Right now @bpabiszczak or @mariuszkrzaczkowski may know it, because they talked about it simply in the office, but nobody else knows it (or not before studying code changes in the last xx days).
@migoi everything you said is true! We see our mistakes, our flaws, and shortcomings. Even inside the company we keep discussing whether or not what we do is good because many users might stumble upon some problems because of that.
Unfortunately Vtiger itself was poorly written [and at the very beginning of the project we had no idea, we, ourselves, were just starting to figure programming out], and even though 3 years have passed we still keep fixing their low quality code. At the start we decided that the first 2-3 years were the right time to introduce changes quickly, and changes that “break” the system, because once the system gets more popular then many companies would suffer. So right now we’re at the end of that road that end users might consider “inconvenient”. Keep in mind that a ton of projects, like SuiteCRM, SugarCRM, Vtiger, JoForce, EPESI, or coreBOS have awful code. It can’t be changed without affecting companies that use the system, and the more time passes the worse it gets. Looking at it from this perspective, I think we made the right decision as far as these changes are concerned.
Additionally, since Feb 2017, together with another company, we’ve been working on one of the largest deployments in Europe for more than 12k users. Because of this, for a few months, we didn’t have anybody who’d be able to develop the open source version the way we wanted it to be – we are still building our dev teams. A year ago we were a 7 people team, right now there are 18 of us and even more will join in Dec. You have to give us some time to build a “professional” release cycle, we know how to do it, we just need the right people. Starting from 5.0 we want to release hotfixes on an ongoing basis for all fixed errors.
Of course "developer chat hour" is a good idea [and we have a ton of other good ideas] and we will most likely make that happen, but the question is why hasn't the community ever bought the 15h package and spent it on "developer chat hours". And - will just an hour be enough... Because from my experience 1h is usually what one person needs, not the whole group.
Hi @migoi, @bpabiszczak etc. I have a number of customisations which get effected by the updates but for me it is worth the effort as I know its all going in the right direction. As they say, "you have to crack a few eggs to make an omelette" we are (hopefully) nearly finished 'cracking eggs'. I like the bold decisions that have been taken to address the bad code early on - even if it has caused headaches and confusion at times. When things are going smoothly, it can either be because the product is so perfect it no longer has errors/bugs (rarely ever the case) or it is not getting updated or moving forward and has become stagnant! It looks like Yetiforce is growing and establishing itself, these things take time. I like the rapid releases (and all the new features they bring). I also appreciate the work that goes into it.
Even inside the company we keep discussing whether or not what we do is good because many users might stumble upon some problems because of that.
When this does happen, the support here has been relatively good. Thankfully everything I have personally come across in terms of update issues has been easily fixed, and I have always taken a backup AND run the update first on a copy of my master version.
Yes there has been troubles, we have had to do many new re-installs, got pretty nasty reactions on simple things and then again tested and tested many others and still come back to Yetiforce since it still is our favourite and heading in a solid feature.
The hotfix idea has been around since v2 but not really started unless something was really broken. We would love to see this implemented and good it is on the list again. We also fully understand the hurdles that are there with the growing pain. Thats why we are still here from day one put the extra time in too re-install, fix, report and re-import things.
We recommended Yeiforce CRM to our clients but got in trouble when they paid voor support but never got a support person to answer their questions properly. Bizar situation. The whole paid support idea should work but not if the same support department is overloaded. We also paid for support we did not fully use but there is no way to check how much is left. The whole paid support system should be setup a bit better if that is a real plan to make money.
On our wishlist a way to export / import customs fields and/or custom modules . Reason: with the frequent new installs to avoid bringing errors to new releases we have to redo them every time and makes it the most time consuming issue.
Long story short: lets keep working together to make Yetiforce better. Big steps are done, more steps and trouble ahead but it is worth it. Lets try to keep the communication friendly and positive. (In ancient Taoist tradition: with 'soft eyes').
@zebrahosting I too like the hotfix concept. It would be easier to track individual issues with updates. I also like the idea of being able to export import custom fields and module. I think we can export/import custom modules already? I have not yet tried this - so not sure if this is the case.
The update package has been improved. You can find it here.
@KatarzynaUlichnowska isn't there too many fles below updates/files/vendor/ e.g. ./composer? Seems they are taken from real installation
@migoi I checked the files and they are all right, what is missing in your opinion?
@mariuszkrzaczkowski the Certs, the installed.json. That may depend whats installed on the local installation? Or do i mix up a development and a production fileset
If RC1 run earlier RC2 not installing on that. But suppose no need to.
Just run the update - so far so good. All custom modules/fields still working. Menus working great. WIll continue testing
Could you please open a new ticket for this (and any other) issue? It would help us keep track of all the issues. Please send your full logs to github@yetiforce.com, and paste the fragment with the error into the issue. Thanks a lot!
@zebrahosting I’m not entirely sure what you mean when it comes to support, we register all hours we spend on helping the client [from what I see you used 13h 40min last year]. I don’t remember what your issues were, and which ones we managed to solve and which we didn’t, so I can’t talk about that. If you think any of the issues are still open you can write directly to p.walenczak@yetiforce.com and she will take care of them.
I know for sure that if our cooperation had been closer and more intensive, YetiForce would’ve been a better product today, so remember that it’s not completely up to us what YetiForce is like, the clients and community can influence that as well.
The package has been updated to version RC4.
We upgraded a few of our clients’ systems from some old versions to 4.3 RC and we found a some errors in the old update packages. All packages where the errors existed were fixed and can be found here: https://github.com/YetiForceCompany/UpdatePackages Next week [before Christmas] we will publish 4.3 and if there are any comments or if you found any errors please report them by Tuesday, because from Wednesday on we are going to fix errors for 4.4 already.
Unfortunately, we have not been able to fix all the important errors, so we are moving the date of publication 4.3 to 2017-12-29. A new update package 4.2.0_to_4.3.0_RC8.zip is ready https://github.com/YetiForceCompany/UpdatePackages/tree/developer/YetiForce%20CRM%204.x.x/4.2.0_to_4.3.0
Thanks for letting us know. Just about to go test the new update :O) Have a great holiday
how update 4.2 to 4.3 site /index.php?module=ModuleManager&parent=Settings&view=ModuleImport&mode=importUserModuleStep1
not work
Incorrect module version. Module version: 4.2.0 - System version: 4.3.0
With version 4.3 just around the corner, there are a few things we would like to say.
First of all, we would like to thank you - our amazing community - for helping us make YetiForce better. We appreciate all your efforts, and we are grateful for every single pull request, bug report, and suggestion you sent us.
In this issue, you will find the link to the RC version. This version includes many fixes and improvements (changelog in the first comment), however, we are aware that we might have missed a bug or two, and we would like to ask you to help us find these bugs.
If you want to report a bug that you found, please provide us with a very detailed step-by-step description how to duplicate it, and send your logs to github@yetiforce.com (the subject of the email must be the GitHub issue number)
You can download the update package from: https://github.com/YetiForceCompany/UpdatePackages/tree/developer/YetiForce%20CRM%204.x.x/4.2.0_to_4.3.0/zip (package updated on 07.12.2017)
IMPORTANT:
The update package introduces a new password encryption mechanism that requires setting a new password. We recommend enabling the reset password mechanism when performing the update and configure SMTP. There is an option for the system to reset system administrators’ passwords and send them via email. If the passwords are not mailed we recommend setting a new password for all users after the update.
All widgets in record summary should be configured once again after the update ( Software configuration > Standard modules > Modules – Widgets); the configuration has been rebuilt, which will cause the widgets to stop working. Please open the widget and save it again.