On 1/25/13 7:05 PM, Apache Bloodhound wrote:
> One note though, the permission test should include product column value
when inserting into global environment. But you might wait with that till
after my patch...
IMO it's quite important to be consistent with the previous approach (i.e.
no explicit reference to products in SQL queries ). All this should be
encapsulated e.g. the proxy has to detect whether a product is not set in
context and still translate the query considering `product = NULL` (
`product = ''` ? ) . All instances of `product = NULL` will refer to
resources in the global environment . That would be enough to keep the
interface exactly the same as before .
I don't know how much complicated this will be for you to add this feature
, but IMO it's a **MUST** . Is it feasible up to this point ?
Everything **must** be just like before for both product envs and global
env . That's exactly the point .
''';)'''
I don't find 'product detection' code very appealing. Assuming that
detecting the product column within the INSERT statement would be
relatively easy to do, detecting WHERE conditions is not that trivial.
Therefor I would suggest the following solution - the code should always
run within ProductEnvironment (and never global Environment). In the
global context (URL namespace), the code should get the
ProductEnvironment with the `product == ''`, which would reference
global resources. This would keep the backward compatibility for 3rd
party plugins/trac code even when running in global context - with the
database view limited to 'global product'.
The product aware code would, on the other hand, in both cases (global
and/or product context), have access to global view of the resources
through env.parent property. The translator code would still be disabled
when accessing database through env.parent, making it possible for the
code/plugins to access all product's resources.
Any other takes on this?
Cheers,
Jure
