IRC logs of #tryton for Tuesday, 2021-04-20 #tryton log beginning Tue Apr 20 12:00:01 AM CEST 2021
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton01:04
-!- thaneor( has joined #tryton02:04
-!- thaneor1( has joined #tryton02:04
-!- yangoon( has joined #tryton03:04
-!- springwurm(~springwur@ has joined #tryton07:04
-!- mrichez(~Maxime@2a02:a03f:c2e8:f900:ed77:85ea:af2b:ba6e) has joined #tryton07:04
-!- Timitos(~kpreisler@2001:a61:482:eb01:762b:62ff:fe84:ed7e) has joined #tryton07:04
-!- mrichez(~Maxime@2a02:a03f:c2e8:f900:ed77:85ea:af2b:ba6e) has joined #tryton08:04
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton08:04
mrichezhi, back with my access rules... i notice we can duplicate a model having a readonly field. In my case, i need to set a field readonly for a specific group, so the advice was to use field access rules..09:04
mrichezThen i define a field with write access = False (same as setting a field readonly) to a specific group... in this case, i cannot duplicate a record09:04
mrichezshould we consider to allow duplicate a record with a field with write access = False (this field will be empty) or how could i set a field readonly depending on a group otherwise than with access rules ? Thanks for help.09:04
mrichezYou can reproduce easily this behaviour in demo: now you can duplicate a party. Then you define a field access rule on field name on party (all access, except "write") then you cannot duplicate a party09:04
-!- ludo2(~Thunderbi@2001:912:1480:380::1) has joined #tryton09:04
pokolimrichez: which is the error raised when duplicating?09:04
-!- rpit( has joined #tryton09:04
mrichezpokoli: you are not allowed to access "Model.field_name"09:04
pokolimrichez: I guess the error is raised in this line:
mrichezpokoli: could we adapt the behavior ?09:04
pokolimrichez: Not sure but it seems there is something to improve here09:04
mrichezpokoli: would be nice...09:04
pokolibecause you are not directly writing the field but copy sends all fields to ensure the new record has the same values thant the previous one09:04
mrichezpokoli: i think fields without write access should be set to None...09:04
pokolimrichez: I think we should keep the other record value09:04
mrichezpokoli: or default value09:04
pokolimrichez: and if you need to clear it you can always do by overriding the copy method09:04
mrichezpokoli: ok09:04
mrichezpokoli: so this check is useless ?09:04
mrichezpokoli: should i open a discuss or create a feature ?09:04
pokolimrichez: no, it's not useless because it should be enforced when creating new recorsd09:04
pokolimrichez: but probably the check should be skipped when copying09:04
cedkI do not think it is right to skip access check when copying09:04
cedkif the user can not create the exact same record manually, he should not be allowed to do so with copy09:04
cedkalso not setting value for field without access will result in an different copied record09:04
cedkthe only case I think this could be done is if the current value is the default value09:04
-!- nicoe(~nicoe@2a02:578:852a:c00:7e2a:31ff:fe5e:b25d) has joined #tryton09:04
mrichezcedk: back with my case... my field is a boolean field which is only writable by admin once model is validated... duplicating a record with current value is like giving an access to this field to unauthorized user09:04
pokolimrichez: you should clear the value when copying, so the default value is set09:04
pokolibut IIUC this will also crash ash the user is not allowed to write on this field09:04
mrichezpokoli: ok, so back to problem09:04
nicoeAbout, I don't think there is anything to do in trunk but those failure (due to dict not being ordered back in python3.5) will be burden. Maybe we should use sort in the assert09:04
pokolinicoe: IIRC we agreed on disabling failing tests on 3.5 because this is no longer supported09:04
nicoepokoli: OK09:04
cedkwe agree when the cause is external tools09:04
cedkI would not like to have trytond tests disabled09:04
cedknicoe: I think the test should be improved also on trunk because it should not rely on internal design like the order a dict is filled09:04
cedknicoe: maybe the easiest way is to convert domain list to set10:04
mrichezcedk: which is the difference between create access and write access ? Duplicate is creating a new record, no ? So field write access should not be checked...11:04
cedkmrichez: create access on field is only for relation field like One2Many11:04
cedkmrichez: otherwise it is always write access that is needed11:04
mrichezcedk: ok11:04
cedkmaybe we should add a note about that in the doc11:04
mrichezcedk: ok, so to resolve my problem i could create a wizard (custo) to copy all fields of a model except those not writable11:04
cedkmrichez: I think your access on field should not be static11:04
cedkmrichez: for me it looks like it depends on a kind of state11:04
mrichezcedk: it's the field which define the "state"... validated or not...11:04
mrichezcedk: would be easier if readonly states could depends on group with a pyson eval11:04
cedkmrichez: it can using the context and Id12:04
mrichezcedk: so i'll try this way12:04
-!- mariomop(~quassel@ has joined #tryton13:04
mrichezi noticed reviewbot was not updating my bugs ? i add to add review manually... problem ?13:04
pokolimrichez: You should do it manually:
mrichezpokoli: ok, thanks!13:04
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton14:04
-!- thaneor2( has joined #tryton14:04
-!- thaneor( has joined #tryton14:04
mrichezcedk: i set readonly state on my field depending on group admin, i remove field access rules and now everything is working correctly (duplicate, record readonly when field is checked by admin,...) :-)15:04
mrichezdo you think useful to explain on discuss what i did to allow giving more rights to user but not admin rights (in my case, validation of a product) ?15:04
pokolimrichez: discuss is our knowledge base, so anything you share there it may be usefull for anyone that haves the same behaviour16:04
mrichezpokoli: i'll update a previous discuss about this subject:
pokolimrichez: great16:04
pokolicedk: weblate broke sao translation another time. I retranslated in catalan to see if this fixed. But IIRC the issue also affected French16:04
pokoliWrong translations are marked as inconsistent because they have an equivalent transaltion in tryton which has a diferent value16:04
pokoliSo they can be found easly16:04
cedkpokoli: there is no error
pokolicedk: ok but I need to fix catalan manually16:04
cedkpokoli: I do not understand what you want to fix16:04
pokolicedk: this changeset
pokoliBut it only affects catalan16:04
cedkbroken software as usual16:04
cedkACTION the opensource tooling is really dieing16:04
pokoliBut I do not understand why it happens, because on french you have also non ascii codes16:04
pokoliOk, I think I fixed all16:04
mrichezhi, small bug with purchase_requisition, when removing currency and trying to add a line... should i allow to add a line without currency and set currency required on save (like for purchase) or prevent to add a line if currency is not set ?16:04
pokolimrichez: which is the purchase behaviour?17:04
mrichezpokoli: currency field is required, but you can add lines without field currency set....17:04
pokolimrichez: now I do not understand which is the bug17:04
mrichezcreate a new purchase_requisition, remove currency set by default, and try to add a line...17:04
pokolimrichez: ok, I've seen the traceback. You shouldallow to add a line wihthout currency without any exception17:04
-!- Timitos(~kpreisler@2001:a61:482:eb01:762b:62ff:fe84:ed7e) has left #tryton17:04
-!- rpit( has joined #tryton17:04
-!- Timitos(~kpreisler@2001:a61:482:eb01:762b:62ff:fe84:ed7e) has joined #tryton17:04
mrichezpokoli: ok17:04
-!- ludo2( has joined #tryton17:04
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton22:04

Generated by 2.16.0 by Marius Gedminas - find it at!