Anyone else ?If we all agree I can adapt the temporary backend I deployed including this new behaviour.SebiOn Mon, May 5, 2014 at 9:34 AM, Christos Vasilakis <cvasilak@gmail.com> wrote:Hi,
answers inline
+1
On May 2, 2014, at 11:37 PM, Jay Balunas <jbalunas@redhat.com> wrote:
> I wanted to chime in here on additional/related items around the contacts use-case and specifically around how to integrate push. Some of these have already been discussed so just getting in one place for my own sanity :-)
>
> 1) I agree that users and "contacts" are separate things. I think it is best to think about them as was mentioned below - users (employees) and contacts (customers, leads, etc...). This is easier to grok imo and could be helped by some simple wording in the UI.
already the backend provides endpoints for creation of “users”, as well as a list of default users initialised once the app is first loaded. By default when a new user is created the security role assigned to it doesn’t allow the creation of new contacts, you get back an “Unauthorised” error. It doesn’t effect push per se, since an “admin” user can create a contact and the notification can be send to all other users that are logged in, but we should document this behaviour.
> Cons:
> ** We then need a way to add "users" - otherwise we won't be sending many push messages. Maybe users could be automatically created when an app first accesses the backend?
I am +1 on this behaviour. IMHO its more clear for the end-user and the actual notification is used to “alert” for a change on the server part that the app can decided to respond (e.g. fetch the new contact list).
>
> 2) Simplifying the push use-case: If we change the use-case from saying hi to specific contacts to notifying all users when a new contact was created it could simplify not only the UI, but the server side processing for the push. We could reserve the more specific push usage to the console, and/or AeroDoc.
>
> If we go with 2) we might be able to avoid the issues with 1) altogether because a broadcast would send to every app that has registered.
>
> Wdyt?
Thanks,
Christos
>
>
> On May 1, 2014, at 10:46 AM, Burr Sutter <bsutter@redhat.com> wrote:
>
>> Joshua owns the backend, let's see if he has a thought on this item.
>>
>> On May 1, 2014, at 7:25 AM, Christos Vasilakis <cvasilak@gmail.com> wrote:
>>
>>> Hi everyone,
>>>
>>> have started working on the iOS native client of the contacts quick start app. Based on edewit branch[1] (which creates a contact on signup of a user) have created an initial version of the iOS client and you can find it here [2], together with a screencast showcasing the app in action [3].
>>>
>>> Some comments observed during writing of the application which would like your feedback:
>>>
>>> a) for PUT, DELETE operations noticed that the jax-rs backend expects the id of the Contact to be present in the body of the request. Not sure why this was chosen instead of @Path(“id”) resulting against /contacts/{id} ?
>>>
>>> b) currently roles are used to distinguish between who is able to create/update/delete contact. When a user signs up (and contact is created), by default the user is _not_ able to apply any CRUD operations apart from viewing (any operation results in unauthorised error). If we agree on this behaviour, would like to know how can I determine the role of the user (in order to update the UI accordingly, eg. disabling add,edit UI elements). Looking at the json response upon login of the user, couldn’t determine a “key” that specifies the role (apart from an “admin” key which stayed the same regardless of the type of the user).
>>>
>>>
>>> Thanks,
>>> Christos
>>>
>>> [1] https://github.com/edewit/jboss-wfk-quickstarts/tree/push_and_secured
>>> [2] https://github.com/cvasilak/aerogear-push-quickstarts/tree/ios
>>> [3] https://vimeo.com/93471554
>>>
>>>
>>>
>>> On Apr 23, 2014, at 5:43 PM, Erik Jan de Wit <edewit@redhat.com> wrote:
>>>
>>>> Right, that makes sense, so let’s not join them. The alternate thing to do is to create a contact on sign up, because if you want to receive push notifications at least you should be in the list of contacts. We will still need to change the sign up page a little as we need a phone number and a birth date as well in order to create a contact.
>>>>
>>>> On 23 Apr,2014, at 16:26 , Burr Sutter <bsutter@redhat.com> wrote:
>>>>
>>>>> These are not strongly held opinions
>>>>>
>>>>> One reason to keep Users & Contacts separate is...because that is normal for the average enterprise app - your have employees (users) and customers (contacts) - employees/users have different roles/privileges from customers.
>>>>>
>>>>> The reason they are separated in the secured (PL) version of contacts-mobile-basic is because it simply evolved that way - contacts came first - users/roles added after the fact. Ideally we would not modify the original too much as it allows a nice learning progression - start with the original contacts-mobile-basic, then upgrade to contacts-mobile-basic-secured, then upgrade to contacts-mobile-basic-secured-cordova (names just made up).
>>>>>
>>>>>
>>>>> On Apr 23, 2014, at 10:16 AM, Sébastien Blanc <scm.blanc@gmail.com> wrote:
>>>>>
>>>>>> Sure !
>>>>>> Be sure to check this with Joshua as he drives the backend bits
>>>>>> Sébi
>>>>>>
>>>>>> Envoyé de mon iPhone
>>>>>>
>>>>>>> Le 23 avr. 2014 à 15:56, Erik Jan de Wit <edewit@redhat.com> a écrit :
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> How about merging the User model and the Contact into one entity? Seems like they have a lot in common, do we really need 2?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Erik Jan
>>>>>>>
>>>>>>>> On 23 Apr,2014, at 14:34 , Sébastien Blanc <scm.blanc@gmail.com> wrote:
>>>>>>>>
>>>>>>>> We should be using the email as alias and the email should also be used as login when registering in the secured part. A registration should also trigger the creation of that user / contact in the application.
>>>>>>>> Author can be left empty By the client and filled by the backend . https://github.com/sebastienblanc/jboss-wfk-quickstarts/tree/push_and_securedAuthor must stay because the receiver must know who sends the message.
>>>>>>>>
>>>>>>>> Envoyé de mon iPhone
>>>>>>>>
>>>>>>>>> Le 23 avr. 2014 à 13:35, Erik Jan de Wit <edewit@redhat.com> a écrit :
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I was working on the aerogear-push-quickstarts for Cordova and was wondering what to put for the alias on registration. The version that is there now has users that logs in and contacts that are fetched. What seems to be missing is that everybody gets all contacts instead of just mine (maybe that is fine), but users that sign up for the app are not contacts. So when I want to send a message to a specific mobile user they are not in my list and there is no way to have to define an alias to send to.
>>>>>>>>>
>>>>>>>>> Also the interface for sending push notifications includes a author. I think it would be better if we remove this and let the service put in the logged in user. That way you can’t pretend to send a message like someone else.
>>>>>>>>>
>>>>>>>>> What do you think?
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Erik Jan
>>>>>>>>> _______________________________________________
>>>>>>>>> aerogear-dev mailing list
>>>>>>>>> aerogear-dev@lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> aerogear-dev mailing list
>>>>>>>> aerogear-dev@lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> aerogear-dev mailing list
>>>>>>> aerogear-dev@lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev@lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev@lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev@lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev