> So from now on bugs can be reported normally on LP ?
yes, trunk branch
> Should we continue to follow website-al branch, or any pending issues will go
> directly to trunk?
trunk
>
> Regards,
> -Mario
>
>
> On 02/01/2014 09:47 AM, Fabien Pinckaers wrote:
>> Dear community,
>>
>> Yesterda
Title: Eric CAUDAL
That sounds the right direction but a
bit complex.
I was thinking of a simpler system: a password-protected
certificate at group level to be unlocked by that the user
password belonging to the group. This certificate would then allow
Great !
A couple questions...
So from now on bugs can be reported normally on LP ?
Should we continue to follow website-al branch, or any pending issues
will go directly to trunk?
Regards,
-Mario
On 02/01/2014 09:47 AM, Fabien Pinckaers wrote:
Dear community,
Yesterday we merged the CMS an
Thats great, looking good.
I mentioned that Enapps also planned to release something last week which
would have worked well for the BI. The idea was to implement a module that
allows materialisation of certain views as supported by Postgres 9.3
However, we decided not to create a standalone modul
Dear community,
Yesterday we merged the CMS and eCommerce modules in trunk. This mean you
can test it on our online SaaS offer.
To test these features, you easily start a free trial here:
https://www.openerp.com/start?app=website
Some of the features you may want to test:
- CMS (website
Well, as I have said, it's only a maintained module of an old approach, but
here it is:
http://bazaar.launchpad.net/~pedro.baeza/serviciosbaeza-openerp-addons/7.0/files
I have improved my OE skills a lot since them ;)
Regards.
2014-02-01 Antony Lesuisse
> Please send a link to the source cod
Please send a link to the source code. I will check it.
On 02/01/2014 03:30 PM, Pedro Manuel Baeza Romero wrote:
Hi, Antony,
I worked some time ago (on v6.0) in two modules called
/account_periodical_invoicing/ and /sale_recurring_orders/ that play with
these concepts. I have been maintining th
Hi Eric,
This is actually a pretty useful feature to have, and its usefulness
becomes evident in shared hosting environments and in the face of
hostile administrators.
Usually there are two types of answers given to this type of question:
1. Use some sort of shared secret (like a password that is
Hi, Antony,
I worked some time ago (on v6.0) in two modules called
*account_periodical_invoicing* and *sale_recurring_orders* that play with
these concepts. I have been maintining them up to v7, but they work in an
isolated way and with some incomplete concepts (for example. analytic
entries gener
Yes this feature is quite small it's located in account_analytic_analysis.py
recurring_* feilds and account.analytic.invoice.line.
We plan to improve this feature a bit to allow choosing between SO or invoice,
discount on lines, and optional pro-rata temporis invoicing on lines.
On 02/01/2014
Thanks Anthony, I hope that theses precisions will also be useful to
others and help understand your development process. So saas branch are
really the future V8, really interesting.
About my case, unfortunately I can't wait for V8 but it's clear it would
be safer to stick to OCB branch. Maybe
I would need it for a float or m2o so as is this seems limited for my use
Eric Caudal (From his mobile)
Holger Brunn wrote:
>Hi Eric,
>
>> I would expect a way to encrypt some critical data at database level
>> (password, accounting information, salaries).
>> I am not sure here but I have the f
> I would need it for a float or m2o so as is this seems limited for my use
Does encrypting IDs really make sense?
For encrypting float/int/char fields (very short plaintexts have their own
challenges), the more I think about it, the more I think the right way to do
that would be creating a tex
I arrived basically to the same conclusions.
I will have a look at Holger's development which seems interesting.
Eric Caudal (From his mobile)
"W. Martin Borgert" wrote:
>On 2014-02-01 18:18, Eric Caudal wrote:
>> We face another security/data access issue with a customer who would
>> like to be
We are developing a web add-on to make invisible some js elements depending on
received js content in the form.
Nevertheless it needs to be used in coordination with ORM security rules to be
effective.
Eric Caudal (From his mobile)
Ferdinand Gassauer wrote:
>__
Hi Eric,
> I would expect a way to encrypt some critical data at database level
> (password, accounting information, salaries).
> I am not sure here but I have the feeling that encryption/decryption
> though should only be possible through a certificate/key at
> browser/client level to protect the
On 2014-02-01 13:46, Frédéric Clementi wrote:
another big issue are attachments access rights - i just give 2 examples
* attached documents (invoice-pdf) may not be deleted/altered manually
- as fiscal law requires reproduction during a long period
* confidential documents attached to emplo
On 2014-02-01 18:18, Eric Caudal wrote:
> We face another security/data access issue with a customer who would
> like to be able to hide the salary information from his IT
> administrator.
Eric, I hope I'm wrong, but I don't believe this is possible,
neither with OpenERP nor any other similar syst
Title: Eric CAUDAL
Hi,
I am not sure this exactly the same topic as Frederic mentioned and
I didnot want "to leech" on the topic...
We face another security/data access issue with a customer who would
like to be able to hide the salary information from his IT
adm
Dear OpenERP,
At Camptocamp we are more and more concerned about the lack of security
settings in OpenERP.
With the v7 we had a great new tools with the security rules which allows
us to give rights at object level. This is a great feature but you have to
go further.
More and more of our custome
20 matches
Mail list logo
