Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Ghost
    @ghost~5b1a499ed73408ce4f9c951e

    Au niveau de l'identification des lecteurs (et du staff), avez-vous prévu de pouvoir vous connecter à un annuaire (LDAP ou active directory) ? J'ai cherché dans les uses cases (Taiga) mais je n'ai pas trouvé.

    Il serait même bien de pouvoir paramétrer un annuaire par organisation.
    C'est une idée en passant... :smile:
    Merci. B.

    Dans ce cadre là, vous pourriez récupérer les données du lecteur depuis l'annuaire LDAP, au lieu de créer un lecteur dans l'interface (même si je comprends l'utilité ici, au début du projet)
    Johnny Mariéthoz
    @jma
    @BenoitErken_twitter Dans d'autres projets nous avons utilisé une authentification oauth, le module correspondant dans Invenio existe déjà: https://github.com/inveniosoftware/invenio-oauthclient. Cela permet par exemple l'utilisation de login extern de type, github, rero, facebook, etc. et de lier ces comptes à un utilisateur de l'ILS par ex. Pour l'instant, je ne vois pas de cas d'utilisation LDAP pour RERO, mais ce ne doit pas être top compliqué à mettre en place le cas échéant.
    @BenoitErken_twitter concernant la question de Docker. Il faut voir ce que vous cherchez à faire. Déployer une version pour développer ou la déployer sur un serveur dédié en vue de la mise en place d'un service. Il est vrai que Docker demande un peu d'apprentissage, mais nous amène beaucoup à moyen, long terme.
    Ghost
    @ghost~5b1a499ed73408ce4f9c951e
    Merci pour le retour !
    :clap:
    Johnny Mariéthoz
    @jma
    @BenoitErken_twitter avec plaisir!
    Ghost
    @ghost~5b1a499ed73408ce4f9c951e

    @jma pour répondre à ta question, nous souhaitons déployer une version pour la mise en place d'un service et le tester en conditions "réelles". Mais dans un premier temps, nous pouvons encore tester avec la formule Docker.

    Au sujet de dojson, avez-vous déjà testé la conversion MARC->JSON de records biblio et des items en même temps ? En théorie, il y a moyen de créer un document JSON qui contient les deux (info book & info item) mais je ne vois pas encore comment faire via le script model.py. Nous allons chercher...

    Dans votre procédure finale, vous comptez migrer tout cela par étape ?
    Ex: charger d'abord tous les bib records (books, serials,...) , ensuite créer tous les items et tous les holdings ? ou alors, vous allez construire des records complets directement (bib+items / bib+holdings) ? avez-vous déjà discuté de cela ? C'est peut être trop tôt... Merci. B. (je ne vous embête plus après)

    iGor milhit
    @iGormilhit
    @BenoitErken_twitter Nous n'avons pas encore réellement un modèle de donnée, il y a un groupe de travail qui planche là-dessus chez nous et nous allons devoir nous y mettre plutôt rapidement... Dans l'état, on n'avait besoin de données minimales pour développer. On a donc sélectionné des bib de livres de manière assez restrictive, planché sur un jsonschema de bib (appelé document dans reroils-data) et écrit le script de migration (reroils_data/dojson/contrib/marc21tojson/model.py), puis on génére des fixtures d'exemplaires (voir https://github.com/rero/reroils-data/blob/master/reroils_data/documents_items/cli.py.
    @BenoitErken_twitter Oups, j'ai tapé sur enter trop tôt! :)

    @BenoitErken_twitter Ensuite les items sont injectés dans les bib avant indexation, afin de les lier.

    Mais c'est tout à fait provisoire, bien entendu. Il faudra que nous ayons des bib, des holdings et des items, et que nous soyons en mesure de faire des migrations complètes.

    Ghost
    @ghost~5b1a499ed73408ce4f9c951e

    Salut l'équipe,

    Nous avons chargé 5000 records biblio UCL dans notre instance Invenio. Ils sont visibles dans l'interface (via l'URL et le documentID) mais une recherche ne retourne rien.

    Après le chargement, nous avons lancé les commandes pour mettre les records dans la queue d'indexation et pour traiter la queue. (OK)

    Au niveau d'ElasticSearch, les documents sont indexés. Je vois les données et je peux lancer une recherche via une commande curl.

    Question: au niveau de l'interface Invenio, y a t-il un filtre lors de la recherche ? ex: une condition/un filtre qu'il applique à la recherche mais que nous n'avons pas mis dans nos documents JSON ?

    iGor milhit
    @iGormilhit

    @BenoitErken_twitter Non, à ma connaissance nous n'avons pas de filtre. On a des vues qui affichent des index différents selon les types de record (dans reroils_app/config.py, les RECORDS_UI_ENDPOINTS).

    Lors de l'indexation, vous avez indiqué un type de record ? invenio index reindex --pid-type doc par exemple ? Et quand vous dites que les records sont accessibles via l'URL, c'est de quelle URL qu'il s'agit ?

    Ghost
    @ghost~5b1a499ed73408ce4f9c951e
    oui nous avons indiqué le type "doc" lors de l'indexation.

    au niveau des records accessibles via leur URL, c'est par exemple ceci:
    http://monsiteinvenio:5000/documents/1234

    Ca fonctionne... Nous voyons le record 1234 mais la recherche ne retourne pas (encore) de résultat.
    Soit, nous allons trouver le problème :clap:
    Merci pour les infos.
    B.

    Johnny Mariéthoz
    @jma
    Ghost
    @ghost~5b1a499ed73408ce4f9c951e

    hello

    http://.../api/documents/1234 => message "You don't have the permission to access the requested resource"

    http://.../api/documents/?q=Homeopathy => réponse JSON, avec "Hits : 0".

    J'ai sans doute fait une erreur dans la procédure de chargement/conversion. Je cherche.
    Merci,
    B.

    Ghost
    @ghost~5b1a499ed73408ce4f9c951e

    OK nos documents sont indexés. (j'avais modifié le schéma book-v0.0.1.json ... et il n'a pas aimé) .

    Par contre, nous avons ajouté des nouveaux codes langues dans le schéma, afin que nos documents "tests" soient valides.

    Pour résumer:

    • nous ajoutons des codes langues dans le schéma. OK
    • nous devons modifier un mapping quelque part pour afficher les nouvelles langues dans la facette. Pour l'instant, ce sont les codes qui s'affichent (pol, dut,...)
    • pour finir, il faut modifier les traductions pour afficher l'intitulé des langues en français, en anglais etc...

    Est-ce exact ?
    Merci. B.

    iGor milhit
    @iGormilhit
    @BenoitErken_twitter À mon avis le mapping et la configuration des facettes font déjà ce qu'il faut. Si les nouveaux codes s'affichent, c'est bien le cas. Reste la traduction, que l'on fait chez nous via transifex. Il y a une ébauche de doc à ce sujet sur le wiki: https://github.com/rero/reroils-app/wiki/Translation
    Ghost
    @ghost~5b1a499ed73408ce4f9c951e

    @iGormilhit Les traductions seront toujours centralisées/gérées par RERO (dans Transifex) ? ou alors, à terme, chaque utilisateur d'Invenio pourra adapter les traductions pour son interface, et lier cela à son site Invenio ? Je ne vois pas encore comment cela va se passer.

    Et voilà une autre question: y a t-il moyen d'utiliser des API REST d'Invenio pour ajouter des données (biblio, exemplaires,...), via des commandes curl par exemple ?

    J'ai trouvé la documentation sur un module "invenio-records-rest" mais pour la version 1. ( https://invenio-records-rest.readthedocs.io/en/latest/ )
    Merci.

    Johnny Mariéthoz
    @jma
    @BenoitErken_twitter pour les traductions du contenu des facettes de langue, regarde ici: https://github.com/rero/reroils-app/blob/master/reroils_app/manual_translations.txt le problème est comment traduire des chaînes qui ne sont ni dans le html ni dans le code python!
    Pour le REST oui c'est bien ìnvenio-records-rest`. Mais il faut adapter les premissions: https://invenio-records-rest.readthedocs.io/en/latest/usage.html#access-control après avoir ajusté les permissions, les méthodes GET, PUT, POST et DELETE doivent fonctionner avec http://localhost:5000/api/documents/4 par ex.
    Ghost
    @ghost~5b1a499ed73408ce4f9c951e
    Merci. :+1:
    Ghost
    @ghost~5b1a499ed73408ce4f9c951e
    Bonjour l'équipe,
    nous avons un problème pour accéder à l'interface du prêt (Circulation). Le browser affiche le message "Loading..." et une page blanche. En fait, il n'arrive pas accéder à l'URL ".../patrons/logged_user" (404 - Not found). Vous avez le même comportement sur ils.test.rero.ch
    Avez-vous une idée pour ce problème ?
    (nous utilisons le login "admin" pour le moment)
    Merci,
    Benoit
    Aly Badr
    @BadrAly
    Salut Benoit,
    J’espère que tout va bien.
    Il ne faut pas utiliser le login "admin" pour les fonctionnalités professionnelles (circulation, catalogage, etc.).
    Actuellement, les utilisateurs ayant les rôles “staff" et “cataloguer" peuvent avoir accès à la circulation/catalogage.
    Pour voir la liste des utilisateurs actuellement configurés, voir le menu “Administrer", puis “Utilisateurs"
    Veuillez consulter les fichiers suivants, pour plus d'informations:
    Configurations d’utilisateurs : reroils_data/data/users.json
    Chargements d'utilisateurs : reroils-app/deployment/populate.sh (ligne #45)
    Ghost
    @ghost~5b1a499ed73408ce4f9c951e
    Merci Aly.
    sinux334
    @sinux334
    Hello. I just wanted to get some insights in actual rero-ils and wondered that the distributed dockerfile calls for rero-ils-base:latest which isn't available through dockerhub. If I follow install.rst the proposed Dockerfile is calling for rero/rero-ils:dev which isn't available. Am I doing something wrong? regards, simon
    Johnny Mariéthoz
    @jma
    @sinux334 we are refactoring the rero-ils application to be more invenio compliant. We will release it probably in two or three weeks. In the meantime, you can try the current master from github: https://github.com/rero/rero-ils, but the documentation is not uptodate. See the PR: rero/rero-ils#74 for more details.
    sinux334
    @sinux334
    @jma ok, thank you!
    Ghost
    @ghost~5b1a499ed73408ce4f9c951e
    Hi guys,
    We have installed the release 0.23 of RERO-ils.
    In the circulation module, when we checkout a book, the system calculates the "due_date" using the params defined in our cipo.
    It's works well for the date but, by default, it takes the time of the transaction.
    Example:
    we define a checkout of 3 days in the CIPO
    We do a checkout this morning at 10:00. The system fixes the due date at today + 3days = 2019-08-03 10:00
    it depends of the institution but we think it's better to let the patron checkin the book before the end of the day no ?
    To fix this on our side, in ext.py, we have used the signal "before_record_update" to change the time of the due_date.
    So now, we do a checkout and the due date is set at now + 3days = 2019-08-03 23:59
    By default, the system could use the closing time defined for the library settings, or a default value (let's say 23h59)
    What do you think ?
    Ben
    Nicolas Prongué
    @pronguen

    Hi Benoit

    it depends of the institution but we think it's better to let the patron checkin the book before the end of the day no ?

    Yes absolutely. We may have an option "Checkout 1 hour" later, but now the standard behaviour should be checkout X days, for the end of the day.

    @BadrAly Should we open an issue?

    Aly Badr
    @BadrAly
    @pronguen Yes please, an issue to fix this.
    You may also consider this as an optional library parameter. Something like:
    Items due at closing day -> True | False
    Ghost
    @ghost~5b1a499ed73408ce4f9c951e
    OK. Thank you.
    Nicolas Prongué
    @pronguen
    rero/rero-ils#417 created, thank you!
    Dubois Laurent
    @itld_solutions_twitter
    Hi,
    it's definitely not the best way but we do a workaround using signal "before_record_update" and connect custom function like :
    def change_loan_end_date(json=None, record=None):
        """Signal before a record is updated."""
    
        """check record type."""
        if record.get('loan_pid', None):
          """fix hour to 23h59."""
          end_date = ciso8601.parse_datetime_as_naive(record.get('end_date'))
          calculated_end_date = end_date.replace(hour=23, minute=59)
          record['end_date'] = calculated_end_date.isoformat()
    Aly Badr
    @BadrAly
    @itld_solutions_twitter Hello Laurent, this is just to let you know that we’re (the dev team) discussing a solution, other than signal before_record_update, for bringing forward the due_dates to the end of the day as requested. We will get back to you soon.
    Aly Badr
    @BadrAly

    Hello @itld_solutions_twitter and @BenoitErken_twitter:

    We have created three pull requests to address the issue of the due date:

    1. invenio-circulation: inveniosoftware/invenio-circulation#117
      changes loan duration from a number of days as int to timedelta (version 1.0.0a16)

    2. rero-ils: rero/rero-ils#436
      upgrades rero-ils to invenio-circulation version 1.0.0a16

    3. rero-ils: rero/rero-ils#440
      adapts the hours of checkouts and renewals due dates to 23:59

    You can enjoy this new feature once these pull requests are merged.

    Ghost
    @ghost~5b1a499ed73408ce4f9c951e
    Thank you @BadrAly
    Mana Deweerdt
    @ManaDeweerdt_twitter
    Hi all, we have a question for the renewal functionality.
    It seems for now that when we click on "extend_loan", the renewal is calculated from today's date and not from the due date. Is it correct?
    If it is so, when a user make a renewal 2 weeks before the due date, the new due date will be very short.
    Ex: renewal duration = 14d. Due date = 26/08. Renewal on 21/08 >> New due date = 4/09 (in place of 9/09).
    It would be nice if we could define the number of days before a user can renew the loan. Ex: 4d before the due date.
    Ghost
    @ghost~5b1a499ed73408ce4f9c951e
    [joke] hey @ManaDeweerdt_twitter... don't bother them with circulation trivialities :-))))
    iGor milhit
    @iGormilhit
    @ManaDeweerdt_twitter You're right.
    In config.py, there's a way to set the new due date from the current due date or form the renewal date. You're proposition makes sense, but we have to talk about it with the product owner side of our team... :slight_smile:

    [joke] hey @ManaDeweerdt_twitter... don't bother them with circulation trivialities :-))))

    It seems that we already had discussions about it, quite some time ago... :smiley:

    Mana Deweerdt
    @ManaDeweerdt_twitter
    ;-)
    Renaud Michotte
    @zannkukai
    @pronguen @BadrAly Bonjour Nicolas, Bonjour Ali.
    Ce matin je me suis attelé à la micro tâche #1012 (Clean way to add a default currency). En en reparlant avec Laurent et Benoit, Benoit à soulever un point intéressant.
    Pour le moment, on a défini une currency par défaut dans la configuration générale. Il serait sans doute plus judicieux de définir ce champ dans la description d'une organisation (à priori, toutes les libraries d'une organisation devraient utiliser le même système monétaire). Cela permettrait également à un gestionnaire de pouvoir modifier cette valeur via une interface admin (actuellement la currency par défaut est définie dans le config général de l'application).
    On se trompe ou pas ?
    Si on ne se trompe pas, Il faudrait peut être rajouter cela dans une tâche soit pour ce sprint, soit pour un futur sprint (je pense qu'on pourrait faire cela en interne à l'UCL avec @BadrAly en soutien si nécessaire si biensur il est d'accord).
    Nicolas Prongué
    @pronguen
    Bonjour @zannkukai
    Après un bref échange avec Aly, ta proposition nous semble pertinente. Peut-on modifier la tâche actuelle 1012 dans ce sens?
    Renaud Michotte
    @zannkukai
    @pronguen on peut tout à fait :-) ce sera juste plus long que mes 3 lignes de codes actuelles mais bien plus intéressant pour se mettre dans le bain ;-)
    Aly Badr
    @BadrAly
    @zannkukai Peter, Gianni ou moi serons disponibles en cas de besoin.
    chrswk
    @chrswk

    Hi. We are a RFID provider for Rero/Virtua libraries and have tried to contact the reroils project via the info@ email but never got a reply. We would like to ask regarding:

    1) The integration of our RFID REST-API to checkout/checkin items via RFID in your webapp. We are more than happy to provide you with a devkit including hardware and tags
    2) Your plans for SIP2 or NCIP APIs, which are the de facto standard for self-check/book return, etc. systems to interact with a LMS

    Any change someone can get in contact with me here or via email at devteam@infomedis.ch? Thanks!

    iGor milhit
    @iGormilhit
    Hi @chrswk, thanks for reaching us. Sorry for the absence of answer to your precedent email. We're going to sent to you an email soon. Thanks for your patience!
    chrswk
    @chrswk
    No problem, thanks in advance