1. 29 Jun, 2022 6 commits
  2. 28 Jun, 2022 1 commit
  3. 27 Jun, 2022 2 commits
  4. 24 Jun, 2022 4 commits
  5. 23 Jun, 2022 2 commits
  6. 22 Jun, 2022 5 commits
  7. 19 Jun, 2022 2 commits
  8. 17 Jun, 2022 4 commits
    • bensinober's avatar
      DEICH-6272 koha : fix Front lookup · 40616271
      bensinober authored
    • bensinober's avatar
      DEICH-6271 remove unused async · 4a26681d
      bensinober authored
    • bensinober's avatar
      DEICH-6271 eslint fixes · 8b7747c1
      bensinober authored
    • Tom Adam's avatar
      DEICH-6271 - Added validation to library event sections · df35aad8
      Tom Adam authored and Benjamin's avatar Benjamin committed
      Library event sections is a dynamic form contained within a create or edit component.
      Whether updating or creating a library event should be allowed or not, is dependent on the validation state of all the dynamic form elements added to the arrangement sections.
      On the other hand, the update/create parent component is not interested on the field level validation result of an arrangement section subcomponent (which consists of potentially many subfields with possible validation attached). To decide whether the save/create button should be enabled or not, it is enough to know, that all fields in a given section (Arrangementsseksjon/Medieseksjon/Blokkeseksjon) are valid.
      Taking all this into consideration a new component was introduced, called Validatable (Validatable.svelte). This is a component with one slot, exposing its setValidProp method.
        This method updates the propValidity object, which is indexed by all the property names included by a section component. In addition, there is a reactive property called allValid, which triggers an allValidChanged component event if all the input elements in the given section are valid (allValid === true), or some of them are invalid (allValid === false).
        The event dispatched contains an object with a unique allValidKey key, which is a symbol (unique on component instance level after the component is attached to the slot of the wrapper Validatable). A single prop cannot be used in this case, since an allValidChanged event is valid for a whole section, potentially containing many properties.
        This way the arrangement sections can contain whatever number of the same type of section, and still have a record of identifiable validity thanks to the unique symbol keys.
        The allValidChanged component event is propagated to the create/update component using standard svelte component event propagation.
        Note, that as the Validatable component is removed, an allValidChanged event is fires with a true value, since the component should not invalidate the create/update component any longer, it is recycled.
        This mechanism is quite universal, so handling the Blokkeseksjon type was straightforward. That is basically a "section in the sections" setup. See the code for details.
        In the future it is wise to take into use the Validatable component in case of non-section form sub-elements (like EditLibraryEventLocation, EditLibraryEventContent etc...), since in all those cases it is the same scenario: the create/update component is only interested in whether all fields requiring validation in the sub-form component are valid or not. This way quite a lot of code could be removed.
      Closes DEICH-6271
  9. 14 Jun, 2022 1 commit
    • Tom Adam's avatar
      DEICH-6268 - Fixed mapping+tests as agreed. · e0147307
      Tom Adam authored
      Muligens blir det flere iterasjoner ettersom det er fortsatt none BS/DFB spesielle tilfeller. Må vurderes om det er verdt å bruke tid på disse (antall spesielle tilfeller er ukjent foreløpig).
      Closes DEICH-6268
  10. 10 Jun, 2022 2 commits
  11. 09 Jun, 2022 1 commit
  12. 31 May, 2022 1 commit
  13. 30 May, 2022 4 commits
  14. 27 May, 2022 5 commits