Hello everyone.
So we have this problem:
https://github.com/frappe/erpnext/issues/17730
And we got two PR, the first one is closed and the second one is merged into the development
https://github.com/frappe/erpnext/pull/17774
https://github.com/frappe/erpnext/pull/18059
We use erpnext projects module to manage our tasks. We have a project with more than 160 tasks. But one member of our team updated the expected end date of the project and the erp changed all the tasks linked to that project to old values.
Are everyone experiencing this problem? Anyone found a way to solve it?
4 Likes
It seems that there isn’t support to the current version of ERPNext, instead, all the effort and focus are set in the new version (v12).
The PR #17774 solved the issue for v11 but was closed because doesn’t have tests (tests that wasn’t present before anyways) and because Rushabh thinks that there is a common use case (arbitrary desicion IMO).
To solve for us, we start to use a fork with this fix alongside another ones. We are still making new pull requests to fix new issues we are encountered but it’s seems that a fork is a must in order to achieve a steady version.
2 Likes
After upgrade to ver 12, the task table is not visible on the project view (at least on this implementation). Is this the intended result of the breaking change? In the project doctype there is no link to the task table.
1 Like
Yes, it seems to be. I did not like it, but that’s how it was done.
For Frappe to require tests to show and validate the impact of changes moving forward may seem arbitrary, unreasonable or a nuisance, but ultimately that is a good thing.
Otherwise to continue with poor test coverage jeopardizes the long term quality viability and so on of ERPNext.
Would you not agree?
Absolutely - stability above all else.
1 Like
Not the only way but arguably the best way to solve this?
Once you identify the problem, write a test to demo reproduce the exact issue.
After you fix the problem code, the test should pass.
Provided all the other tests pass too, only then can you commit the code change fix.
Thereafter if that test fails, identify and resolve the problem with the pending code change that causes the test to fail.
Follow that ‘test driven’ practice and be confident you are on the right path.
I must say the inclusion of the task list / table on the project view was a very handy feature.
We are now trying to create a workaround work flow. The advantage was that birds eye view of dates were available on opening a project view.
In my view direct calendar integration with a project would be ideal.
2 Likes
I agree of course. But I don’t agree with the idea of “if a functionality has a bug then we remove it instead of solving the problem”. The task table in the project’s doctype was a feature used by a lot of people and now it’s gone, just because nobody wanted to fix the problem.
Not to mention that the functionality in question was bugged for like 10 minor versions and still is in v11.
I think that that’s not the correct path.
Would you not agree?
1 Like
"
The child table “Project Task” was a UX hack so that the user can quickly add tasks to project. This type of 2-way syncing is an anti-pattern and source of bugs and performance problems.
"
I am not certain but the feature rmehta removed might be a design defect. If Project & Task refer to eachother in a circular reference, then a deadlock or contention could occur upon a change/update to one or the other.
Tests would highlight such a problem case.
Fortunately users have options, to restore the code to suit themselves.
1 Like
Looking at various posts and frappe’s design principles, the creation of real M2M / Many to Many relations are not supported at this time. The solution appears to be a much more difficult problem to solve and a hack as clarkej say is not a solution. Are any plans on the table to implement a M2M solution in the future? I understand that table relations are not managed on the database level.
Is this a M2M case? I think not.
One project can have multiple tasks but one task can’t be in multiple projects.
Of course with open source we are all free to own ‘the problem’.
My fear is poor test coverage will mire and plateau development progress.
Users will grow disenchanted with QA issues like this one.
IMHO that’s a technical debt that is the elephant in the room!
It looks like m2m on the implementation side. I.e. in django could do Task.objects.filter(projects__title__startswith=“SomeProjectRef”).distinct() or whatever other filter on m2m. The implementation is circular and have no idea how to even approach a test as it is. Saw the link here How do I create a bidirectional link between two doctypes? - #2 by rmehta. It is the correct decision to remove the task project table. I’m now using the task calendar which is fine.
My plan was to wait until a “stable” version 12 but I migrated to it anyway because it is an important feature for us.
We don’t really need that task table here, as said:
There are other ways to get the information that we need from ERPNext. It just seems odd that we had to migrate so early because of one feature.
I think that the migration (either early or late) is not really a problem. Been using ErpNext for a year today and I can only say thank you very much to the developers. I am very grateful to have the use of such an excellent product. Thank you once again.