Requesting Help/Insight Identifying Work-Around(s) for Modifying Cases Using Group[ed] Users

Dear Fellow CommCare Users and Implementers,
We hope this finds you doing well. We are writing to request your thoughts
and insights on group[ed] users in CommCareHQ. [Apologies in advance for
the lengthy post, but wanted to provide as much detail as possible.]

We are working on a project in Ethiopia that requires regional users for a
catchment area and individual users within that catchment area. The set-up
is such that the individual users, who are Health Extension Workers (HEWs),
are mobile users, and for each mobile user, a case has been set up. The
case represents the individual (HEW) and includes key data points like
their name, location, mobile phone number (if available) and health center
that they work in. The regional users are office-based data entry personnel
who have access to the same forms but use CloudCare and to submit the form
on behalf of the HEW.

To submit forms on behalf of the HEW, the regional user is linked to each
of the mobile workers and the corresponding "case". The regional user then
selects a case in CloudCare and is able to open the form under that case
and enter the data and submit.

Therefore, we have the regional user linked to each of the individual users
for that region. Hence, group[ed] users.

However, we have found that registering and modifying a case (i.e., an HEW
relocates to another health post in the same region) as a regional user has
posed problems. Since the regional user has been grouped, an error message
pops up to notify us that grouped users can not submit such modifying
information.

To address this problem--at least for registering new HEWs (or cases), we
thought we could set up a new user that was not grouped. This ungrouped
user could then register a new HEW (or case) in CloudCare, then work could
be done to properly group the HEW into the appropriate region and create a
mobile user to link to that new case after the initial registration. This
has worked fine.

Where we have been having issues is to modify an existing case. Since the
ungrouped user is 'new', it does not have all of the HEW data (or cases)
that the regional users have -- therefore, there is no way to select the
appropriate HEW (or case) to modify. And if we try and modify HEW data (or
a case), we receive an error message notifying us that group[ed] users can
not make such changes in the CommCare system at this time.

Have any of you run into a similar issue? Do any of you have insight
and/or suggestions on this issue? Please advise.

Thank you and if you require more information or clarification, please do
not hesitate to let us know.

With much appreciation,
Nadi Nina Kaonga (on behalf of colleagues)

While I'm not sure if this will help (or simply cause confusion), the image
below illustrates the design we have settled on for a similar scenario.

I think the key difference between your design and this one is that we
decided model each community as a CommCare case, rather than each CHW. We
create one sharing group for each community and put the CHW and health post
nurse into this group. The design allows us to put as many users as
desired into each sharing group --- essentially changing the list of people
providing care to any community. Each community case is owned by the
sharing group created for that community and each sub-case of the community
has been setup to inherit the owner of the community case.
[note: the auto-inheritance of ownership require custom-coded xform code;
the Wiki [1] includes some documentation to handle situations where a user
belongs to more than one sharing group]

This seems to make it easier to handle situations where CHWs are assigned
to more/less/different communities, although other scenarios could become
more challenging to address.

Cheers, Ray

1 -
https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups

[image: Inline image 1]

··· On Thu, Jan 24, 2013 at 10:12 AM, Nadi Kaonga wrote:

Dear Fellow CommCare Users and Implementers,
We hope this finds you doing well. We are writing to request your
thoughts and insights on group[ed] users in CommCareHQ. [Apologies in
advance for the lengthy post, but wanted to provide as much detail as
possible.]

We are working on a project in Ethiopia that requires regional users for a
catchment area and individual users within that catchment area. The set-up
is such that the individual users, who are Health Extension Workers (HEWs),
are mobile users, and for each mobile user, a case has been set up. The
case represents the individual (HEW) and includes key data points like
their name, location, mobile phone number (if available) and health center
that they work in. The regional users are office-based data entry personnel
who have access to the same forms but use CloudCare and to submit the form
on behalf of the HEW.

To submit forms on behalf of the HEW, the regional user is linked to each
of the mobile workers and the corresponding "case". The regional user then
selects a case in CloudCare and is able to open the form under that case
and enter the data and submit.

Therefore, we have the regional user linked to each of the individual
users for that region. Hence, group[ed] users.

However, we have found that registering and modifying a case (i.e., an HEW
relocates to another health post in the same region) as a regional user has
posed problems. Since the regional user has been grouped, an error message
pops up to notify us that grouped users can not submit such modifying
information.

To address this problem--at least for registering new HEWs (or cases), we
thought we could set up a new user that was not grouped. This ungrouped
user could then register a new HEW (or case) in CloudCare, then work could
be done to properly group the HEW into the appropriate region and create a
mobile user to link to that new case after the initial registration. This
has worked fine.

Where we have been having issues is to modify an existing case. Since the
ungrouped user is 'new', it does not have all of the HEW data (or cases)
that the regional users have -- therefore, there is no way to select the
appropriate HEW (or case) to modify. And if we try and modify HEW data (or
a case), we receive an error message notifying us that group[ed] users can
not make such changes in the CommCare system at this time.

Have any of you run into a similar issue? Do any of you have insight
and/or suggestions on this issue? Please advise.

Thank you and if you require more information or clarification, please do
not hesitate to let us know.

With much appreciation,
Nadi Nina Kaonga (on behalf of colleagues)

--
Ray Brunsting, CTO, Tula Foundation / www.tula.org

Hi Nadi,

I'm having a hard time totally understanding the exact use case/problem
you're describing, but I think it's possible that it boils down to
something quite simple:

How can I assign a case (HEW) from one group (region) to another in
CommCare HQ?

I know you've been using cloudcare for most of your workflows, but possibly
the reassign cases tool[1] will be able to do this for you?

Apologies if I've vastly misunderstood what you need to do and gotten this
all wrong, and please feel free to clarify.

thanks,
Cory

[1] Log In - Dimagi Confluence

··· On Fri, Jan 25, 2013 at 8:50 AM, Ray Brunsting wrote:

While I'm not sure if this will help (or simply cause confusion), the
image below illustrates the design we have settled on for a similar
scenario.

I think the key difference between your design and this one is that we
decided model each community as a CommCare case, rather than each CHW. We
create one sharing group for each community and put the CHW and health post
nurse into this group. The design allows us to put as many users as
desired into each sharing group --- essentially changing the list of people
providing care to any community. Each community case is owned by the
sharing group created for that community and each sub-case of the community
has been setup to inherit the owner of the community case.
[note: the auto-inheritance of ownership require custom-coded xform
code; the Wiki [1] includes some documentation to handle situations where a
user belongs to more than one sharing group]

This seems to make it easier to handle situations where CHWs are assigned
to more/less/different communities, although other scenarios could become
more challenging to address.

Cheers, Ray

1 -
https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups

[image: Inline image 1]

On Thu, Jan 24, 2013 at 10:12 AM, Nadi Kaonga nkaonga@gmail.com wrote:

Dear Fellow CommCare Users and Implementers,
We hope this finds you doing well. We are writing to request your
thoughts and insights on group[ed] users in CommCareHQ. [Apologies in
advance for the lengthy post, but wanted to provide as much detail as
possible.]

We are working on a project in Ethiopia that requires regional users for
a catchment area and individual users within that catchment area. The
set-up is such that the individual users, who are Health Extension Workers
(HEWs), are mobile users, and for each mobile user, a case has been set up.
The case represents the individual (HEW) and includes key data points like
their name, location, mobile phone number (if available) and health center
that they work in. The regional users are office-based data entry personnel
who have access to the same forms but use CloudCare and to submit the form
on behalf of the HEW.

To submit forms on behalf of the HEW, the regional user is linked to each
of the mobile workers and the corresponding "case". The regional user then
selects a case in CloudCare and is able to open the form under that case
and enter the data and submit.

Therefore, we have the regional user linked to each of the individual
users for that region. Hence, group[ed] users.

However, we have found that registering and modifying a case (i.e., an
HEW relocates to another health post in the same region) as a regional user
has posed problems. Since the regional user has been grouped, an error
message pops up to notify us that grouped users can not submit such
modifying information.

To address this problem--at least for registering new HEWs (or cases), we
thought we could set up a new user that was not grouped. This ungrouped
user could then register a new HEW (or case) in CloudCare, then work could
be done to properly group the HEW into the appropriate region and create a
mobile user to link to that new case after the initial registration. This
has worked fine.

Where we have been having issues is to modify an existing case. Since
the ungrouped user is 'new', it does not have all of the HEW data (or
cases) that the regional users have -- therefore, there is no way to select
the appropriate HEW (or case) to modify. And if we try and modify HEW data
(or a case), we receive an error message notifying us that group[ed] users
can not make such changes in the CommCare system at this time.

Have any of you run into a similar issue? Do any of you have insight
and/or suggestions on this issue? Please advise.

Thank you and if you require more information or clarification, please do
not hesitate to let us know.

With much appreciation,
Nadi Nina Kaonga (on behalf of colleagues)

--
Ray Brunsting, CTO, Tula Foundation / www.tula.org

Dear Ray,
Thank you very much for the feedback and the information. With your custom
case-sharing setting, have you been able to easily modify cases?

Dear Cory,
That is not exactly the problem, but may work towards the solution. My
only concern is if we re-assign cases to another user (from the region
user) and then modify the case, would that alter any of the form
submissions that that case has made? Please advise.

Thank you both and we are looking forward to hearing back from you.

All the best,

··· -- Nadi Nina Kaonga

On Mon, Jan 28, 2013 at 6:54 PM, Cory Zue czue@dimagi.com wrote:

Hi Nadi,

I'm having a hard time totally understanding the exact use case/problem
you're describing, but I think it's possible that it boils down to
something quite simple:

How can I assign a case (HEW) from one group (region) to another in
CommCare HQ?

I know you've been using cloudcare for most of your workflows, but
possibly the reassign cases tool[1] will be able to do this for you?

Apologies if I've vastly misunderstood what you need to do and gotten this
all wrong, and please feel free to clarify.

thanks,
Cory

[1]
Log In - Dimagi Confluence

On Fri, Jan 25, 2013 at 8:50 AM, Ray Brunsting ray@tula.org wrote:

While I'm not sure if this will help (or simply cause confusion), the
image below illustrates the design we have settled on for a similar
scenario.

I think the key difference between your design and this one is that we
decided model each community as a CommCare case, rather than each CHW. We
create one sharing group for each community and put the CHW and health post
nurse into this group. The design allows us to put as many users as
desired into each sharing group --- essentially changing the list of people
providing care to any community. Each community case is owned by the
sharing group created for that community and each sub-case of the community
has been setup to inherit the owner of the community case.
[note: the auto-inheritance of ownership require custom-coded xform
code; the Wiki [1] includes some documentation to handle situations where a
user belongs to more than one sharing group]

This seems to make it easier to handle situations where CHWs are assigned
to more/less/different communities, although other scenarios could become
more challenging to address.

Cheers, Ray

1 -
https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups

[image: Inline image 1]

On Thu, Jan 24, 2013 at 10:12 AM, Nadi Kaonga nkaonga@gmail.com wrote:

Dear Fellow CommCare Users and Implementers,
We hope this finds you doing well. We are writing to request your
thoughts and insights on group[ed] users in CommCareHQ. [Apologies in
advance for the lengthy post, but wanted to provide as much detail as
possible.]

We are working on a project in Ethiopia that requires regional users for
a catchment area and individual users within that catchment area. The
set-up is such that the individual users, who are Health Extension Workers
(HEWs), are mobile users, and for each mobile user, a case has been set up.
The case represents the individual (HEW) and includes key data points like
their name, location, mobile phone number (if available) and health center
that they work in. The regional users are office-based data entry personnel
who have access to the same forms but use CloudCare and to submit the form
on behalf of the HEW.

To submit forms on behalf of the HEW, the regional user is linked to
each of the mobile workers and the corresponding "case". The regional user
then selects a case in CloudCare and is able to open the form under that
case and enter the data and submit.

Therefore, we have the regional user linked to each of the individual
users for that region. Hence, group[ed] users.

However, we have found that registering and modifying a case (i.e., an
HEW relocates to another health post in the same region) as a regional user
has posed problems. Since the regional user has been grouped, an error
message pops up to notify us that grouped users can not submit such
modifying information.

To address this problem--at least for registering new HEWs (or cases),
we thought we could set up a new user that was not grouped. This ungrouped
user could then register a new HEW (or case) in CloudCare, then work could
be done to properly group the HEW into the appropriate region and create a
mobile user to link to that new case after the initial registration. This
has worked fine.

Where we have been having issues is to modify an existing case. Since
the ungrouped user is 'new', it does not have all of the HEW data (or
cases) that the regional users have -- therefore, there is no way to select
the appropriate HEW (or case) to modify. And if we try and modify HEW data
(or a case), we receive an error message notifying us that group[ed] users
can not make such changes in the CommCare system at this time.

Have any of you run into a similar issue? Do any of you have insight
and/or suggestions on this issue? Please advise.

Thank you and if you require more information or clarification, please
do not hesitate to let us know.

With much appreciation,
Nadi Nina Kaonga (on behalf of colleagues)

--
Ray Brunsting, CTO, Tula Foundation / www.tula.org

--
You received this message because you are subscribed to the Google Groups
"commcare-users" group.
To unsubscribe from this group, send email to
commcare-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

That is not exactly the problem, but may work towards the solution. My
only concern is if we re-assign cases to another user (from the region
user) and then modify the case, would that alter any of the form
submissions that that case has made? Please advise.

It shouldn't touch any of the previous form submissions. It will be like a
new submission was made that just updates the case ownership.

Cory

··· On Mon, Jan 28, 2013 at 9:02 PM, Nadi Kaonga wrote:

Thank you both and we are looking forward to hearing back from you.

All the best,

--
Nadi Nina Kaonga

On Mon, Jan 28, 2013 at 6:54 PM, Cory Zue czue@dimagi.com wrote:

Hi Nadi,

I'm having a hard time totally understanding the exact use case/problem
you're describing, but I think it's possible that it boils down to
something quite simple:

How can I assign a case (HEW) from one group (region) to another in
CommCare HQ?

I know you've been using cloudcare for most of your workflows, but
possibly the reassign cases tool[1] will be able to do this for you?

Apologies if I've vastly misunderstood what you need to do and gotten
this all wrong, and please feel free to clarify.

thanks,
Cory

[1]
Log In - Dimagi Confluence

On Fri, Jan 25, 2013 at 8:50 AM, Ray Brunsting ray@tula.org wrote:

While I'm not sure if this will help (or simply cause confusion), the
image below illustrates the design we have settled on for a similar
scenario.

I think the key difference between your design and this one is that we
decided model each community as a CommCare case, rather than each CHW. We
create one sharing group for each community and put the CHW and health post
nurse into this group. The design allows us to put as many users as
desired into each sharing group --- essentially changing the list of people
providing care to any community. Each community case is owned by the
sharing group created for that community and each sub-case of the community
has been setup to inherit the owner of the community case.
[note: the auto-inheritance of ownership require custom-coded xform
code; the Wiki [1] includes some documentation to handle situations where a
user belongs to more than one sharing group]

This seems to make it easier to handle situations where CHWs are
assigned to more/less/different communities, although other scenarios could
become more challenging to address.

Cheers, Ray

1 -
https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups

[image: Inline image 1]

On Thu, Jan 24, 2013 at 10:12 AM, Nadi Kaonga nkaonga@gmail.com wrote:

Dear Fellow CommCare Users and Implementers,
We hope this finds you doing well. We are writing to request your
thoughts and insights on group[ed] users in CommCareHQ. [Apologies in
advance for the lengthy post, but wanted to provide as much detail as
possible.]

We are working on a project in Ethiopia that requires regional users
for a catchment area and individual users within that catchment area. The
set-up is such that the individual users, who are Health Extension Workers
(HEWs), are mobile users, and for each mobile user, a case has been set up.
The case represents the individual (HEW) and includes key data points like
their name, location, mobile phone number (if available) and health center
that they work in. The regional users are office-based data entry personnel
who have access to the same forms but use CloudCare and to submit the form
on behalf of the HEW.

