main Koha release repository branch 16.11.x updated. v16.11.09-33-g193f139

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

main Koha release repository branch 16.11.x updated. v16.11.09-33-g193f139

Git repo owner
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "main Koha release repository".

The branch, 16.11.x has been updated
       via  193f139062226547d42f66ebfce5a094003e3ea4 (commit)
       via  885886fe2e414eff3fb7ee812f69b811938e1f06 (commit)
       via  794061a947f3275ac82e6fc0a168ae44a0af6b28 (commit)
       via  bb179998b47d4d6f3b5674cdfc96508276b341ad (commit)
       via  cedae4535ba4b91826b4476d109070c847fad160 (commit)
      from  f5da355d4f2fc4435d1581afa0cbb462e9f389f0 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 193f139062226547d42f66ebfce5a094003e3ea4
Author: Marcel de Rooy <[hidden email]>
Date:   Wed Jun 14 15:37:55 2017 +0200

    Bug 18634: Handle colliding translation for preference sections
   
    Problem on this report was caused by translating the tabs Privacy
    and Payments by the same string. This caused overwriting a hash entry.
   
    This patch tests if the key already exists and if so, it merges the
    entries instead of overwriting the old contents.
   
    Test plan:
    [1] Make sure that e.g. Privacy and Payments translate to e.g Vie privee.
    [2] Run translate install fr-CA (or the language you altered)
    [3] Without this patch you should loose preferences from either Privacy or
        Payments. With this patch, they should be merged.
   
    Signed-off-by: Marcel de Rooy <[hidden email]>
    Tested with fr-CA.
   
    Signed-off-by: Blou <[hidden email]>
    Reset the .po files, reproduced the problem.  Applied the patch and suddenly 'paypal' appeared.
   
    Signed-off-by: Julian Maurice <[hidden email]>
   
    Signed-off-by: Jonathan Druart <[hidden email]>
    (cherry picked from commit 0d98089ec701bc96893e68408ce2dedad36f7235)
    Signed-off-by: Fridolin Somers <[hidden email]>
    (cherry picked from commit 7bcad818744b11180b2b2c31a5dda8d51552b862)
    Signed-off-by: Katrin Fischer <[hidden email]>

commit 885886fe2e414eff3fb7ee812f69b811938e1f06
Author: Christophe Croullebois <[hidden email]>
Date:   Thu Jun 8 13:17:56 2017 +0000

    Bug 18756: Users can view aq.baskets even if they are not allowed
   
    Due to bad use of grep syntax if there is one or more Basket Users the result of grep is not equal to 0 and the borrower is allowed.
   
    Test plan :
    1- select system preference 'AcqViewBaskets' on 'user'
    2- create 2 borrowers (A, B) with only permissions on acquisition :
    group_manage
    order_manage
    order_receive
    staff
    3- login with A and create a basket
    4- add a basquet manager other than B
    5- relog with account B
    6- you can see the basket
   
    Apply the patch.
    The basket is no longer visible.
    1- relog with A
    2- add basquet manager B
    3- relog with B
    5- you must see the basket
   
    Signed-off-by: Josef Moravec <[hidden email]>
   
    Signed-off-by: Nick Clemens <[hidden email]>
   
    Signed-off-by: Jonathan Druart <[hidden email]>
    (cherry picked from commit 0c09adbfc87b950b9f08aebede131ba694997290)
    Signed-off-by: Fridolin Somers <[hidden email]>
    (cherry picked from commit 9800895cabade7ad8d78ff986a9a156f3962efa2)
    Signed-off-by: Katrin Fischer <[hidden email]>

commit 794061a947f3275ac82e6fc0a168ae44a0af6b28
Author: Fridolin Somers <[hidden email]>
Date:   Wed Jun 14 12:33:25 2017 +0200

    Bug 18756 - add Unit Test
   
    Signed-off-by: Lee Jamison <[hidden email]>
   
    Signed-off-by: Nick Clemens <[hidden email]>
   
    Signed-off-by: Jonathan Druart <[hidden email]>
    (cherry picked from commit 8b15c064405ff4a48cb3f5803dd6bd16d49d5b9b)
    Signed-off-by: Fridolin Somers <[hidden email]>
    (cherry picked from commit 40db2dcc388706b54f13db9c312ee7f181f6bd9b)
    Signed-off-by: Katrin Fischer <[hidden email]>

commit bb179998b47d4d6f3b5674cdfc96508276b341ad
Author: Marcel de Rooy <[hidden email]>
Date:   Thu Jun 22 08:55:16 2017 +0200

    Bug 18214: Add check for shared or public list
   
    Following the idea behind bug 10865, we are only showing the permissions
    when the list is shared or public.
    Adding a simple test in opac-shelves here.
   
    Note 1: Since the owner can always add or delete entries, the permissions
    will not be relevant anymore for a strictly private list.
   
    Note 2: Staff view always shows the permissions. This could have been
    changed here too, but that change is far less urgent (bug 10865 did not
    touch staff view and bug 18228 will rearrange permissions anyway).
   
    Test plan:
    [1] Verify on OPAC that you see the permissions for a private list with
        shares or a public list. And you do not see them for a private list
        without shares.
   
    Signed-off-by: Marcel de Rooy <[hidden email]>
    (cherry picked from commit b494837c8d17a29936e2c2bcc067120c26876855)
    Signed-off-by: Fridolin Somers <[hidden email]>
    (cherry picked from commit f4b6e5963ff3511d54f1af1f66d1fb7c1e2cfb4a)
    Signed-off-by: Katrin Fischer <[hidden email]>

commit cedae4535ba4b91826b4476d109070c847fad160
Author: Marcel de Rooy <[hidden email]>
Date:   Mon Mar 6 09:44:48 2017 +0100

    Bug 18214: Cannot edit list permissions of a private list
   
    If you have disabled the pref OpacAllowPublicListCreation, your users are
    not able to edit the list permissions for private/shared lists.
    For a private list they may only be theoretically relevant, but for a shared
    list they are relevant.
    Since we do not always know the history of a list (has it been public or
    shared, does it contains entries from other users) and therefore permissions
    are even relevant for a currently private list, we should just allow editing
    these permissions.
   
    Test plan:
    [1] Do not yet apply this patch.
    [2] Disable OpacAllowPublicListCreation.
    [3] Create a private list in OPAC. Edit the list. Verify that you do not
        see the permission combo boxes.
    [4] Apply this patch. Edit the list again. Do they appear now?
   
    Signed-off-by: Marcel de Rooy <[hidden email]>
    Signed-off-by: Magnus Enger <[hidden email]>
    Works as advertised.
   
    (cherry picked from commit 3d2eddaf3da3e090d00b4e5823f8f70a70c06ea1)
    Signed-off-by: Fridolin Somers <[hidden email]>
    (cherry picked from commit 306055cd81a8f61cd25025f89bdb5e8d90a33caf)
    Signed-off-by: Katrin Fischer <[hidden email]>

-----------------------------------------------------------------------

Summary of changes:
 C4/Acquisition.pm                                        |    4 ++--
 koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-shelves.tt |    2 ++
 misc/translator/LangInstaller.pm                         |    7 ++++++-
 t/Acquisition/CanUserManageBasket.t                      |    9 ++++++++-
 4 files changed, 18 insertions(+), 4 deletions(-)


hooks/post-receive
--
main Koha release repository
_______________________________________________
koha-commits mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-commits
Loading...