Yes, may appear trivial, but it's not.
http://mifosforge.jira.com/browse/MIFOS-4368
Is not just about clients DOB, Client has family details where the
family members DOB is also maintained. There is a configuration using
which one can enter details about multiple people in clients family.
Apart fr
I had actually looked at this, when Nirantara mentioned it. Just
making it editable is trivial of course;
http://mifos.git.sourceforge.net/git/gitweb.cgi?p=mifos/head;a=commitdiff;h=d0fcc66a6a194b4ec42b1567eb9adbe782f52981
has where I tried this (please delete branch
hudsonBuild-MIFOS-5093_DateOfBi
This is an easy decision imho. Let's let DOB and name field be editable.
We can tackle the permissions problem later.
Emily
> -Original Message-
> From: Udai Gupta [mailto:mailt...@gmail.com]
> Sent: Tuesday, September 27, 2011 11:35 AM
> To: A good place to start for users or folks new
> if we have to have permission then we should take on the big chunk and fix
> things in code.
Which means we don't change edit forms until we fix the permission
framework, i.e. these feature won't get in this(oct) release.
Udai
--
> Not sure what the answer is, but I fear going to something simple like you
> propose will hurt Mifos adoption.
I am not in favor of sticking with simple permissions either in long
run, we don't have access level control framework configure
(Spring-ACL). I said this is big task, not that we won'
Udai,
While I agree with the idea to simplify the permissions, the reality with the
MFI's I've worked with in the past is that their permission requirements are
much more granular. Certain values they want staff to enter, others they want
other staff members. Then there are all the questions a
SHORT:
If we want this field editable we don't add permission.
If we want permission anyway then we don't at this feature in this release.
LONG:
If we add these edit fields we should not add separate permission or
configuration for these fields. If we have to create permission based
on fields of a
