git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42745 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42744 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42743 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42742 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42741 20353a03-c40f-0410-a6d1-a30d3c3de9de

 - accept arguments in main method to make it easier to use it as entry point, and merge properly passed arguments with passed from command line

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42739 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42738 20353a03-c40f-0410-a6d1-a30d3c3de9de

- add response to each calendar request

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42737 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42736 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42735 20353a03-c40f-0410-a6d1-a30d3c3de9de

Revert part of r42730. Real full text search will be provided by a separate business template (MySQL full text, Sphix or another one).

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42734 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42733 20353a03-c40f-0410-a6d1-a30d3c3de9de

* support that one can have more account types in asset, equity or liability. It was producing wrong GL and TB
* make sure to call the analytic scripts on accounting_module

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42732 20353a03-c40f-0410-a6d1-a30d3c3de9de

- fixes the case where organisation has no group

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42731 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42730 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42729 20353a03-c40f-0410-a6d1-a30d3c3de9de

we need to update generated portal types as well


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42728 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42727 20353a03-c40f-0410-a6d1-a30d3c3de9de

time instead of runtime.

Since the portal type does not change, and since methods are wrapped
individually depending on the portal type, it is safe to do this at
registration time.

It means that no "useless" interactions are attached to objects,
and that the portal type check only happens once in the life of a method.
Overall, this should contribute to better performances.


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42726 20353a03-c40f-0410-a6d1-a30d3c3de9de

notify* methods are never called if the guard evaluates to False. This
check looks costly and useless.


The only possibility (?) would be that one of your Interaction workflow guards
checks kw['workflow_method_args'] and returns a different result depending
on when _checkTransitionGuard is called.
That seems like a tricky (wrong? unlikely?) usecase.
If you are in this case, let me know, and if needed I'll engineer a fast guard
check that is only ever checked once.


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42725 20353a03-c40f-0410-a6d1-a30d3c3de9de

Correct and update comment: we _do_ use isWorkflowMethodSupported to check the
guard of a transition before running it, check Base.WorkflowMethod implementation.


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42724 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42723 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42722 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42721 20353a03-c40f-0410-a6d1-a30d3c3de9de

If this is not the case, we should adapt code registrating methods
to skip non-triggers instead of checking invalid transitions all the
time. Hence the assert.


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42720 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42719 20353a03-c40f-0410-a6d1-a30d3c3de9de

"raise urlnorm.InvalidUrl" was not catched because it was in an except clause.

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42718 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42717 20353a03-c40f-0410-a6d1-a30d3c3de9de

* Detect searchable column from dynamic related key feature of catalog.


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42716 20353a03-c40f-0410-a6d1-a30d3c3de9de

New test to check that Listbox is able to set-up searchable columns automatically according their id.

Currently dynamic related_keys are not searchable columns, this test point out this lack of feature.

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42715 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42714 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42713 20353a03-c40f-0410-a6d1-a30d3c3de9de

- remove not used files correctly

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42712 20353a03-c40f-0410-a6d1-a30d3c3de9de

erp5_jquery is used and can be used in other skins (not only "View"). Such a case is any ERP5 Web Site using jQuery.

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42711 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42710 20353a03-c40f-0410-a6d1-a30d3c3de9de

- improve css to calendar
- remove not used javascript file

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42709 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42708 20353a03-c40f-0410-a6d1-a30d3c3de9de

Testing with current zope test runner (2.12) which has one thread only will cause inside the only running zope's thread an another request to same zope instance. Zope will accept this new request and wait for parent request to finish.As result it's a typical deadlock case which will last until some timeout is reached. This totally breaks test runner in zope 2.12.

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42707 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42706 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@42705 20353a03-c40f-0410-a6d1-a30d3c3de9de