1. 29 May, 2017 4 commits
    • Romain Courteaud's avatar
    • Jérome Perrin's avatar
      Create user preference only when user configure preferences · d362cecd
      Jérome Perrin authored
      To make it easier for users to change their preferences, so that they do not have to create the preference themselves, we tried to pre-create a user preference ready to be configured for each user.  
      
      It was 59860df3 :  an interaction to create a user preference on `Person.setReference` which is more or less the time when this person become a user ( but not really - this was already a weakness of this approach).
      
      This calls `Person_createUserPreference` that initialize the preference by introspecting the assignments of the person. This already had a problem that it was working only if the assignments were created before the reference was set on the person.
      
      With the new user management introduced in !185 this interaction moved to `Person.setUserId`, which is called in Person's init script. This had the following problems:
       - All persons have a user id, so all persons have a preference. For sites with many persons that are not actually users, this create useless preferences.
       - During init, person does not have assignments yet, so `Person_createUserPreference` could not use information from assignment to create preference.
      
      The suggested change is to create the preference only when the user click on *Edit my preferences* button.
      
      This is done by adding a new `portal_preferences.getActiveUserPreference` method that returns the active user preference and create it if not already existing, this way we do not have to put logic in the user interface scripts.
      
      All *Edit my preferences* links should use it like it was done in f62e6651
      
      The `person_interaction_workflow` was completely remove, as the other interaction it was containing - clearCache when deleting the person - was useless . We had to adjust a few tests that was passing thanks to this interaction.
      
      /cc @gabriel @vpelletier @kazuhiko @tc 
      
      /reviewed-on nexedi/erp5!273
      d362cecd
    • Jérome Perrin's avatar
      Don't call a useless getPrice on edit(price=x) · 3b1e230c
      Jérome Perrin authored
      Base.edit has this feature of not actually modifying the properties when
      the new property value is same as the current one, so when we do
      `movement.edit(price=x)`, this will cause an implicit getPrice.
      
      As price lookup is a bit slow, do not lookup price in this case.
      
      /cc @vpelletier @kazuhiko @romain 
      
      /reviewed-on nexedi/erp5!259
      3b1e230c
    • Jérome Perrin's avatar
      Fix clone behavior on transformations · bc3b5a25
      Jérome Perrin authored
      Fix for [#20160719-1B69F57]( https://nexedi.erp5.net/bug_module/20160719-1B69F57 ) 
      
      These after clone methods in transformed resources are being too clever and behave very badly when the transformation itself is cloned.
      
      The suggested approach is to stop initializing int index & reference when cloning transformed resources ("transformation lines"). This behavior is kept when adding new transformed resource. This become consistent with what we have, for example, with Sale Order Lines in Sale Orders. 
      
      /cc @luke @seb @gabriel @kazuhiko @romain @Nicolas 
      
      ( see also !148 for more )
      
      
      /reviewed-on !258
      bc3b5a25
  2. 25 May, 2017 11 commits
  3. 24 May, 2017 5 commits
  4. 23 May, 2017 2 commits
  5. 22 May, 2017 7 commits
  6. 19 May, 2017 7 commits
  7. 18 May, 2017 4 commits