To submit forms on behalf of the HEW, the regional user is linked to
each of the mobile workers and the corresponding "case". The regional user
then selects a case in CloudCare and is able to open the form under that
case and enter the data and submit.

Therefore, we have the regional user linked to each of the individual
users for that region. Hence, group[ed] users.

However, we have found that registering and modifying a case (i.e., an
HEW relocates to another health post in the same region) as a regional user
has posed problems. Since the regional user has been grouped, an error
message pops up to notify us that grouped users can not submit such
modifying information.

To address this problem--at least for registering new HEWs (or cases),
we thought we could set up a new user that was not grouped. This ungrouped
user could then register a new HEW (or case) in CloudCare, then work could
be done to properly group the HEW into the appropriate region and create a
mobile user to link to that new case after the initial registration. This
has worked fine.

Where we have been having issues is to modify an existing case. Since
the ungrouped user is 'new', it does not have all of the HEW data (or
cases) that the regional users have -- therefore, there is no way to select
the appropriate HEW (or case) to modify. And if we try and modify HEW data
(or a case), we receive an error message notifying us that group[ed] users
can not make such changes in the CommCare system at this time.

Have any of you run into a similar issue? Do any of you have insight
and/or suggestions on this issue? Please advise.

Thank you and if you require more information or clarification, please
do not hesitate to let us know.

With much appreciation,
Nadi Nina Kaonga (on behalf of colleagues)

--
Ray Brunsting, CTO, Tula Foundation / www.tula.org

--
You received this message because you are subscribed to the Google Groups
"commcare-users" group.
To unsubscribe from this group, send email to
commcare-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
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/groups/opt_out.

Re: "With your custom case-sharing setting, have you been able to easily
modify cases?
"
While it has been working fine in testing, we don't yet have any field
experience with case-sharing. I'd be interested to hear how your final
design works out.

Best regards, Ray

··· On Mon, Jan 28, 2013 at 9:02 PM, Nadi Kaonga wrote:

Dear Ray,
Thank you very much for the feedback and the information. With your
custom case-sharing setting, have you been able to easily modify cases?

Dear Cory,
That is not exactly the problem, but may work towards the solution. My
only concern is if we re-assign cases to another user (from the region
user) and then modify the case, would that alter any of the form
submissions that that case has made? Please advise.

Thank you both and we are looking forward to hearing back from you.

All the best,

--
Nadi Nina Kaonga

On Mon, Jan 28, 2013 at 6:54 PM, Cory Zue czue@dimagi.com wrote:

Hi Nadi,

I'm having a hard time totally understanding the exact use case/problem
you're describing, but I think it's possible that it boils down to
something quite simple:

How can I assign a case (HEW) from one group (region) to another in
CommCare HQ?

I know you've been using cloudcare for most of your workflows, but
possibly the reassign cases tool[1] will be able to do this for you?

Apologies if I've vastly misunderstood what you need to do and gotten
this all wrong, and please feel free to clarify.

thanks,
Cory

[1]
Log In - Dimagi Confluence

On Fri, Jan 25, 2013 at 8:50 AM, Ray Brunsting ray@tula.org wrote:

While I'm not sure if this will help (or simply cause confusion), the
image below illustrates the design we have settled on for a similar
scenario.

I think the key difference between your design and this one is that we
decided model each community as a CommCare case, rather than each CHW. We
create one sharing group for each community and put the CHW and health post
nurse into this group. The design allows us to put as many users as
desired into each sharing group --- essentially changing the list of people
providing care to any community. Each community case is owned by the
sharing group created for that community and each sub-case of the community
has been setup to inherit the owner of the community case.
[note: the auto-inheritance of ownership require custom-coded xform
code; the Wiki [1] includes some documentation to handle situations where a
user belongs to more than one sharing group]

This seems to make it easier to handle situations where CHWs are
assigned to more/less/different communities, although other scenarios could
become more challenging to address.

Cheers, Ray

1 -
https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups

[image: Inline image 1]

On Thu, Jan 24, 2013 at 10:12 AM, Nadi Kaonga nkaonga@gmail.com wrote:

Dear Fellow CommCare Users and Implementers,
We hope this finds you doing well. We are writing to request your
thoughts and insights on group[ed] users in CommCareHQ. [Apologies in
advance for the lengthy post, but wanted to provide as much detail as
possible.]

We are working on a project in Ethiopia that requires regional users
for a catchment area and individual users within that catchment area. The
set-up is such that the individual users, who are Health Extension Workers
(HEWs), are mobile users, and for each mobile user, a case has been set up.
The case represents the individual (HEW) and includes key data points like
their name, location, mobile phone number (if available) and health center
that they work in. The regional users are office-based data entry personnel
who have access to the same forms but use CloudCare and to submit the form
on behalf of the HEW.

To submit forms on behalf of the HEW, the regional user is linked to
each of the mobile workers and the corresponding "case". The regional user
then selects a case in CloudCare and is able to open the form under that
case and enter the data and submit.

Therefore, we have the regional user linked to each of the individual
users for that region. Hence, group[ed] users.

However, we have found that registering and modifying a case (i.e., an
HEW relocates to another health post in the same region) as a regional user
has posed problems. Since the regional user has been grouped, an error
message pops up to notify us that grouped users can not submit such
modifying information.

To address this problem--at least for registering new HEWs (or cases),
we thought we could set up a new user that was not grouped. This ungrouped
user could then register a new HEW (or case) in CloudCare, then work could
be done to properly group the HEW into the appropriate region and create a
mobile user to link to that new case after the initial registration. This
has worked fine.

Where we have been having issues is to modify an existing case. Since
the ungrouped user is 'new', it does not have all of the HEW data (or
cases) that the regional users have -- therefore, there is no way to select
the appropriate HEW (or case) to modify. And if we try and modify HEW data
(or a case), we receive an error message notifying us that group[ed] users
can not make such changes in the CommCare system at this time.

Have any of you run into a similar issue? Do any of you have insight
and/or suggestions on this issue? Please advise.

Thank you and if you require more information or clarification, please
do not hesitate to let us know.

With much appreciation,
Nadi Nina Kaonga (on behalf of colleagues)

--
Ray Brunsting, CTO, Tula Foundation / www.tula.org

--
You received this message because you are subscribed to the Google Groups
"commcare-users" group.
To unsubscribe from this group, send email to
commcare-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
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/groups/opt_out.

--
Ray Brunsting, CTO, Tula Foundation / www.tula.org

Thank you!

··· -- Nadi Nina Kaonga

On Mon, Jan 28, 2013 at 9:14 PM, Cory Zue czue@dimagi.com wrote:

On Mon, Jan 28, 2013 at 9:02 PM, Nadi Kaonga nkaonga@gmail.com wrote:

That is not exactly the problem, but may work towards the solution. My
only concern is if we re-assign cases to another user (from the region
user) and then modify the case, would that alter any of the form
submissions that that case has made? Please advise.

It shouldn't touch any of the previous form submissions. It will be like a
new submission was made that just updates the case ownership.

Cory

Thank you both and we are looking forward to hearing back from you.

All the best,

--
Nadi Nina Kaonga

On Mon, Jan 28, 2013 at 6:54 PM, Cory Zue czue@dimagi.com wrote:

Hi Nadi,

I'm having a hard time totally understanding the exact use case/problem
you're describing, but I think it's possible that it boils down to
something quite simple:

How can I assign a case (HEW) from one group (region) to another in
CommCare HQ?

I know you've been using cloudcare for most of your workflows, but
possibly the reassign cases tool[1] will be able to do this for you?

Apologies if I've vastly misunderstood what you need to do and gotten
this all wrong, and please feel free to clarify.

thanks,
Cory

[1]
Log In - Dimagi Confluence

On Fri, Jan 25, 2013 at 8:50 AM, Ray Brunsting ray@tula.org wrote:

While I'm not sure if this will help (or simply cause confusion), the
image below illustrates the design we have settled on for a similar
scenario.

I think the key difference between your design and this one is that we
decided model each community as a CommCare case, rather than each CHW. We
create one sharing group for each community and put the CHW and health post
nurse into this group. The design allows us to put as many users as
desired into each sharing group --- essentially changing the list of people
providing care to any community. Each community case is owned by the
sharing group created for that community and each sub-case of the community
has been setup to inherit the owner of the community case.
[note: the auto-inheritance of ownership require custom-coded xform
code; the Wiki [1] includes some documentation to handle situations where a
user belongs to more than one sharing group]

This seems to make it easier to handle situations where CHWs are
assigned to more/less/different communities, although other scenarios could
become more challenging to address.

Cheers, Ray

1 -
https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups

[image: Inline image 1]

On Thu, Jan 24, 2013 at 10:12 AM, Nadi Kaonga nkaonga@gmail.comwrote:

Dear Fellow CommCare Users and Implementers,
We hope this finds you doing well. We are writing to request your
thoughts and insights on group[ed] users in CommCareHQ. [Apologies in
advance for the lengthy post, but wanted to provide as much detail as
possible.]

We are working on a project in Ethiopia that requires regional users
for a catchment area and individual users within that catchment area. The
set-up is such that the individual users, who are Health Extension Workers
(HEWs), are mobile users, and for each mobile user, a case has been set up.
The case represents the individual (HEW) and includes key data points like
their name, location, mobile phone number (if available) and health center
that they work in. The regional users are office-based data entry personnel
who have access to the same forms but use CloudCare and to submit the form
on behalf of the HEW.

To submit forms on behalf of the HEW, the regional user is linked to
each of the mobile workers and the corresponding "case". The regional user
then selects a case in CloudCare and is able to open the form under that
case and enter the data and submit.

Therefore, we have the regional user linked to each of the individual
users for that region. Hence, group[ed] users.

However, we have found that registering and modifying a case (i.e., an
HEW relocates to another health post in the same region) as a regional user
has posed problems. Since the regional user has been grouped, an error
message pops up to notify us that grouped users can not submit such
modifying information.

To address this problem--at least for registering new HEWs (or cases),
we thought we could set up a new user that was not grouped. This ungrouped
user could then register a new HEW (or case) in CloudCare, then work could
be done to properly group the HEW into the appropriate region and create a
mobile user to link to that new case after the initial registration. This
has worked fine.

Where we have been having issues is to modify an existing case. Since
the ungrouped user is 'new', it does not have all of the HEW data (or
cases) that the regional users have -- therefore, there is no way to select
the appropriate HEW (or case) to modify. And if we try and modify HEW data
(or a case), we receive an error message notifying us that group[ed] users
can not make such changes in the CommCare system at this time.

Have any of you run into a similar issue? Do any of you have insight
and/or suggestions on this issue? Please advise.

Thank you and if you require more information or clarification, please
do not hesitate to let us know.

With much appreciation,
Nadi Nina Kaonga (on behalf of colleagues)

--
Ray Brunsting, CTO, Tula Foundation / www.tula.org

--
You received this message because you are subscribed to the Google
Groups "commcare-users" group.
To unsubscribe from this group, send email to
commcare-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
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/groups/opt_out.

--
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/groups/opt_out.

Thank you, Ray. We will definitely try and let the CommCare User Community
know how this progresses.

With much appreciation,
Nadi

··· On Jan 29, 2013 8:20 AM, "Ray Brunsting" wrote:

Re: "With your custom case-sharing setting, have you been able to easily
modify cases?
"
While it has been working fine in testing, we don't yet have any field
experience with case-sharing. I'd be interested to hear how your final
design works out.

Best regards, Ray

On Mon, Jan 28, 2013 at 9:02 PM, Nadi Kaonga nkaonga@gmail.com wrote:

Dear Ray,
Thank you very much for the feedback and the information. With your
custom case-sharing setting, have you been able to easily modify cases?

Dear Cory,
That is not exactly the problem, but may work towards the solution. My
only concern is if we re-assign cases to another user (from the region
user) and then modify the case, would that alter any of the form
submissions that that case has made? Please advise.

Thank you both and we are looking forward to hearing back from you.

All the best,

--
Nadi Nina Kaonga

On Mon, Jan 28, 2013 at 6:54 PM, Cory Zue czue@dimagi.com wrote:

Hi Nadi,

I'm having a hard time totally understanding the exact use case/problem
you're describing, but I think it's possible that it boils down to
something quite simple:

How can I assign a case (HEW) from one group (region) to another in
CommCare HQ?

I know you've been using cloudcare for most of your workflows, but
possibly the reassign cases tool[1] will be able to do this for you?

Apologies if I've vastly misunderstood what you need to do and gotten
this all wrong, and please feel free to clarify.

thanks,
Cory

[1]
Log In - Dimagi Confluence

On Fri, Jan 25, 2013 at 8:50 AM, Ray Brunsting ray@tula.org wrote:

While I'm not sure if this will help (or simply cause confusion), the
image below illustrates the design we have settled on for a similar
scenario.

I think the key difference between your design and this one is that we
decided model each community as a CommCare case, rather than each CHW. We
create one sharing group for each community and put the CHW and health post
nurse into this group. The design allows us to put as many users as
desired into each sharing group --- essentially changing the list of people
providing care to any community. Each community case is owned by the
sharing group created for that community and each sub-case of the community
has been setup to inherit the owner of the community case.
[note: the auto-inheritance of ownership require custom-coded xform
code; the Wiki [1] includes some documentation to handle situations where a
user belongs to more than one sharing group]

This seems to make it easier to handle situations where CHWs are
assigned to more/less/different communities, although other scenarios could
become more challenging to address.

Cheers, Ray

1 -
https://confluence.dimagi.com/display/commcarepublic/Assigning+cases+to+one+of+multiple+groups

[image: Inline image 1]

On Thu, Jan 24, 2013 at 10:12 AM, Nadi Kaonga nkaonga@gmail.comwrote:

Dear Fellow CommCare Users and Implementers,
We hope this finds you doing well. We are writing to request your
thoughts and insights on group[ed] users in CommCareHQ. [Apologies in
advance for the lengthy post, but wanted to provide as much detail as
possible.]

We are working on a project in Ethiopia that requires regional users
for a catchment area and individual users within that catchment area. The
set-up is such that the individual users, who are Health Extension Workers
(HEWs), are mobile users, and for each mobile user, a case has been set up.
The case represents the individual (HEW) and includes key data points like
their name, location, mobile phone number (if available) and health center
that they work in. The regional users are office-based data entry personnel
who have access to the same forms but use CloudCare and to submit the form
on behalf of the HEW.

To submit forms on behalf of the HEW, the regional user is linked to
each of the mobile workers and the corresponding "case". The regional user
then selects a case in CloudCare and is able to open the form under that
case and enter the data and submit.

Therefore, we have the regional user linked to each of the individual
users for that region. Hence, group[ed] users.

However, we have found that registering and modifying a case (i.e., an
HEW relocates to another health post in the same region) as a regional user
has posed problems. Since the regional user has been grouped, an error
message pops up to notify us that grouped users can not submit such
modifying information.

To address this problem--at least for registering new HEWs (or cases),
we thought we could set up a new user that was not grouped. This ungrouped
user could then register a new HEW (or case) in CloudCare, then work could
be done to properly group the HEW into the appropriate region and create a
mobile user to link to that new case after the initial registration. This
has worked fine.

Where we have been having issues is to modify an existing case. Since
the ungrouped user is 'new', it does not have all of the HEW data (or
cases) that the regional users have -- therefore, there is no way to select
the appropriate HEW (or case) to modify. And if we try and modify HEW data
(or a case), we receive an error message notifying us that group[ed] users
can not make such changes in the CommCare system at this time.

Have any of you run into a similar issue? Do any of you have insight
and/or suggestions on this issue? Please advise.

Thank you and if you require more information or clarification, please
do not hesitate to let us know.

With much appreciation,
Nadi Nina Kaonga (on behalf of colleagues)

--
Ray Brunsting, CTO, Tula Foundation / www.tula.org

--
You received this message because you are subscribed to the Google
Groups "commcare-users" group.
To unsubscribe from this group, send email to
commcare-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
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/groups/opt_out.

--
Ray Brunsting, CTO, Tula Foundation / www.tula.org

--
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/groups/opt_out.