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

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

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

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

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

- Add functionality to remove event and add a new event by selecting a date on the calendar

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

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

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

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

* do not build db libraries.


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

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

ODBM_File extension is known to be non-buildable on certain OpenSuSE environment, and we don't need it anyway.


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

erp5_banking_* BTs use custom catalog based on old ERP5 catalog structure.
This should not change, for backward compatibility reasons (data migration of
SQL tables would take an unbearable amount of time).
As such, the "owner" column in catalog table means the same thing as
"viewable_owner" in newest ERP5 catalog schema, so:
- "Owner" role must be set to use "owner" column for queries
- indexation of "owner" column must continue using "getViewPermissionOwner"

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

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

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

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