https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups
on import of new survey's the default static user group is assigned to the
case in our application.
I have added a Case Sharing logistics form that will allow a supervisor to
assign the case to the correct group based on case properties........
this is working great but my supervisors want to go to a further
level..........they would like to add a secondary level to this so they can
select a distinct FLW from the case sharing group selected as the owner_id
not just the group level.
any suggestions on modifying the above totorial?
i thought maybe we would have a simular instance such as *jr://fixture/user
jr://fixture/user-groups instead of **jr://fixture/user-groups
jr://fixture/user-groups . *
or a cascading select from the selected case sharing group from which they
could select the team member.........
your thoughts?
Hi John!
In general programs who need that level of complexity for ownership
hierarchies and data manipulation have more success moving their project to
using the Organizations feature
https://confluence.dimagi.com/display/commcarepublic/Organizations as a
way to gain visibility into locations/groups/other user models.
Have you explored that feature set and identified whether it would be
applicable to your use case?
-Clayton
···
On Fri, Jun 2, 2017 at 8:41 PM, John Harper wrote:
Home - CommCare Public - CommCare Public
Assigning+cases+to+one+of+multiple+groups
on import of new survey's the default static user group is assigned to the
case in our application.
I have added a Case Sharing logistics form that will allow a supervisor to
assign the case to the correct group based on case properties........
this is working great but my supervisors want to go to a further
level..........they would like to add a secondary level to this so they can
select a distinct FLW from the case sharing group selected as the owner_id
not just the group level.
any suggestions on modifying the above totorial?
i thought maybe we would have a simular instance such as *jr://fixture/user instead
of **jr://fixture/user-groups . *
or a cascading select from the selected case sharing group from which
they could select the team member.........
your thoughts?
--
You received this message because you are subscribed to the Google Groups
"commcare-users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to commcare-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
yes I have and would be open to use the hierarchy groups to accomplish this
but the work flow that is in place is that the survey request comes from a
third party system which assigns the case to a owner group (supervisors)
this group has the assignment to send the case to the appropriate FLW.
currently they are assigning them to a case sharing group from which the
techs have to select from this group. The end goal is to allow the
supervisor to assign to a group as is currently done now...or go to the
individual if required.
Can we get down to this level or is the case group as far as we can go?
This is done in the field and the supervisors do not come into an office
most of the work week.
···
On Monday, June 5, 2017 at 7:21:46 AM UTC-7, Clayton Sims wrote:
>
> Hi John!
>
> In general programs who need that level of complexity for ownership
> hierarchies and data manipulation have more success moving their project to
> using the Organizations feature
> as a
> way to gain visibility into locations/groups/other user models.
>
> Have you explored that feature set and identified whether it would be
> applicable to your use case?
>
> -Clayton
>
> On Fri, Jun 2, 2017 at 8:41 PM, John Harper <john....@grableservices.com > wrote:
>
>>
>> https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups
>>
>>
>> on import of new survey's the default static user group is assigned to
>> the case in our application.
>>
>> I have added a Case Sharing logistics form that will allow a supervisor
>> to assign the case to the correct group based on case properties........
>>
>> this is working great but my supervisors want to go to a further
>> level..........they would like to add a secondary level to this so they can
>> select a distinct FLW from the case sharing group selected as the owner_id
>> not just the group level.
>>
>>
>> any suggestions on modifying the above totorial?
>>
>> i thought maybe we would have a simular instance such as *jr://fixture/user instead
>> of **jr://fixture/user-groups . *
>>
>>
>> *or a cascading select from the selected case sharing group from which
>> they could select the team member.........*
>>
>>
>> *your thoughts?*
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "commcare-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to commcare-user...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
Hi John,
I would probably solve that workflow by creating a Location which
represents the "landing location" for each user.
Unfortunately we don't have a clean way currently to produce a set of
groups which should be visible to a user outside of the Locations
infrastructure, so that's the most straightforward way to ensure that cases
can be assigned out.
One advantage of that solution is that you can also configure that setup to
allow the "parent" location (which supervisors would be a member of) to
include the cases which are assigned to any sub-location, which is a common
use case for the "Delegation" type workflows you are describing, and is
quite hard to accomplish with pure Case Sharing Groups
-Clayton
···
On Mon, Jun 5, 2017 at 7:31 PM, John Harper wrote:
yes I have and would be open to use the hierarchy groups to accomplish
this but the work flow that is in place is that the survey request comes
from a third party system which assigns the case to a owner group
(supervisors)
this group has the assignment to send the case to the appropriate FLW.
currently they are assigning them to a case sharing group from which the
techs have to select from this group. The end goal is to allow the
supervisor to assign to a group as is currently done now...or go to the
individual if required.
Can we get down to this level or is the case group as far as we can go?
This is done in the field and the supervisors do not come into an office
most of the work week.
On Monday, June 5, 2017 at 7:21:46 AM UTC-7, Clayton Sims wrote:
Hi John!
In general programs who need that level of complexity for ownership
hierarchies and data manipulation have more success moving their project to
using the Organizations feature
https://confluence.dimagi.com/display/commcarepublic/Organizations as
a way to gain visibility into locations/groups/other user models.
Have you explored that feature set and identified whether it would be
applicable to your use case?
-Clayton
On Fri, Jun 2, 2017 at 8:41 PM, John Harper john....@grableservices.com wrote:
https://confluence.dimagi.com/display/commcarepublic/Assigni
ng+cases+to+one+of+multiple+groups
on import of new survey's the default static user group is assigned to
the case in our application.
I have added a Case Sharing logistics form that will allow a supervisor
to assign the case to the correct group based on case properties........
this is working great but my supervisors want to go to a further
level..........they would like to add a secondary level to this so they can
select a distinct FLW from the case sharing group selected as the owner_id
not just the group level.
any suggestions on modifying the above totorial?
i thought maybe we would have a simular instance such as *jr://fixture/user instead
of **jr://fixture/user-groups . *
or a cascading select from the selected case sharing group from which
they could select the team member.........
your thoughts?
--
You received this message because you are subscribed to the Google
Groups "commcare-users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to commcare-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"commcare-users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to commcare-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
This does give me some advantages but it also may not work for my
application. I still require that the Supervisor group be able to use the
android app to reassign the survey request as it is comes into the system.
can this same functionality be accomplished by assigning a lookup of the
organizational hierarchy?
···
On Tuesday, June 6, 2017 at 8:38:44 AM UTC-7, Clayton Sims wrote:
>
> Hi John,
>
> I would probably solve that workflow by creating a Location which
> represents the "landing location" for each user.
>
> Unfortunately we don't have a clean way currently to produce a set of
> groups which should be visible to a user outside of the Locations
> infrastructure, so that's the most straightforward way to ensure that cases
> can be assigned out.
>
> One advantage of that solution is that you can also configure that setup
> to allow the "parent" location (which supervisors would be a member of) to
> include the cases which are assigned to any sub-location, which is a common
> use case for the "Delegation" type workflows you are describing, and is
> quite hard to accomplish with pure Case Sharing Groups
>
> -Clayton
>
> On Mon, Jun 5, 2017 at 7:31 PM, John Harper <john....@grableservices.com > wrote:
>
>> yes I have and would be open to use the hierarchy groups to accomplish
>> this but the work flow that is in place is that the survey request comes
>> from a third party system which assigns the case to a owner group
>> (supervisors)
>>
>> this group has the assignment to send the case to the appropriate FLW.
>> currently they are assigning them to a case sharing group from which the
>> techs have to select from this group. The end goal is to allow the
>> supervisor to assign to a group as is currently done now...or go to the
>> individual if required.
>>
>> Can we get down to this level or is the case group as far as we can go?
>>
>> This is done in the field and the supervisors do not come into an office
>> most of the work week.
>>
>>
>> On Monday, June 5, 2017 at 7:21:46 AM UTC-7, Clayton Sims wrote:
>>>
>>> Hi John!
>>>
>>> In general programs who need that level of complexity for ownership
>>> hierarchies and data manipulation have more success moving their project to
>>> using the Organizations feature
>>> as
>>> a way to gain visibility into locations/groups/other user models.
>>>
>>> Have you explored that feature set and identified whether it would be
>>> applicable to your use case?
>>>
>>> -Clayton
>>>
>>> On Fri, Jun 2, 2017 at 8:41 PM, John Harper >>
>>>>
>>>> https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups
>>>>
>>>>
>>>> on import of new survey's the default static user group is assigned to
>>>> the case in our application.
>>>>
>>>> I have added a Case Sharing logistics form that will allow a supervisor
>>>> to assign the case to the correct group based on case properties........
>>>>
>>>> this is working great but my supervisors want to go to a further
>>>> level..........they would like to add a secondary level to this so they can
>>>> select a distinct FLW from the case sharing group selected as the owner_id
>>>> not just the group level.
>>>>
>>>>
>>>> any suggestions on modifying the above totorial?
>>>>
>>>> i thought maybe we would have a simular instance such as *jr://fixture/user instead
>>>> of **jr://fixture/user-groups . *
>>>>
>>>>
>>>> *or a cascading select from the selected case sharing group from which
>>>> they could select the team member.........*
>>>>
>>>>
>>>> *your thoughts?*
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "commcare-users" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to commcare-user...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "commcare-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to commcare-user...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
Hi John,
The supervisors would be able to use the android app in either case, and
you could use either the Location hierarchy to assign survey requests to a
"higher level" location or you could use a case sharing group, users are
allowed to be in both types of sharing groups.
The question I believe you were trying to track down is the destination
groups themselves, and the only real way to get a "target" group to assign
a case to is to use the organizational hierarchy and to create a leaf entry
for each individual who can have something assigned to them. We don't yet
have the capacity to reveal the user id of the individual users who are
inside of each organizational level.
-Clayton
···
On Tue, Jun 6, 2017 at 1:23 PM, John Harper wrote:
This does give me some advantages but it also may not work for my
application. I still require that the Supervisor group be able to use the
android app to reassign the survey request as it is comes into the system.
can this same functionality be accomplished by assigning a lookup of the
organizational hierarchy?
On Tuesday, June 6, 2017 at 8:38:44 AM UTC-7, Clayton Sims wrote:
Hi John,
I would probably solve that workflow by creating a Location which
represents the "landing location" for each user.
Unfortunately we don't have a clean way currently to produce a set of
groups which should be visible to a user outside of the Locations
infrastructure, so that's the most straightforward way to ensure that cases
can be assigned out.
One advantage of that solution is that you can also configure that setup
to allow the "parent" location (which supervisors would be a member of) to
include the cases which are assigned to any sub-location, which is a common
use case for the "Delegation" type workflows you are describing, and is
quite hard to accomplish with pure Case Sharing Groups
-Clayton
On Mon, Jun 5, 2017 at 7:31 PM, John Harper john....@grableservices.com wrote:
yes I have and would be open to use the hierarchy groups to accomplish
this but the work flow that is in place is that the survey request comes
from a third party system which assigns the case to a owner group
(supervisors)
this group has the assignment to send the case to the appropriate FLW.
currently they are assigning them to a case sharing group from which the
techs have to select from this group. The end goal is to allow the
supervisor to assign to a group as is currently done now...or go to the
individual if required.
Can we get down to this level or is the case group as far as we can go?
This is done in the field and the supervisors do not come into an office
most of the work week.
On Monday, June 5, 2017 at 7:21:46 AM UTC-7, Clayton Sims wrote:
Hi John!
In general programs who need that level of complexity for ownership
hierarchies and data manipulation have more success moving their project to
using the Organizations feature
https://confluence.dimagi.com/display/commcarepublic/Organizations as
a way to gain visibility into locations/groups/other user models.
Have you explored that feature set and identified whether it would be
applicable to your use case?
-Clayton
On Fri, Jun 2, 2017 at 8:41 PM, John Harper < john....@grableservices.com> wrote:
https://confluence.dimagi.com/display/commcarepublic/Assigni
ng+cases+to+one+of+multiple+groups
on import of new survey's the default static user group is assigned to
the case in our application.
I have added a Case Sharing logistics form that will allow a
supervisor to assign the case to the correct group based on case
properties........
this is working great but my supervisors want to go to a further
level..........they would like to add a secondary level to this so they can
select a distinct FLW from the case sharing group selected as the owner_id
not just the group level.
any suggestions on modifying the above totorial?
i thought maybe we would have a simular instance such as *jr://fixture/user instead
of **jr://fixture/user-groups . *
or a cascading select from the selected case sharing group from which
they could select the team member.........
your thoughts?
--
You received this message because you are subscribed to the Google
Groups "commcare-users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to commcare-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "commcare-users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to commcare-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"commcare-users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to commcare-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Thank Clayton,
This makes sense,
One more question that has come up on this ........Will the supervisor
still only see the locations that are in their logical tree path? (as long
as that level has been checked -can see child records-)
- On a personal note its nice to reconnect with you........I was looking
through some of my old and more detailed posts on the ODK users group on
cascading selects within repeat groups and we had quite the trail going
back and forth a few years back
Thanks again for the time you put into this endeavor...........very much
appreciate your effort.
···
On Wednesday, June 7, 2017 at 11:19:54 AM UTC-7, Clayton Sims wrote:
>
> Hi John,
>
> The supervisors would be able to use the android app in either case, and
> you could use either the Location hierarchy to assign survey requests to a
> "higher level" location or you could use a case sharing group, users are
> allowed to be in both types of sharing groups.
>
> The question I believe you were trying to track down is the destination
> groups themselves, and the only real way to get a "target" group to assign
> a case to is to use the organizational hierarchy and to create a leaf entry
> for each individual who can have something assigned to them. We don't yet
> have the capacity to reveal the user id of the individual users who are
> inside of each organizational level.
>
> -Clayton
>
> On Tue, Jun 6, 2017 at 1:23 PM, John Harper <john....@grableservices.com > wrote:
>
>> This does give me some advantages but it also may not work for my
>> application. I still require that the Supervisor group be able to use the
>> android app to reassign the survey request as it is comes into the system.
>>
>> can this same functionality be accomplished by assigning a lookup of the
>> organizational hierarchy?
>>
>>
>>
>> On Tuesday, June 6, 2017 at 8:38:44 AM UTC-7, Clayton Sims wrote:
>>>
>>> Hi John,
>>>
>>> I would probably solve that workflow by creating a Location which
>>> represents the "landing location" for each user.
>>>
>>> Unfortunately we don't have a clean way currently to produce a set of
>>> groups which should be visible to a user outside of the Locations
>>> infrastructure, so that's the most straightforward way to ensure that cases
>>> can be assigned out.
>>>
>>> One advantage of that solution is that you can also configure that setup
>>> to allow the "parent" location (which supervisors would be a member of) to
>>> include the cases which are assigned to any sub-location, which is a common
>>> use case for the "Delegation" type workflows you are describing, and is
>>> quite hard to accomplish with pure Case Sharing Groups
>>>
>>> -Clayton
>>>
>>> On Mon, Jun 5, 2017 at 7:31 PM, John Harper >>
>>>> yes I have and would be open to use the hierarchy groups to accomplish
>>>> this but the work flow that is in place is that the survey request comes
>>>> from a third party system which assigns the case to a owner group
>>>> (supervisors)
>>>>
>>>> this group has the assignment to send the case to the appropriate FLW.
>>>> currently they are assigning them to a case sharing group from which the
>>>> techs have to select from this group. The end goal is to allow the
>>>> supervisor to assign to a group as is currently done now...or go to the
>>>> individual if required.
>>>>
>>>> Can we get down to this level or is the case group as far as we can go?
>>>>
>>>> This is done in the field and the supervisors do not come into an
>>>> office most of the work week.
>>>>
>>>>
>>>> On Monday, June 5, 2017 at 7:21:46 AM UTC-7, Clayton Sims wrote:
>>>>>
>>>>> Hi John!
>>>>>
>>>>> In general programs who need that level of complexity for ownership
>>>>> hierarchies and data manipulation have more success moving their project to
>>>>> using the Organizations feature
>>>>> as
>>>>> a way to gain visibility into locations/groups/other user models.
>>>>>
>>>>> Have you explored that feature set and identified whether it would be
>>>>> applicable to your use case?
>>>>>
>>>>> -Clayton
>>>>>
>>>>> On Fri, Jun 2, 2017 at 8:41 PM, John Harper < john....@grableservices.com> wrote:
>>>>>
>>>>>>
>>>>>> https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups
>>>>>>
>>>>>>
>>>>>> on import of new survey's the default static user group is assigned
>>>>>> to the case in our application.
>>>>>>
>>>>>> I have added a Case Sharing logistics form that will allow a
>>>>>> supervisor to assign the case to the correct group based on case
>>>>>> properties........
>>>>>>
>>>>>> this is working great but my supervisors want to go to a further
>>>>>> level..........they would like to add a secondary level to this so they can
>>>>>> select a distinct FLW from the case sharing group selected as the owner_id
>>>>>> not just the group level.
>>>>>>
>>>>>>
>>>>>> any suggestions on modifying the above totorial?
>>>>>>
>>>>>> i thought maybe we would have a simular instance such as *jr://fixture/user instead
>>>>>> of **jr://fixture/user-groups . *
>>>>>>
>>>>>>
>>>>>> *or a cascading select from the selected case sharing group from
>>>>>> which they could select the team member.........*
>>>>>>
>>>>>>
>>>>>> *your thoughts?*
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "commcare-users" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to commcare-user...@googlegroups.com.
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "commcare-users" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to commcare-user...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "commcare-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to commcare-user...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
Hi John,
Funny to hear about the previous posts! Super happy that we are able to
finally manage some of these core cascading workflows.
By default with the organizations feature, the users won't see any
locations which are not in their tree path, and if you choose "can see
child records", they will only see the records of locations which
sub-locations of their assigned location. They won't see the records (or
existence) of sub-locations from other tree paths.
-Clayton
···
On Fri, Jun 9, 2017 at 10:50 AM, John Harper <john.harper@grableservices.com wrote:
Thank Clayton,
This makes sense,
One more question that has come up on this ........Will the supervisor
still only see the locations that are in their logical tree path? (as long
as that level has been checked -can see child records-)
- On a personal note its nice to reconnect with you........I was looking
through some of my old and more detailed posts on the ODK users group on
cascading selects within repeat groups and we had quite the trail going
back and forth a few years back
Thanks again for the time you put into this endeavor...........very much
appreciate your effort.
On Wednesday, June 7, 2017 at 11:19:54 AM UTC-7, Clayton Sims wrote:
Hi John,
The supervisors would be able to use the android app in either case, and
you could use either the Location hierarchy to assign survey requests to a
"higher level" location or you could use a case sharing group, users are
allowed to be in both types of sharing groups.
The question I believe you were trying to track down is the destination
groups themselves, and the only real way to get a "target" group to assign
a case to is to use the organizational hierarchy and to create a leaf entry
for each individual who can have something assigned to them. We don't yet
have the capacity to reveal the user id of the individual users who are
inside of each organizational level.
-Clayton
On Tue, Jun 6, 2017 at 1:23 PM, John Harper john....@grableservices.com wrote:
This does give me some advantages but it also may not work for my
application. I still require that the Supervisor group be able to use the
android app to reassign the survey request as it is comes into the system.
can this same functionality be accomplished by assigning a lookup of the
organizational hierarchy?
On Tuesday, June 6, 2017 at 8:38:44 AM UTC-7, Clayton Sims wrote:
Hi John,
I would probably solve that workflow by creating a Location which
represents the "landing location" for each user.
Unfortunately we don't have a clean way currently to produce a set of
groups which should be visible to a user outside of the Locations
infrastructure, so that's the most straightforward way to ensure that cases
can be assigned out.
One advantage of that solution is that you can also configure that
setup to allow the "parent" location (which supervisors would be a member
of) to include the cases which are assigned to any sub-location, which is a
common use case for the "Delegation" type workflows you are describing, and
is quite hard to accomplish with pure Case Sharing Groups
-Clayton
On Mon, Jun 5, 2017 at 7:31 PM, John Harper < john....@grableservices.com> wrote:
yes I have and would be open to use the hierarchy groups to accomplish
this but the work flow that is in place is that the survey request comes
from a third party system which assigns the case to a owner group
(supervisors)
this group has the assignment to send the case to the appropriate FLW.
currently they are assigning them to a case sharing group from which the
techs have to select from this group. The end goal is to allow the
supervisor to assign to a group as is currently done now...or go to the
individual if required.
Can we get down to this level or is the case group as far as we can go?
This is done in the field and the supervisors do not come into an
office most of the work week.
On Monday, June 5, 2017 at 7:21:46 AM UTC-7, Clayton Sims wrote:
Hi John!
In general programs who need that level of complexity for ownership
hierarchies and data manipulation have more success moving their project to
using the Organizations feature
https://confluence.dimagi.com/display/commcarepublic/Organizations as
a way to gain visibility into locations/groups/other user models.
Have you explored that feature set and identified whether it would be
applicable to your use case?
-Clayton
On Fri, Jun 2, 2017 at 8:41 PM, John Harper < john....@grableservices.com> wrote:
https://confluence.dimagi.com/display/commcarepublic/Assigni
ng+cases+to+one+of+multiple+groups
on import of new survey's the default static user group is assigned
to the case in our application.
I have added a Case Sharing logistics form that will allow a
supervisor to assign the case to the correct group based on case
properties........
this is working great but my supervisors want to go to a further
level..........they would like to add a secondary level to this so they can
select a distinct FLW from the case sharing group selected as the owner_id
not just the group level.
any suggestions on modifying the above totorial?
i thought maybe we would have a simular instance such as *jr://fixture/user instead
of **jr://fixture/user-groups . *
or a cascading select from the selected case sharing group from
which they could select the team member.........
your thoughts?
--
You received this message because you are subscribed to the Google
Groups "commcare-users" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to commcare-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "commcare-users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to commcare-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "commcare-users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to commcare-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"commcare-users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to commcare-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.