From alberto.martin at bitergia.com Tue Feb 2 13:01:44 2016 From: alberto.martin at bitergia.com (=?UTF-8?Q?Alberto_Mart=C3=ADn_Casado?=) Date: Tue, 2 Feb 2016 13:01:44 +0100 Subject: [Fiware-developer-experience] New dudes about the tour guide. In-Reply-To: References: Message-ID: Hi all! Getting back to the previous e-mails, we've done several implementations based on the feedback provided. The main changes are: * Provide reviews id at the review body. The id now is provided under the field "name" (NOTE that the schema to POST reviews has changed) * Regarding reservations and Occupancy: - Added additionalProperties "capacity" and "occupancyLevels" at every Restaurant (NOTE that the schema to POST restaurants has changed) - Provided a new Route [1] that given a Restaurant and a date, returns the Restaurant with the occupancyLevels at that time (it calculates the reservations from -2 hours of the given date). - Provided a new Route [2] that retrieves all the reservations between the dates provided (params "from" and "to") All the changes are reflected in Apiary and the documentation is updated. Let us know if you have any doubts. Best! Alberto Mart?n [1]: http://docs.tourguide.apiary.io/#reference/api-especification-for-tourguide/restaurant/get-restaurant-with-a-given-date [2]: http://docs.tourguide.apiary.io/#reference/api-especification-for-tourguide/reservation/list-reservations-by-restaurant-and-date On Wed, Jan 20, 2016 at 3:58 PM, Jaisiel Santana wrote: > Hi! > > thanks for you response. We will be waiting for your decisions before > continue with these working lines. > > > Regards, > > Jaisiel Santana. > > On Wed, Jan 20, 2016 at 11:31 AM, Alberto Mart?n Casado < > alberto.martin at bitergia.com> wrote: > >> Hi! >> >> Comments inline. >> >> On Wed, Jan 20, 2016 at 11:03 AM, Jaisiel Santana >> wrote: >> >>> Hi! >>> >>> We are updating the client of the tour guide and some questions have >>> arisen. We would appreciate if you can answer it. >>> >>> >>> - >>> >>> We found that the API allows to write more than one review per user >>> about the same restaurant. Is this behaviour correct? >>> >>> >> Yes. We conclude that a user can go to a restaurant once, twice or more >> times; and the service each time can be different, so we let the reviews >> open to more than one. >> >> >>> >>> - >>> >>> If we retrieve a set of reviews, the ids are not listed. We need >>> them to update or delete reviews, we also noticed that they are not >>> specified in the responses located in the API specification. >>> >>> For example, if we request for: >>> http://compose_devguide_1/api/orion/reviews/restaurant/Ondalan we get: >>> >>> >>> [ >>> >>> { >>> >>> "@context": "http://schema.org", >>> >>> "@type": "Review", >>> >>> "author": >>> >>> { >>> >>> "name": "user5", >>> >>> "@type": "Person" >>> >>> }, >>> >>> "itemReviewed": >>> >>> { >>> >>> "name": "Ondalan", >>> >>> "@type": "Restaurant" >>> >>> }, >>> >>> "name": "Rating description", >>> >>> "publisher": >>> >>> { >>> >>> "name": "Bitergia", >>> >>> "@type": "Organization" >>> >>> }, >>> >>> "reviewBody": "Body review", >>> >>> "reviewRating": >>> >>> { >>> >>> "ratingValue": 4, >>> >>> "@type": "Rating" >>> >>> } >>> >>> } >>> >>> ] >>> >> >> True. Actually the 'id' field it's a field that breaks the Review schema >> in schema.org, that's why we did not add it. I'll have a look again to >> try to find a way to add it in every review response (as in Orion it's >> already there but not being displayed in our API). >> >> >>> >>> >>> - >>> >>> Have you considered to add restrictions to make reservations? >>> (number of commensals, schedule ,maximum of reservations...) In that case, >>> how can we retrieve this information? >>> >>> >> Reservations are restricted already. The procedure we've follow is: >> >> - Everytime a user try to create a reservation, the application >> calculates how many reservations has been done in the previous 2 hours of >> the time we want to reserve a table. >> - If there's enough space, the reservation can be done; and if not, is >> discarded. >> >> We have a script to update that information into the restaurants: >> https://github.com/Fiware/tutorials.TourGuide-App/tree/master/server/feeders#occupancy-updater >> >> We are still thinking on how to 'automate' this occupancy levels into the >> restaurants (as I guess is the information you need). >> >> Also, we can discuss on how can we display this information and what's >> better for the client side, so we can talk a bit deeper about it to match >> your requirements. >> >> >>> >>> - >>> >>> We can?t access to the API specification in Apiary ( >>> http://docs.devguide.apiary.io/#reference/api-especification-for-devguide/). >>> We suppose that the project name has been changed according to the new >>> nomenclature. Can you provide us the new url? >>> >>> >>> >> Yes, sorry. I've updated in the repository thinking that it would work as >> github does (doing redirections) but seems not. It has been changed from >> 'devguide' to 'tourguide': http://docs.tourguide.apiary.io/. Sorry for >> the inconvenience! >> >> >>> >>> Regards, >>> -- >>> Jaisiel Santana. >>> >>> _______________________________________________ >>> Fiware-developer-experience mailing list >>> Fiware-developer-experience at lists.fiware.org >>> https://lists.fiware.org/listinfo/fiware-developer-experience >>> >>> >> Best, >> >> >> Alberto Mart?n >> >> > > _______________________________________________ > Fiware-developer-experience mailing list > Fiware-developer-experience at lists.fiware.org > https://lists.fiware.org/listinfo/fiware-developer-experience > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pablofernandezmoniz at gmail.com Fri Feb 5 11:57:04 2016 From: pablofernandezmoniz at gmail.com (=?UTF-8?Q?Pablo_Fern=C3=A1ndez_Moniz?=) Date: Fri, 5 Feb 2016 10:57:04 +0000 Subject: [Fiware-developer-experience] IdM callback URL issue Message-ID: Hello, we are working to introduce the changes related to occupancy levels and reviews identifiers and we have found that we cannot log in on the app using IdM after retrieving the last modifications [idm_error.tiff]. We think that it occurs because the url and the callback url are set to localhost instead of the tourguide host [idm_localhost.tiff]. During installation we noticed that the tourguide_1 failed to retrieve the file '/config/idm2chanchan.json' [failed_to_retrieve_idm2chanchan.json.tiff] We don't discard that the issue is related to the refactoring process but we have revised our code and didn't find evidences of it. We have pushed our code to the branch fix/client_login_idm so you can reproduce the error by yourself. Do you have any suggestion about what is causing this error? Regards, FIWARE ULPGC team. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: idm_localhost.tiff Type: image/tiff Size: 103994 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: failed_to_retrieve_idm2chanchan.json.tiff Type: image/tiff Size: 1022148 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: idm_error.tiff Type: image/tiff Size: 291382 bytes Desc: not available URL: From alberto.martin at bitergia.com Mon Feb 8 13:00:03 2016 From: alberto.martin at bitergia.com (=?UTF-8?Q?Alberto_Mart=C3=ADn_Casado?=) Date: Mon, 8 Feb 2016 13:00:03 +0100 Subject: [Fiware-developer-experience] IdM callback URL issue In-Reply-To: References: Message-ID: Hi Pablo, I've been testing and I could not reproduce the issue right now, but it happened to me once if I remember well. The script that generates the 'idm2chanchan.json' was not able to access the database, which could cause the issue. Probably is a timing issue due to the synchronization of all the containers. We will have a look at it. Still, if you remove the containers and try to generate them again, probably you will be able to run tourguide normally (if you are working with volumes you should not lose any changes). Sorry for the inconvenience! Best, Alberto Mart?n On Fri, Feb 5, 2016 at 11:57 AM, Pablo Fern?ndez Moniz < pablofernandezmoniz at gmail.com> wrote: > Hello, > > we are working to introduce the changes related to occupancy levels and > reviews identifiers and we have found that we cannot log in on the app > using IdM after retrieving the last modifications [idm_error.tiff]. We > think that it occurs because the url and the callback url are set to > localhost instead of the tourguide host [idm_localhost.tiff]. > > During installation we noticed that the tourguide_1 failed to retrieve the > file '/config/idm2chanchan.json' [failed_to_retrieve_idm2chanchan.json.tiff] > > We don't discard that the issue is related to the refactoring process but > we have revised our code and didn't find evidences of it. We have pushed > our code to the branch fix/client_login_idm so you can reproduce the error > by yourself. > > Do you have any suggestion about what is causing this error? > > > Regards, > > FIWARE ULPGC team. > > _______________________________________________ > Fiware-developer-experience mailing list > Fiware-developer-experience at lists.fiware.org > https://lists.fiware.org/listinfo/fiware-developer-experience > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaisiel at gmail.com Tue Feb 9 11:22:48 2016 From: jaisiel at gmail.com (Jaisiel Santana) Date: Tue, 9 Feb 2016 10:22:48 +0000 Subject: [Fiware-developer-experience] IdM callback URL issue In-Reply-To: References: Message-ID: Hi! we have tried to generate all the containers again (even from the scratch using a new machine) and we have obtained the same error. We are using Ubuntu 14.04, Docker 1.8.3 and docker-compose 1.4.2. Which configuration are you using? Thanks, ULPGC team. On Mon, Feb 8, 2016 at 12:00 PM, Alberto Mart?n Casado < alberto.martin at bitergia.com> wrote: > Hi Pablo, > > I've been testing and I could not reproduce the issue right now, but it > happened to me once if I remember well. The script that generates the > 'idm2chanchan.json' was not able to access the database, which could cause > the issue. Probably is a timing issue due to the synchronization of all the > containers. We will have a look at it. > > Still, if you remove the containers and try to generate them again, > probably you will be able to run tourguide normally (if you are working > with volumes you should not lose any changes). > > Sorry for the inconvenience! > > Best, > > > Alberto Mart?n > > On Fri, Feb 5, 2016 at 11:57 AM, Pablo Fern?ndez Moniz < > pablofernandezmoniz at gmail.com> wrote: > >> Hello, >> >> we are working to introduce the changes related to occupancy levels and >> reviews identifiers and we have found that we cannot log in on the app >> using IdM after retrieving the last modifications [idm_error.tiff]. We >> think that it occurs because the url and the callback url are set to >> localhost instead of the tourguide host [idm_localhost.tiff]. >> >> During installation we noticed that the tourguide_1 failed to retrieve >> the file '/config/idm2chanchan.json' >> [failed_to_retrieve_idm2chanchan.json.tiff] >> >> We don't discard that the issue is related to the refactoring process but >> we have revised our code and didn't find evidences of it. We have pushed >> our code to the branch fix/client_login_idm so you can reproduce the error >> by yourself. >> >> Do you have any suggestion about what is causing this error? >> >> >> Regards, >> >> FIWARE ULPGC team. >> >> _______________________________________________ >> Fiware-developer-experience mailing list >> Fiware-developer-experience at lists.fiware.org >> https://lists.fiware.org/listinfo/fiware-developer-experience >> >> > > _______________________________________________ > Fiware-developer-experience mailing list > Fiware-developer-experience at lists.fiware.org > https://lists.fiware.org/listinfo/fiware-developer-experience > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alberto.martin at bitergia.com Tue Feb 9 11:52:00 2016 From: alberto.martin at bitergia.com (=?UTF-8?Q?Alberto_Mart=C3=ADn_Casado?=) Date: Tue, 9 Feb 2016 11:52:00 +0100 Subject: [Fiware-developer-experience] IdM callback URL issue In-Reply-To: References: Message-ID: Hi! That's really strange... I'm using Debian GNU/Linux 8.1 (jessie), Docker version 1.9.1, build a34a1d5 and docker-compose version 1.5.2, build 7240ff3. In Travis tests works well also (pointing to your branch): https://travis-ci.org/Fiware/tutorials.TourGuide-App/builds/107204432 There's been a release of a new version of Keyrock, and we are also about to upgrade it, but nothing should change for the client. We will let you know as soon as its ready, just in case you could not fix the issue. Best! Alberto Mart?n On Tue, Feb 9, 2016 at 11:22 AM, Jaisiel Santana wrote: > Hi! > > we have tried to generate all the containers again (even from the scratch > using a new machine) and we have obtained the same error. > > We are using Ubuntu 14.04, Docker 1.8.3 and docker-compose 1.4.2. > > Which configuration are you using? > > > Thanks, > > ULPGC team. > > > On Mon, Feb 8, 2016 at 12:00 PM, Alberto Mart?n Casado < > alberto.martin at bitergia.com> wrote: > >> Hi Pablo, >> >> I've been testing and I could not reproduce the issue right now, but it >> happened to me once if I remember well. The script that generates the >> 'idm2chanchan.json' was not able to access the database, which could cause >> the issue. Probably is a timing issue due to the synchronization of all the >> containers. We will have a look at it. >> >> Still, if you remove the containers and try to generate them again, >> probably you will be able to run tourguide normally (if you are working >> with volumes you should not lose any changes). >> >> Sorry for the inconvenience! >> >> Best, >> >> >> Alberto Mart?n >> >> On Fri, Feb 5, 2016 at 11:57 AM, Pablo Fern?ndez Moniz < >> pablofernandezmoniz at gmail.com> wrote: >> >>> Hello, >>> >>> we are working to introduce the changes related to occupancy levels and >>> reviews identifiers and we have found that we cannot log in on the app >>> using IdM after retrieving the last modifications [idm_error.tiff]. We >>> think that it occurs because the url and the callback url are set to >>> localhost instead of the tourguide host [idm_localhost.tiff]. >>> >>> During installation we noticed that the tourguide_1 failed to retrieve >>> the file '/config/idm2chanchan.json' >>> [failed_to_retrieve_idm2chanchan.json.tiff] >>> >>> We don't discard that the issue is related to the refactoring process >>> but we have revised our code and didn't find evidences of it. We have >>> pushed our code to the branch fix/client_login_idm so you can reproduce >>> the error by yourself. >>> >>> Do you have any suggestion about what is causing this error? >>> >>> >>> Regards, >>> >>> FIWARE ULPGC team. >>> >>> _______________________________________________ >>> Fiware-developer-experience mailing list >>> Fiware-developer-experience at lists.fiware.org >>> https://lists.fiware.org/listinfo/fiware-developer-experience >>> >>> >> >> _______________________________________________ >> Fiware-developer-experience mailing list >> Fiware-developer-experience at lists.fiware.org >> https://lists.fiware.org/listinfo/fiware-developer-experience >> >> > > _______________________________________________ > Fiware-developer-experience mailing list > Fiware-developer-experience at lists.fiware.org > https://lists.fiware.org/listinfo/fiware-developer-experience > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alberto.martin at bitergia.com Wed Feb 10 14:03:51 2016 From: alberto.martin at bitergia.com (=?UTF-8?Q?Alberto_Mart=C3=ADn_Casado?=) Date: Wed, 10 Feb 2016 14:03:51 +0100 Subject: [Fiware-developer-experience] IdM callback URL issue In-Reply-To: References: Message-ID: Hi again! As I said yesterday, we've updated the Keyrock image to the 5.1.0 version. We've also made some adjustments in the timing synchronization of the Keyrock image, so hopefully the error you were getting is completely gone. Please, let us know if the error still appears. Best! Alberto Mart?n On Tue, Feb 9, 2016 at 11:52 AM, Alberto Mart?n Casado < alberto.martin at bitergia.com> wrote: > Hi! > > That's really strange... I'm using Debian GNU/Linux 8.1 (jessie), Docker > version 1.9.1, build a34a1d5 and docker-compose version 1.5.2, build > 7240ff3. > > In Travis tests works well also (pointing to your branch): > https://travis-ci.org/Fiware/tutorials.TourGuide-App/builds/107204432 > > There's been a release of a new version of Keyrock, and we are also about > to upgrade it, but nothing should change for the client. We will let you > know as soon as its ready, just in case you could not fix the issue. > > Best! > > > Alberto Mart?n > > On Tue, Feb 9, 2016 at 11:22 AM, Jaisiel Santana > wrote: > >> Hi! >> >> we have tried to generate all the containers again (even from the scratch >> using a new machine) and we have obtained the same error. >> >> We are using Ubuntu 14.04, Docker 1.8.3 and docker-compose 1.4.2. >> >> Which configuration are you using? >> >> >> Thanks, >> >> ULPGC team. >> >> >> On Mon, Feb 8, 2016 at 12:00 PM, Alberto Mart?n Casado < >> alberto.martin at bitergia.com> wrote: >> >>> Hi Pablo, >>> >>> I've been testing and I could not reproduce the issue right now, but it >>> happened to me once if I remember well. The script that generates the >>> 'idm2chanchan.json' was not able to access the database, which could cause >>> the issue. Probably is a timing issue due to the synchronization of all the >>> containers. We will have a look at it. >>> >>> Still, if you remove the containers and try to generate them again, >>> probably you will be able to run tourguide normally (if you are working >>> with volumes you should not lose any changes). >>> >>> Sorry for the inconvenience! >>> >>> Best, >>> >>> >>> Alberto Mart?n >>> >>> On Fri, Feb 5, 2016 at 11:57 AM, Pablo Fern?ndez Moniz < >>> pablofernandezmoniz at gmail.com> wrote: >>> >>>> Hello, >>>> >>>> we are working to introduce the changes related to occupancy levels and >>>> reviews identifiers and we have found that we cannot log in on the app >>>> using IdM after retrieving the last modifications [idm_error.tiff]. We >>>> think that it occurs because the url and the callback url are set to >>>> localhost instead of the tourguide host [idm_localhost.tiff]. >>>> >>>> During installation we noticed that the tourguide_1 failed to retrieve >>>> the file '/config/idm2chanchan.json' >>>> [failed_to_retrieve_idm2chanchan.json.tiff] >>>> >>>> We don't discard that the issue is related to the refactoring process >>>> but we have revised our code and didn't find evidences of it. We have >>>> pushed our code to the branch fix/client_login_idm so you can reproduce >>>> the error by yourself. >>>> >>>> Do you have any suggestion about what is causing this error? >>>> >>>> >>>> Regards, >>>> >>>> FIWARE ULPGC team. >>>> >>>> _______________________________________________ >>>> Fiware-developer-experience mailing list >>>> Fiware-developer-experience at lists.fiware.org >>>> https://lists.fiware.org/listinfo/fiware-developer-experience >>>> >>>> >>> >>> _______________________________________________ >>> Fiware-developer-experience mailing list >>> Fiware-developer-experience at lists.fiware.org >>> https://lists.fiware.org/listinfo/fiware-developer-experience >>> >>> >> >> _______________________________________________ >> Fiware-developer-experience mailing list >> Fiware-developer-experience at lists.fiware.org >> https://lists.fiware.org/listinfo/fiware-developer-experience >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaisiel at gmail.com Thu Feb 11 10:27:01 2016 From: jaisiel at gmail.com (Jaisiel Santana) Date: Thu, 11 Feb 2016 09:27:01 +0000 Subject: [Fiware-developer-experience] IdM callback URL issue In-Reply-To: References: Message-ID: Hi! we have rebuilt the containers and the same error still appears. We made a fork of the project and we could replicate the error in Travis-ci https://travis-ci.org/FiwareULPGC/fiware-devguide-app/jobs/108481783#L1124 In order to replicate the error we replace in .travis.yml: * - cd $TEST_DIR && npm install && npm test* by - *cd $COMPOSE_DIR && docker-compose -f docker-compose.yml up* We are really thankful for your assist and if you need to clarify something, don't hesitate to contact us. FIWARE ULPGC team. Jaisiel Santana. On Wed, Feb 10, 2016 at 1:03 PM, Alberto Mart?n Casado < alberto.martin at bitergia.com> wrote: > Hi again! > > As I said yesterday, we've updated the Keyrock image to the 5.1.0 version. > We've also made some adjustments in the timing synchronization of the > Keyrock image, so hopefully the error you were getting is completely gone. > > Please, let us know if the error still appears. > > Best! > > > Alberto Mart?n > > > On Tue, Feb 9, 2016 at 11:52 AM, Alberto Mart?n Casado < > alberto.martin at bitergia.com> wrote: > >> Hi! >> >> That's really strange... I'm using Debian GNU/Linux 8.1 (jessie), Docker >> version 1.9.1, build a34a1d5 and docker-compose version 1.5.2, build >> 7240ff3. >> >> In Travis tests works well also (pointing to your branch): >> https://travis-ci.org/Fiware/tutorials.TourGuide-App/builds/107204432 >> >> There's been a release of a new version of Keyrock, and we are also about >> to upgrade it, but nothing should change for the client. We will let you >> know as soon as its ready, just in case you could not fix the issue. >> >> Best! >> >> >> Alberto Mart?n >> >> On Tue, Feb 9, 2016 at 11:22 AM, Jaisiel Santana >> wrote: >> >>> Hi! >>> >>> we have tried to generate all the containers again (even from the >>> scratch using a new machine) and we have obtained the same error. >>> >>> We are using Ubuntu 14.04, Docker 1.8.3 and docker-compose 1.4.2. >>> >>> Which configuration are you using? >>> >>> >>> Thanks, >>> >>> ULPGC team. >>> >>> >>> On Mon, Feb 8, 2016 at 12:00 PM, Alberto Mart?n Casado < >>> alberto.martin at bitergia.com> wrote: >>> >>>> Hi Pablo, >>>> >>>> I've been testing and I could not reproduce the issue right now, but it >>>> happened to me once if I remember well. The script that generates the >>>> 'idm2chanchan.json' was not able to access the database, which could cause >>>> the issue. Probably is a timing issue due to the synchronization of all the >>>> containers. We will have a look at it. >>>> >>>> Still, if you remove the containers and try to generate them again, >>>> probably you will be able to run tourguide normally (if you are working >>>> with volumes you should not lose any changes). >>>> >>>> Sorry for the inconvenience! >>>> >>>> Best, >>>> >>>> >>>> Alberto Mart?n >>>> >>>> On Fri, Feb 5, 2016 at 11:57 AM, Pablo Fern?ndez Moniz < >>>> pablofernandezmoniz at gmail.com> wrote: >>>> >>>>> Hello, >>>>> >>>>> we are working to introduce the changes related to occupancy levels >>>>> and reviews identifiers and we have found that we cannot log in on the app >>>>> using IdM after retrieving the last modifications [idm_error.tiff]. We >>>>> think that it occurs because the url and the callback url are set to >>>>> localhost instead of the tourguide host [idm_localhost.tiff]. >>>>> >>>>> During installation we noticed that the tourguide_1 failed to retrieve >>>>> the file '/config/idm2chanchan.json' >>>>> [failed_to_retrieve_idm2chanchan.json.tiff] >>>>> >>>>> We don't discard that the issue is related to the refactoring process >>>>> but we have revised our code and didn't find evidences of it. We have >>>>> pushed our code to the branch fix/client_login_idm so you can reproduce >>>>> the error by yourself. >>>>> >>>>> Do you have any suggestion about what is causing this error? >>>>> >>>>> >>>>> Regards, >>>>> >>>>> FIWARE ULPGC team. >>>>> >>>>> _______________________________________________ >>>>> Fiware-developer-experience mailing list >>>>> Fiware-developer-experience at lists.fiware.org >>>>> https://lists.fiware.org/listinfo/fiware-developer-experience >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Fiware-developer-experience mailing list >>>> Fiware-developer-experience at lists.fiware.org >>>> https://lists.fiware.org/listinfo/fiware-developer-experience >>>> >>>> >>> >>> _______________________________________________ >>> Fiware-developer-experience mailing list >>> Fiware-developer-experience at lists.fiware.org >>> https://lists.fiware.org/listinfo/fiware-developer-experience >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alberto.martin at bitergia.com Thu Feb 11 11:14:17 2016 From: alberto.martin at bitergia.com (=?UTF-8?Q?Alberto_Mart=C3=ADn_Casado?=) Date: Thu, 11 Feb 2016 11:14:17 +0100 Subject: [Fiware-developer-experience] IdM callback URL issue In-Reply-To: References: Message-ID: Hi Jaisiel! The fork you've made from TourGuide is one commit [1] behind master. Due to the Keyrock image upgrade, the users, roles and permissions provision script has changed a bit in Tourguide, and that's why you are getting the error. Please, sync your fork with master and everything will be gone :) Also, I would not change that in Travis. 'Npm test' runs a script that, in order to avoid errors, first pulls all the images and then generate the containers; by running directly 'docker-compose -f docker-compose.yml up', it will pull and generate the containers at the same time, and it may generate synchronization issues. Let me know how it goes. Best! Alberto Mart?n [1]: https://github.com/Fiware/tutorials.TourGuide-App/commit/b482d2cd1bbd6a39984568376b566a5c0930f150 On Thu, Feb 11, 2016 at 10:27 AM, Jaisiel Santana wrote: > Hi! > > we have rebuilt the containers and the same error still appears. We made a > fork of the project and we could replicate the error in Travis-ci > > https://travis-ci.org/FiwareULPGC/fiware-devguide-app/jobs/108481783#L1124 > > In order to replicate the error we replace in .travis.yml: > > * - cd $TEST_DIR && npm install && npm test* > > by > > - *cd $COMPOSE_DIR && docker-compose -f docker-compose.yml up* > > > We are really thankful for your assist and if you need to clarify > something, don't hesitate to contact us. > > FIWARE ULPGC team. > > Jaisiel Santana. > > On Wed, Feb 10, 2016 at 1:03 PM, Alberto Mart?n Casado < > alberto.martin at bitergia.com> wrote: > >> Hi again! >> >> As I said yesterday, we've updated the Keyrock image to the 5.1.0 >> version. We've also made some adjustments in the timing synchronization of >> the Keyrock image, so hopefully the error you were getting is completely >> gone. >> >> Please, let us know if the error still appears. >> >> Best! >> >> >> Alberto Mart?n >> >> >> On Tue, Feb 9, 2016 at 11:52 AM, Alberto Mart?n Casado < >> alberto.martin at bitergia.com> wrote: >> >>> Hi! >>> >>> That's really strange... I'm using Debian GNU/Linux 8.1 (jessie), Docker >>> version 1.9.1, build a34a1d5 and docker-compose version 1.5.2, build >>> 7240ff3. >>> >>> In Travis tests works well also (pointing to your branch): >>> https://travis-ci.org/Fiware/tutorials.TourGuide-App/builds/107204432 >>> >>> There's been a release of a new version of Keyrock, and we are also >>> about to upgrade it, but nothing should change for the client. We will let >>> you know as soon as its ready, just in case you could not fix the issue. >>> >>> Best! >>> >>> >>> Alberto Mart?n >>> >>> On Tue, Feb 9, 2016 at 11:22 AM, Jaisiel Santana >>> wrote: >>> >>>> Hi! >>>> >>>> we have tried to generate all the containers again (even from the >>>> scratch using a new machine) and we have obtained the same error. >>>> >>>> We are using Ubuntu 14.04, Docker 1.8.3 and docker-compose 1.4.2. >>>> >>>> Which configuration are you using? >>>> >>>> >>>> Thanks, >>>> >>>> ULPGC team. >>>> >>>> >>>> On Mon, Feb 8, 2016 at 12:00 PM, Alberto Mart?n Casado < >>>> alberto.martin at bitergia.com> wrote: >>>> >>>>> Hi Pablo, >>>>> >>>>> I've been testing and I could not reproduce the issue right now, but >>>>> it happened to me once if I remember well. The script that generates the >>>>> 'idm2chanchan.json' was not able to access the database, which could cause >>>>> the issue. Probably is a timing issue due to the synchronization of all the >>>>> containers. We will have a look at it. >>>>> >>>>> Still, if you remove the containers and try to generate them again, >>>>> probably you will be able to run tourguide normally (if you are working >>>>> with volumes you should not lose any changes). >>>>> >>>>> Sorry for the inconvenience! >>>>> >>>>> Best, >>>>> >>>>> >>>>> Alberto Mart?n >>>>> >>>>> On Fri, Feb 5, 2016 at 11:57 AM, Pablo Fern?ndez Moniz < >>>>> pablofernandezmoniz at gmail.com> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> we are working to introduce the changes related to occupancy levels >>>>>> and reviews identifiers and we have found that we cannot log in on the app >>>>>> using IdM after retrieving the last modifications [idm_error.tiff]. We >>>>>> think that it occurs because the url and the callback url are set to >>>>>> localhost instead of the tourguide host [idm_localhost.tiff]. >>>>>> >>>>>> During installation we noticed that the tourguide_1 failed to >>>>>> retrieve the file '/config/idm2chanchan.json' >>>>>> [failed_to_retrieve_idm2chanchan.json.tiff] >>>>>> >>>>>> We don't discard that the issue is related to the refactoring process >>>>>> but we have revised our code and didn't find evidences of it. We have >>>>>> pushed our code to the branch fix/client_login_idm so you can reproduce >>>>>> the error by yourself. >>>>>> >>>>>> Do you have any suggestion about what is causing this error? >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> FIWARE ULPGC team. >>>>>> >>>>>> _______________________________________________ >>>>>> Fiware-developer-experience mailing list >>>>>> Fiware-developer-experience at lists.fiware.org >>>>>> https://lists.fiware.org/listinfo/fiware-developer-experience >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Fiware-developer-experience mailing list >>>>> Fiware-developer-experience at lists.fiware.org >>>>> https://lists.fiware.org/listinfo/fiware-developer-experience >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Fiware-developer-experience mailing list >>>> Fiware-developer-experience at lists.fiware.org >>>> https://lists.fiware.org/listinfo/fiware-developer-experience >>>> >>>> >>> >> > > _______________________________________________ > Fiware-developer-experience mailing list > Fiware-developer-experience at lists.fiware.org > https://lists.fiware.org/listinfo/fiware-developer-experience > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaisiel at gmail.com Fri Feb 12 12:26:39 2016 From: jaisiel at gmail.com (Jaisiel Santana) Date: Fri, 12 Feb 2016 11:26:39 +0000 Subject: [Fiware-developer-experience] IdM callback URL issue In-Reply-To: References: Message-ID: Hi! finally we can execute the app without get the error. As you said, we use now "docker-compose pull" before "docker-compose up" and it works (with the last commit). Just a suggestion, in order to avoid confusions by users, we think that the documentation should reflect this need. We are working to adapt the last changes and we will push the client with the updates as soon as possible. Thanks for the help!! FIWARE ULPGC team. On Thu, Feb 11, 2016 at 10:14 AM, Alberto Mart?n Casado < alberto.martin at bitergia.com> wrote: > Hi Jaisiel! > > The fork you've made from TourGuide is one commit [1] behind master. Due > to the Keyrock image upgrade, the users, roles and permissions provision > script has changed a bit in Tourguide, and that's why you are getting the > error. Please, sync your fork with master and everything will be gone :) > > Also, I would not change that in Travis. 'Npm test' runs a script that, in > order to avoid errors, first pulls all the images and then generate the > containers; by running directly 'docker-compose -f docker-compose.yml up', > it will pull and generate the containers at the same time, and it may > generate synchronization issues. > > Let me know how it goes. > > Best! > > > Alberto Mart?n > > [1]: > https://github.com/Fiware/tutorials.TourGuide-App/commit/b482d2cd1bbd6a39984568376b566a5c0930f150 > > On Thu, Feb 11, 2016 at 10:27 AM, Jaisiel Santana > wrote: > >> Hi! >> >> we have rebuilt the containers and the same error still appears. We made >> a fork of the project and we could replicate the error in Travis-ci >> >> https://travis-ci.org/FiwareULPGC/fiware-devguide-app/jobs/108481783#L1124 >> >> In order to replicate the error we replace in .travis.yml: >> >> * - cd $TEST_DIR && npm install && npm test* >> >> by >> >> - *cd $COMPOSE_DIR && docker-compose -f docker-compose.yml up* >> >> >> We are really thankful for your assist and if you need to clarify >> something, don't hesitate to contact us. >> >> FIWARE ULPGC team. >> >> Jaisiel Santana. >> >> On Wed, Feb 10, 2016 at 1:03 PM, Alberto Mart?n Casado < >> alberto.martin at bitergia.com> wrote: >> >>> Hi again! >>> >>> As I said yesterday, we've updated the Keyrock image to the 5.1.0 >>> version. We've also made some adjustments in the timing synchronization of >>> the Keyrock image, so hopefully the error you were getting is completely >>> gone. >>> >>> Please, let us know if the error still appears. >>> >>> Best! >>> >>> >>> Alberto Mart?n >>> >>> >>> On Tue, Feb 9, 2016 at 11:52 AM, Alberto Mart?n Casado < >>> alberto.martin at bitergia.com> wrote: >>> >>>> Hi! >>>> >>>> That's really strange... I'm using Debian GNU/Linux 8.1 >>>> (jessie), Docker version 1.9.1, build a34a1d5 and docker-compose version >>>> 1.5.2, build 7240ff3. >>>> >>>> In Travis tests works well also (pointing to your branch): >>>> https://travis-ci.org/Fiware/tutorials.TourGuide-App/builds/107204432 >>>> >>>> There's been a release of a new version of Keyrock, and we are also >>>> about to upgrade it, but nothing should change for the client. We will let >>>> you know as soon as its ready, just in case you could not fix the issue. >>>> >>>> Best! >>>> >>>> >>>> Alberto Mart?n >>>> >>>> On Tue, Feb 9, 2016 at 11:22 AM, Jaisiel Santana >>>> wrote: >>>> >>>>> Hi! >>>>> >>>>> we have tried to generate all the containers again (even from the >>>>> scratch using a new machine) and we have obtained the same error. >>>>> >>>>> We are using Ubuntu 14.04, Docker 1.8.3 and docker-compose 1.4.2. >>>>> >>>>> Which configuration are you using? >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> ULPGC team. >>>>> >>>>> >>>>> On Mon, Feb 8, 2016 at 12:00 PM, Alberto Mart?n Casado < >>>>> alberto.martin at bitergia.com> wrote: >>>>> >>>>>> Hi Pablo, >>>>>> >>>>>> I've been testing and I could not reproduce the issue right now, but >>>>>> it happened to me once if I remember well. The script that generates the >>>>>> 'idm2chanchan.json' was not able to access the database, which could cause >>>>>> the issue. Probably is a timing issue due to the synchronization of all the >>>>>> containers. We will have a look at it. >>>>>> >>>>>> Still, if you remove the containers and try to generate them again, >>>>>> probably you will be able to run tourguide normally (if you are working >>>>>> with volumes you should not lose any changes). >>>>>> >>>>>> Sorry for the inconvenience! >>>>>> >>>>>> Best, >>>>>> >>>>>> >>>>>> Alberto Mart?n >>>>>> >>>>>> On Fri, Feb 5, 2016 at 11:57 AM, Pablo Fern?ndez Moniz < >>>>>> pablofernandezmoniz at gmail.com> wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> we are working to introduce the changes related to occupancy levels >>>>>>> and reviews identifiers and we have found that we cannot log in on the app >>>>>>> using IdM after retrieving the last modifications [idm_error.tiff]. We >>>>>>> think that it occurs because the url and the callback url are set to >>>>>>> localhost instead of the tourguide host [idm_localhost.tiff]. >>>>>>> >>>>>>> During installation we noticed that the tourguide_1 failed to >>>>>>> retrieve the file '/config/idm2chanchan.json' >>>>>>> [failed_to_retrieve_idm2chanchan.json.tiff] >>>>>>> >>>>>>> We don't discard that the issue is related to the refactoring >>>>>>> process but we have revised our code and didn't find evidences of it. We >>>>>>> have pushed our code to the branch fix/client_login_idm so you can >>>>>>> reproduce the error by yourself. >>>>>>> >>>>>>> Do you have any suggestion about what is causing this error? >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> FIWARE ULPGC team. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Fiware-developer-experience mailing list >>>>>>> Fiware-developer-experience at lists.fiware.org >>>>>>> https://lists.fiware.org/listinfo/fiware-developer-experience >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Fiware-developer-experience mailing list >>>>>> Fiware-developer-experience at lists.fiware.org >>>>>> https://lists.fiware.org/listinfo/fiware-developer-experience >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Fiware-developer-experience mailing list >>>>> Fiware-developer-experience at lists.fiware.org >>>>> https://lists.fiware.org/listinfo/fiware-developer-experience >>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> Fiware-developer-experience mailing list >> Fiware-developer-experience at lists.fiware.org >> https://lists.fiware.org/listinfo/fiware-developer-experience >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alberto.martin at bitergia.com Fri Feb 12 17:08:35 2016 From: alberto.martin at bitergia.com (=?UTF-8?Q?Alberto_Mart=C3=ADn_Casado?=) Date: Fri, 12 Feb 2016 17:08:35 +0100 Subject: [Fiware-developer-experience] IdM callback URL issue In-Reply-To: References: Message-ID: Glad to hear :) That's a good idea. We will update the documentation to point that, as we are running many containers, is the best way to avoid synchronization issues. Thanks for the point! Best, Alberto Mart?n On Fri, Feb 12, 2016 at 12:26 PM, Jaisiel Santana wrote: > Hi! > > finally we can execute the app without get the error. As you said, we use > now "docker-compose pull" before "docker-compose up" and it works (with the > last commit). Just a suggestion, in order to avoid confusions by users, we > think that the documentation should reflect this need. > > We are working to adapt the last changes and we will push the client with > the updates as soon as possible. > > Thanks for the help!! > > FIWARE ULPGC team. > > > > On Thu, Feb 11, 2016 at 10:14 AM, Alberto Mart?n Casado < > alberto.martin at bitergia.com> wrote: > >> Hi Jaisiel! >> >> The fork you've made from TourGuide is one commit [1] behind master. Due >> to the Keyrock image upgrade, the users, roles and permissions provision >> script has changed a bit in Tourguide, and that's why you are getting the >> error. Please, sync your fork with master and everything will be gone :) >> >> Also, I would not change that in Travis. 'Npm test' runs a script that, >> in order to avoid errors, first pulls all the images and then generate the >> containers; by running directly 'docker-compose -f docker-compose.yml up', >> it will pull and generate the containers at the same time, and it may >> generate synchronization issues. >> >> Let me know how it goes. >> >> Best! >> >> >> Alberto Mart?n >> >> [1]: >> https://github.com/Fiware/tutorials.TourGuide-App/commit/b482d2cd1bbd6a39984568376b566a5c0930f150 >> >> On Thu, Feb 11, 2016 at 10:27 AM, Jaisiel Santana >> wrote: >> >>> Hi! >>> >>> we have rebuilt the containers and the same error still appears. We made >>> a fork of the project and we could replicate the error in Travis-ci >>> >>> >>> https://travis-ci.org/FiwareULPGC/fiware-devguide-app/jobs/108481783#L1124 >>> >>> In order to replicate the error we replace in .travis.yml: >>> >>> * - cd $TEST_DIR && npm install && npm test* >>> >>> by >>> >>> - *cd $COMPOSE_DIR && docker-compose -f docker-compose.yml up* >>> >>> >>> We are really thankful for your assist and if you need to clarify >>> something, don't hesitate to contact us. >>> >>> FIWARE ULPGC team. >>> >>> Jaisiel Santana. >>> >>> On Wed, Feb 10, 2016 at 1:03 PM, Alberto Mart?n Casado < >>> alberto.martin at bitergia.com> wrote: >>> >>>> Hi again! >>>> >>>> As I said yesterday, we've updated the Keyrock image to the 5.1.0 >>>> version. We've also made some adjustments in the timing synchronization of >>>> the Keyrock image, so hopefully the error you were getting is completely >>>> gone. >>>> >>>> Please, let us know if the error still appears. >>>> >>>> Best! >>>> >>>> >>>> Alberto Mart?n >>>> >>>> >>>> On Tue, Feb 9, 2016 at 11:52 AM, Alberto Mart?n Casado < >>>> alberto.martin at bitergia.com> wrote: >>>> >>>>> Hi! >>>>> >>>>> That's really strange... I'm using Debian GNU/Linux 8.1 >>>>> (jessie), Docker version 1.9.1, build a34a1d5 and docker-compose version >>>>> 1.5.2, build 7240ff3. >>>>> >>>>> In Travis tests works well also (pointing to your branch): >>>>> https://travis-ci.org/Fiware/tutorials.TourGuide-App/builds/107204432 >>>>> >>>>> There's been a release of a new version of Keyrock, and we are also >>>>> about to upgrade it, but nothing should change for the client. We will let >>>>> you know as soon as its ready, just in case you could not fix the issue. >>>>> >>>>> Best! >>>>> >>>>> >>>>> Alberto Mart?n >>>>> >>>>> On Tue, Feb 9, 2016 at 11:22 AM, Jaisiel Santana >>>>> wrote: >>>>> >>>>>> Hi! >>>>>> >>>>>> we have tried to generate all the containers again (even from the >>>>>> scratch using a new machine) and we have obtained the same error. >>>>>> >>>>>> We are using Ubuntu 14.04, Docker 1.8.3 and docker-compose 1.4.2. >>>>>> >>>>>> Which configuration are you using? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> ULPGC team. >>>>>> >>>>>> >>>>>> On Mon, Feb 8, 2016 at 12:00 PM, Alberto Mart?n Casado < >>>>>> alberto.martin at bitergia.com> wrote: >>>>>> >>>>>>> Hi Pablo, >>>>>>> >>>>>>> I've been testing and I could not reproduce the issue right now, but >>>>>>> it happened to me once if I remember well. The script that generates the >>>>>>> 'idm2chanchan.json' was not able to access the database, which could cause >>>>>>> the issue. Probably is a timing issue due to the synchronization of all the >>>>>>> containers. We will have a look at it. >>>>>>> >>>>>>> Still, if you remove the containers and try to generate them again, >>>>>>> probably you will be able to run tourguide normally (if you are working >>>>>>> with volumes you should not lose any changes). >>>>>>> >>>>>>> Sorry for the inconvenience! >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> >>>>>>> Alberto Mart?n >>>>>>> >>>>>>> On Fri, Feb 5, 2016 at 11:57 AM, Pablo Fern?ndez Moniz < >>>>>>> pablofernandezmoniz at gmail.com> wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> we are working to introduce the changes related to occupancy levels >>>>>>>> and reviews identifiers and we have found that we cannot log in on the app >>>>>>>> using IdM after retrieving the last modifications [idm_error.tiff]. We >>>>>>>> think that it occurs because the url and the callback url are set to >>>>>>>> localhost instead of the tourguide host [idm_localhost.tiff]. >>>>>>>> >>>>>>>> During installation we noticed that the tourguide_1 failed to >>>>>>>> retrieve the file '/config/idm2chanchan.json' >>>>>>>> [failed_to_retrieve_idm2chanchan.json.tiff] >>>>>>>> >>>>>>>> We don't discard that the issue is related to the refactoring >>>>>>>> process but we have revised our code and didn't find evidences of it. We >>>>>>>> have pushed our code to the branch fix/client_login_idm so you can >>>>>>>> reproduce the error by yourself. >>>>>>>> >>>>>>>> Do you have any suggestion about what is causing this error? >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> FIWARE ULPGC team. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Fiware-developer-experience mailing list >>>>>>>> Fiware-developer-experience at lists.fiware.org >>>>>>>> https://lists.fiware.org/listinfo/fiware-developer-experience >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Fiware-developer-experience mailing list >>>>>>> Fiware-developer-experience at lists.fiware.org >>>>>>> https://lists.fiware.org/listinfo/fiware-developer-experience >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Fiware-developer-experience mailing list >>>>>> Fiware-developer-experience at lists.fiware.org >>>>>> https://lists.fiware.org/listinfo/fiware-developer-experience >>>>>> >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> Fiware-developer-experience mailing list >>> Fiware-developer-experience at lists.fiware.org >>> https://lists.fiware.org/listinfo/fiware-developer-experience >>> >>> >> > > _______________________________________________ > Fiware-developer-experience mailing list > Fiware-developer-experience at lists.fiware.org > https://lists.fiware.org/listinfo/fiware-developer-experience > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pablofernandezmoniz at gmail.com Mon Feb 15 22:08:09 2016 From: pablofernandezmoniz at gmail.com (=?UTF-8?Q?Pablo_Fern=C3=A1ndez_Moniz?=) Date: Mon, 15 Feb 2016 21:08:09 +0000 Subject: [Fiware-developer-experience] Issue related to occupancy levels Message-ID: Hi! we are updating the client with the last API changes, and we think that we have found an issue. The problem is related to the occupancyLevel field that is treated as string instead of integer. This causes that if a user make two reservations, the number of commensals are concatenated as a string instead of being added. The screenshot [reservation_5.png] shows the occupancyLevel after reserved five commensals while the [reservation_5_more.png] image shows the occupancyLevel after reserve five more commensals. The consequences of the issue are that neither the backend nor the front end can control the max reservations allowing to the app virtually make reservations for a infinite number of commensals.[allow_infinite_reservations.png] Any sugesttions? Regards, ULPGC team -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: allow_infinite_reservations.png Type: image/png Size: 52826 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: reservation_5_more.png Type: image/png Size: 46911 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: reservation_5.png Type: image/png Size: 42149 bytes Desc: not available URL: From alberto.martin at bitergia.com Tue Feb 16 10:38:41 2016 From: alberto.martin at bitergia.com (=?UTF-8?Q?Alberto_Mart=C3=ADn_Casado?=) Date: Tue, 16 Feb 2016 10:38:41 +0100 Subject: [Fiware-developer-experience] Issue related to occupancy levels In-Reply-To: References: Message-ID: Hi Pablo! On Mon, Feb 15, 2016 at 10:08 PM, Pablo Fern?ndez Moniz < pablofernandezmoniz at gmail.com> wrote: > Hi! > > we are updating the client with the last API changes, and we think that we > have found an issue. > > The problem is related to the occupancyLevel field that is treated as > string instead of integer. > > This causes that if a user make two reservations, the number of commensals > are concatenated as a string instead of being added. The screenshot > [reservation_5.png] shows the occupancyLevel after reserved five commensals > while the [reservation_5_more.png] image shows the occupancyLevel after > reserve five more commensals. > > The consequences of the issue are that neither the backend nor the front > end can control the max reservations allowing to the app virtually make > reservations for a infinite number of > commensals.[allow_infinite_reservations.png] > > Any sugesttions? > I've been testing the API, and if the Reservation field 'partySize' is posted as an integer in the reservation, the back-end works as expected (see attachments). But as you said, if you generate reservations adding the field as a String, the behavior is wrong and it concatenates the values. Even though using the right variable types does not generate any issue, I will add a cast for that field in every reservation generation to avoid it. Hope it works for you! Best, Alberto Mart?n -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: reservations_list.png Type: image/png Size: 158021 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: get_restaurant_with_date_filter.png Type: image/png Size: 147451 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: create_reservation.png Type: image/png Size: 67799 bytes Desc: not available URL: From jaisiel at gmail.com Wed Feb 17 12:38:09 2016 From: jaisiel at gmail.com (Jaisiel Santana) Date: Wed, 17 Feb 2016 11:38:09 +0000 Subject: [Fiware-developer-experience] Unexpected timestamp retrieving restaurant by date. Message-ID: Hi! We found an unexpected behavior when we perform multiple *restaurant-by-date* requests at the same time using different timestamps. Some of the responses that we get do not correspond with the solicited timestamp [unexpected_time_stamp.png]. If we add a little timeout before send each new request, the issue does not happen. We think that it could be a minor performance issue but it is not too important because it's a starter guide and we can control it from the client. Furthermore, we think that it will be kept in mind for scalability purposes. Regards, ULPGC team. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: unexpected_time_stamp.png Type: image/png Size: 604479 bytes Desc: not available URL: From pablofernandezmoniz at gmail.com Wed Feb 17 12:45:49 2016 From: pablofernandezmoniz at gmail.com (=?UTF-8?Q?Pablo_Fern=C3=A1ndez_Moniz?=) Date: Wed, 17 Feb 2016 11:45:49 +0000 Subject: [Fiware-developer-experience] Issue related to occupancy levels In-Reply-To: References: Message-ID: Hi! you were right, we was providing the party_size field incorrectly. We forced a cast to integer and now the occupancy level is increased as a number with each reservation. With this fix, we can check if we can perform a reservation or not. Due to a bug in the reservation control from the client, we found that the restriction from the backend does not seem to work for us. We could make more reservations even if occupancyLevel raises the capacity value [occupancy_exceeds_capacity_1.png] [occupancy_exceeds_capacity_2.png]. Are we requesting the reservations correctly? 2016-02-16 9:38 GMT+00:00 Alberto Mart?n Casado : > Hi Pablo! > > On Mon, Feb 15, 2016 at 10:08 PM, Pablo Fern?ndez Moniz < > pablofernandezmoniz at gmail.com> wrote: > >> Hi! >> >> we are updating the client with the last API changes, and we think that >> we have found an issue. >> >> The problem is related to the occupancyLevel field that is treated as >> string instead of integer. >> >> This causes that if a user make two reservations, the number of >> commensals are concatenated as a string instead of being added. The >> screenshot [reservation_5.png] shows the occupancyLevel after reserved five >> commensals while the [reservation_5_more.png] image shows the >> occupancyLevel after reserve five more commensals. >> >> The consequences of the issue are that neither the backend nor the front >> end can control the max reservations allowing to the app virtually make >> reservations for a infinite number of >> commensals.[allow_infinite_reservations.png] >> >> Any sugesttions? >> > > I've been testing the API, and if the Reservation field 'partySize' is > posted as an integer in the reservation, the back-end works as expected > (see attachments). But as you said, if you generate reservations adding the > field as a String, the behavior is wrong and it concatenates the values. > > Even though using the right variable types does not generate any issue, I > will add a cast for that field in every reservation generation to avoid it. > > Hope it works for you! > > Best, > > > Alberto Mart?n > -- Pablo Fern?ndez Moniz GIT Analyst Web Linkedin Twitter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: occupancy_exceeds_capacity_1.png Type: image/png Size: 54349 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: occupancy_exceeds_capacity_2.png Type: image/png Size: 39257 bytes Desc: not available URL: From alberto.martin at bitergia.com Wed Feb 17 13:26:30 2016 From: alberto.martin at bitergia.com (=?UTF-8?Q?Alberto_Mart=C3=ADn_Casado?=) Date: Wed, 17 Feb 2016 13:26:30 +0100 Subject: [Fiware-developer-experience] Fwd: Unexpected timestamp retrieving restaurant by date. In-Reply-To: References: Message-ID: Forwarding to the list (forgot to cc) ---------- Forwarded message ---------- From: Alberto Mart?n Casado Date: Wed, Feb 17, 2016 at 12:52 PM Subject: Re: [Fiware-developer-experience] Unexpected timestamp retrieving restaurant by date. To: Jaisiel Santana Hi! Thanks for letting us now. As we are performing requests directly to Orion, I think we should check if the "error" is due to our Server or due to the responses we get from Orion. If as you said is not a huge issue, I'll leave it in background. Thanks again! Best, Alberto Mart?n On Wed, Feb 17, 2016 at 12:38 PM, Jaisiel Santana wrote: > Hi! > > We found an unexpected behavior when we perform multiple > *restaurant-by-date* requests at the same time using different > timestamps. Some of the responses that we get do not correspond with the > solicited timestamp [unexpected_time_stamp.png]. > > If we add a little timeout before send each new request, the issue does > not happen. We think that it could be a minor performance issue but it is > not too important because it's a starter guide and we can control it from > the client. Furthermore, we think that it will be kept in mind for > scalability purposes. > > > Regards, > > ULPGC team. > > _______________________________________________ > Fiware-developer-experience mailing list > Fiware-developer-experience at lists.fiware.org > https://lists.fiware.org/listinfo/fiware-developer-experience > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alberto.martin at bitergia.com Wed Feb 17 13:26:48 2016 From: alberto.martin at bitergia.com (=?UTF-8?Q?Alberto_Mart=C3=ADn_Casado?=) Date: Wed, 17 Feb 2016 13:26:48 +0100 Subject: [Fiware-developer-experience] Fwd: Issue related to occupancy levels In-Reply-To: References: Message-ID: Forwarding to the list (forgot to cc) ---------- Forwarded message ---------- From: Pablo Fern?ndez Moniz Date: Wed, Feb 17, 2016 at 1:18 PM Subject: Re: [Fiware-developer-experience] Issue related to occupancy levels To: Alberto Mart?n Casado Great! Thank you 2016-02-17 11:55 GMT+00:00 Alberto Mart?n Casado < alberto.martin at bitergia.com>: > Hi Pablo! > > While doing the cast for the 'partySize' values, I've found the bug you > are reporting right now. The issue is fixed here > so, > if you pull the latest changes it should work. > > I've tested myself and it works in the client :) > > Best, > > > Alberto Mart?n > > On Wed, Feb 17, 2016 at 12:45 PM, Pablo Fern?ndez Moniz < > pablofernandezmoniz at gmail.com> wrote: > >> Hi! >> >> you were right, we was providing the party_size field incorrectly. We >> forced a cast to integer and now the occupancy level is increased as a >> number with each reservation. With this fix, we can check if we can perform >> a reservation or not. >> >> Due to a bug in the reservation control from the client, we found that >> the restriction from the backend does not seem to work for us. We could >> make more reservations even if occupancyLevel raises the capacity value >> [occupancy_exceeds_capacity_1.png] [occupancy_exceeds_capacity_2.png]. >> >> Are we requesting the reservations correctly? >> >> >> 2016-02-16 9:38 GMT+00:00 Alberto Mart?n Casado < >> alberto.martin at bitergia.com>: >> >>> Hi Pablo! >>> >>> On Mon, Feb 15, 2016 at 10:08 PM, Pablo Fern?ndez Moniz < >>> pablofernandezmoniz at gmail.com> wrote: >>> >>>> Hi! >>>> >>>> we are updating the client with the last API changes, and we think that >>>> we have found an issue. >>>> >>>> The problem is related to the occupancyLevel field that is treated as >>>> string instead of integer. >>>> >>>> This causes that if a user make two reservations, the number of >>>> commensals are concatenated as a string instead of being added. The >>>> screenshot [reservation_5.png] shows the occupancyLevel after reserved five >>>> commensals while the [reservation_5_more.png] image shows the >>>> occupancyLevel after reserve five more commensals. >>>> >>>> The consequences of the issue are that neither the backend nor the >>>> front end can control the max reservations allowing to the app virtually >>>> make reservations for a infinite number of >>>> commensals.[allow_infinite_reservations.png] >>>> >>>> Any sugesttions? >>>> >>> >>> I've been testing the API, and if the Reservation field 'partySize' is >>> posted as an integer in the reservation, the back-end works as expected >>> (see attachments). But as you said, if you generate reservations adding the >>> field as a String, the behavior is wrong and it concatenates the values. >>> >>> Even though using the right variable types does not generate any issue, >>> I will add a cast for that field in every reservation generation to avoid >>> it. >>> >>> Hope it works for you! >>> >>> Best, >>> >>> >>> Alberto Mart?n >>> >> >> >> >> -- >> >> Pablo Fern?ndez Moniz >> GIT Analyst >> >> Web Linkedin >> Twitter >> >> > > -- Pablo Fern?ndez Moniz GIT Analyst Web Linkedin Twitter -------------- next part -------------- An HTML attachment was scrubbed... URL: From alberto.martin at bitergia.com Mon Feb 22 08:41:59 2016 From: alberto.martin at bitergia.com (=?UTF-8?Q?Alberto_Mart=C3=ADn_Casado?=) Date: Mon, 22 Feb 2016 08:41:59 +0100 Subject: [Fiware-developer-experience] Latest TourGuide changes Message-ID: Hi all! During the last week we've added some changes to the TourGuide: - We've made the first integration with the CEP image. As the official CEP image wasn't automated in Dockerhub, we've made our own image under our organization, lighter and based on the Tomcat 7 official image. The initial approach is to generate events when temperatures exceeds some limits during a 30 sec period time (using the UL20 client). Documentation of it's usage will be added during the week. - We've added schema validators to the Restaurant, review and reservations entities. Now, the sever checks the elements and types before posting to Orion. This breaks some of the functionalities of the client, as it's using wrong value types (as discussed in previous e-mails). We've been also testing the client and we've found several things worth to mention: 1. The latest client update included >236.000 line changes and 180 files. As you made a pull request, I thought you would like us to review it, but even Github said that this was impossible (find image attached). It was an urgent change because the client was broken (due to the renaming), but now we are discussing if we should "re-write" the repository history. We believe that doing smaller commits allow everyone to trace all the changes easier (even though we are not developing the client). Also, we wonder if all the files included are needed (for example here: https://github.com/Fiware/tutorials.TourGuide-App/tree/master/client/img/FI-WARE_style_guide/wordpress). What do you think? 2. Initial warning. Every time we access tourguide, there's an initial warning that can confuse the users (image attached). It may suggest users that something is failing, meanwhile it's just the user needs to log in to start. 3. Drop-down button in reservations allow to select from [1,2,3,4,5,100]. It should allow to generate reservations from different values (image attached). 4. Reservations have some typos also (image attached). Also, we've discussed about the field 'commensals' and it sounds a bit strange for us. How about 'customers' or 'diners'? Waiting for your feedback. Best! Alberto Mart?n -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: git-commit.png Type: image/png Size: 47602 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dropdown.png Type: image/png Size: 19516 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: typos.png Type: image/png Size: 16431 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: initial_warning.png Type: image/png Size: 7382 bytes Desc: not available URL: From josemanuel.canterafonseca at telefonica.com Mon Feb 22 08:49:53 2016 From: josemanuel.canterafonseca at telefonica.com (JOSE MANUEL CANTERA FONSECA) Date: Mon, 22 Feb 2016 07:49:53 +0000 Subject: [Fiware-developer-experience] Latest TourGuide changes In-Reply-To: References: Message-ID: Hi, Can we separate the client changes in different pull requests? For instance, look and feel changes and functional changes, but I agree that we should not be working by creating so big changes in one chunk ... Incremental pull requests separating features and changes is a must ... Thanks! De: > on behalf of Alberto Mart?n Casado > Fecha: lunes, 22 de febrero de 2016, 8:41 Para: "fiware-developer-experience at lists.fiware.org" > Asunto: [Fiware-developer-experience] Latest TourGuide changes Hi all! During the last week we've added some changes to the TourGuide: - We've made the first integration with the CEP image. As the official CEP image wasn't automated in Dockerhub, we've made our own image under our organization, lighter and based on the Tomcat 7 official image. The initial approach is to generate events when temperatures exceeds some limits during a 30 sec period time (using the UL20 client). Documentation of it's usage will be added during the week. - We've added schema validators to the Restaurant, review and reservations entities. Now, the sever checks the elements and types before posting to Orion. This breaks some of the functionalities of the client, as it's using wrong value types (as discussed in previous e-mails). We've been also testing the client and we've found several things worth to mention: 1. The latest client update included >236.000 line changes and 180 files. As you made a pull request, I thought you would like us to review it, but even Github said that this was impossible (find image attached). It was an urgent change because the client was broken (due to the renaming), but now we are discussing if we should "re-write" the repository history. We believe that doing smaller commits allow everyone to trace all the changes easier (even though we are not developing the client). Also, we wonder if all the files included are needed (for example here: https://github.com/Fiware/tutorials.TourGuide-App/tree/master/client/img/FI-WARE_style_guide/wordpress). What do you think? 2. Initial warning. Every time we access tourguide, there's an initial warning that can confuse the users (image attached). It may suggest users that something is failing, meanwhile it's just the user needs to log in to start. 3. Drop-down button in reservations allow to select from [1,2,3,4,5,100]. It should allow to generate reservations from different values (image attached). 4. Reservations have some typos also (image attached). Also, we've discussed about the field 'commensals' and it sounds a bit strange for us. How about 'customers' or 'diners'? Waiting for your feedback. Best! Alberto Mart?n ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener informaci?n privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilizaci?n, divulgaci?n y/o copia sin autorizaci?n puede estar prohibida en virtud de la legislaci?n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su destrucci?n. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat?rio, pode conter informa??o privilegiada ou confidencial e ? para uso exclusivo da pessoa ou entidade de destino. Se n?o ? vossa senhoria o destinat?rio indicado, fica notificado de que a leitura, utiliza??o, divulga??o e/ou c?pia sem autoriza??o pode estar proibida em virtude da legisla??o vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destrui??o -------------- next part -------------- An HTML attachment was scrubbed... URL: From pablofernandezmoniz at gmail.com Mon Feb 22 10:35:16 2016 From: pablofernandezmoniz at gmail.com (=?UTF-8?Q?Pablo_Fern=C3=A1ndez_Moniz?=) Date: Mon, 22 Feb 2016 09:35:16 +0000 Subject: [Fiware-developer-experience] Latest TourGuide changes In-Reply-To: References: Message-ID: Hi all! Most of the new files are related to the FIWARE Style Guide, so we will check all files and find with files are not currently needed for the addons. We absolutely agree with that, one of the reasons of the big pull, is that the actual client is completely new comparing the old one: styes and API functionalities. We also has to readapt the code several times each time the docker images in docker-hub stop to work for us due to new changes. Anyway, we agree with the need to separate the pull request and we are working on it! Talking about other minor issues, thank you for your feedback! we will solve them as soon as possible. Regards, 2016-02-22 7:49 GMT+00:00 JOSE MANUEL CANTERA FONSECA < josemanuel.canterafonseca at telefonica.com>: > Hi, > > Can we separate the client changes in different pull requests? For > instance, look and feel changes and functional changes, but I agree that we > should not be working by creating so big changes in one chunk ? Incremental > pull requests separating features and changes is a must ? > > Thanks! > > De: on behalf of > Alberto Mart?n Casado > Fecha: lunes, 22 de febrero de 2016, 8:41 > Para: "fiware-developer-experience at lists.fiware.org" < > fiware-developer-experience at lists.fiware.org> > Asunto: [Fiware-developer-experience] Latest TourGuide changes > > Hi all! > > During the last week we've added some changes to the TourGuide: > > - We've made the first integration with the CEP image. As the official CEP > image wasn't automated in Dockerhub, we've made our own image under our > organization, lighter and based on the Tomcat 7 official image. The > initial approach is to generate events when temperatures exceeds some > limits during a 30 sec period time (using the UL20 client). Documentation > of it's usage will be added during the week. > > - We've added schema validators to the Restaurant, review and reservations > entities. Now, the sever checks the elements and types before posting to > Orion. This breaks some of the functionalities of the client, as it's using > wrong value types (as discussed in previous e-mails). > > We've been also testing the client and we've found several things worth to > mention: > > 1. The latest client update included >236.000 line changes and 180 files. > As you made a pull request, I thought you would like us to review it, but > even Github said that this was impossible (find image attached). It was an > urgent change because the client was broken (due to the renaming), but now > we are discussing if we should "re-write" the repository history. We > believe that doing smaller commits allow everyone to trace all the changes > easier (even though we are not developing the client). Also, we wonder if > all the files included are needed (for example here: > https://github.com/Fiware/tutorials.TourGuide-App/tree/master/client/img/FI-WARE_style_guide/wordpress). > What do you think? > > 2. Initial warning. Every time we access tourguide, there's an initial > warning that can confuse the users (image attached). It may suggest users > that something is failing, meanwhile it's just the user needs to log in to > start. > > 3. Drop-down button in reservations allow to select from [1,2,3,4,5,100]. > It should allow to generate reservations from different values (image > attached). > > 4. Reservations have some typos also (image attached). Also, we've > discussed about the field 'commensals' and it sounds a bit strange for us. > How about 'customers' or 'diners'? > > Waiting for your feedback. > > Best! > > Alberto Mart?n > > > > ------------------------------ > > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, > puede contener informaci?n privilegiada o confidencial y es para uso > exclusivo de la persona o entidad de destino. Si no es usted. el > destinatario indicado, queda notificado de que la lectura, utilizaci?n, > divulgaci?n y/o copia sin autorizaci?n puede estar prohibida en virtud de > la legislaci?n vigente. Si ha recibido este mensaje por error, le rogamos > que nos lo comunique inmediatamente por esta misma v?a y proceda a su > destrucci?n. > > The information contained in this transmission is privileged and > confidential information intended only for the use of the individual or > entity named above. If the reader of this message is not the intended > recipient, you are hereby notified that any dissemination, distribution or > copying of this communication is strictly prohibited. If you have received > this transmission in error, do not read it. Please immediately reply to the > sender that you have received this communication in error and then delete > it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat?rio, > pode conter informa??o privilegiada ou confidencial e ? para uso exclusivo > da pessoa ou entidade de destino. Se n?o ? vossa senhoria o destinat?rio > indicado, fica notificado de que a leitura, utiliza??o, divulga??o e/ou > c?pia sem autoriza??o pode estar proibida em virtude da legisla??o vigente. > Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique > imediatamente por esta mesma via e proceda a sua destrui??o > > _______________________________________________ > Fiware-developer-experience mailing list > Fiware-developer-experience at lists.fiware.org > https://lists.fiware.org/listinfo/fiware-developer-experience > > -- Pablo Fern?ndez Moniz GIT Analyst Web Linkedin Twitter -------------- next part -------------- An HTML attachment was scrubbed... URL: From pablofernandezmoniz at gmail.com Thu Feb 25 12:42:16 2016 From: pablofernandezmoniz at gmail.com (=?UTF-8?Q?Pablo_Fern=C3=A1ndez_Moniz?=) Date: Thu, 25 Feb 2016 11:42:16 +0000 Subject: [Fiware-developer-experience] Error 500 triying to get reviews by organization Message-ID: Hi! We are trying to get reviews by organization but, if we perform a request, we get a 500 error [request.png]. Attached the output error [ error.png] If this error occurs, the user should log in again because the token is lost. The same error happens in reservations Are we performing the request in a wrong way? Thanks in advance! ULPGC team. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: request.png Type: image/png Size: 121847 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: error.png Type: image/png Size: 497216 bytes Desc: not available URL: From dmuriel at bitergia.com Thu Feb 25 14:40:46 2016 From: dmuriel at bitergia.com (David Muriel) Date: Thu, 25 Feb 2016 14:40:46 +0100 Subject: [Fiware-developer-experience] Error 500 triying to get reviews by organization In-Reply-To: References: Message-ID: On Thu, Feb 25, 2016 at 12:42 PM, Pablo Fern?ndez Moniz wrote: > Hi! > > We are trying to get reviews by organization but, if we perform a request, > we get a 500 error [request.png]. > > Attached the output error [ error.png] > > If this error occurs, the user should log in again because the token is > lost. > > The same error happens in reservations > > Are we performing the request in a wrong way? No, the request was fine, there was a bug in the filtering functions. I've just pushed the fix to the repository. Thanks for the report. Regards, -- David Muriel. From pablofernandezmoniz at gmail.com Thu Feb 25 15:03:51 2016 From: pablofernandezmoniz at gmail.com (=?UTF-8?Q?Pablo_Fern=C3=A1ndez_Moniz?=) Date: Thu, 25 Feb 2016 14:03:51 +0000 Subject: [Fiware-developer-experience] Error 500 triying to get reviews by organization In-Reply-To: References: Message-ID: Hi David, Thank you for your fast reply and fix! Regards, 2016-02-25 13:40 GMT+00:00 David Muriel : > On Thu, Feb 25, 2016 at 12:42 PM, Pablo Fern?ndez Moniz > wrote: > > Hi! > > > > We are trying to get reviews by organization but, if we perform a > request, > > we get a 500 error [request.png]. > > > > Attached the output error [ error.png] > > > > If this error occurs, the user should log in again because the token is > > lost. > > > > The same error happens in reservations > > > > Are we performing the request in a wrong way? > > No, the request was fine, there was a bug in the filtering functions. > I've just pushed the fix to the repository. > Thanks for the report. > > Regards, > -- > David Muriel. > -- Pablo Fern?ndez Moniz GIT Analyst Web Linkedin Twitter -------------- next part -------------- An HTML attachment was scrubbed... URL: From josemanuel.canterafonseca at telefonica.com Fri Feb 26 12:35:19 2016 From: josemanuel.canterafonseca at telefonica.com (JOSE MANUEL CANTERA FONSECA) Date: Fri, 26 Feb 2016 11:35:19 +0000 Subject: [Fiware-developer-experience] Development guidelines Message-ID: Friends, Please, all the development of the Tour guide Application must be done in accordance with the FIWARE Community development guidelines http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Developer_Guidelines Particularly, please do not land any code without a proper peer review. Additionally, please keep your PRs simple, clean and focused on one work item at a time (bug, feature, etc.) to ease the review process. Once a peer review has been conducted, and all the comments have been addressed, (which can take many cycles) the reviewer will have to sign off by writing 'LGTM' (looks good to me) Thanks for your help and support best ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener informaci?n privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilizaci?n, divulgaci?n y/o copia sin autorizaci?n puede estar prohibida en virtud de la legislaci?n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su destrucci?n. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat?rio, pode conter informa??o privilegiada ou confidencial e ? para uso exclusivo da pessoa ou entidade de destino. Se n?o ? vossa senhoria o destinat?rio indicado, fica notificado de que a leitura, utiliza??o, divulga??o e/ou c?pia sem autoriza??o pode estar proibida em virtude da legisla??o vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destrui??o -------------- next part -------------- An HTML attachment was scrubbed... URL: