Re: Proposal: easier tenant configuration based on application.properties

[Bharath Gowda]

+1 for this Idea Aleks.

This will help a lot of organizations and make work easier to spin out new
tenants when required.
Let me know how I can help you the same, maybe with documentation I could
be useful.


Regards,
Bharath
Lead Implementation Analyst | Mifos Initiative
Skype: live:cbharath4| Mobile: +91.7019635592
http://mifos.org  



On Mon, Dec 19, 2022 at 11:27 AM Manoj VM  wrote:

> Thanks Alekx,
>
>  One feature that currently we do not have is to set up a new tenant
> dynamically on a running system. The configurations usually are loaded in
> the startup and that may also inherit the same issue. While most of the
> implementations do not require dynamic loading of a new tenant, I feel this
> is a good-to-have and usefull feature.
>
> you have already addressed the "sharing credentials in the property files"
> concern.
>
>
> Thanks and Regards,
>  Manoj Mohanan
>
>
>
> On Mon, Dec 19, 2022 at 11:02 AM Aleksandar Vidakovic <
> chee...@monkeysintown.com> wrote:
>
>> ... definitely James... just left a comment on the Jira ticket in
>> response to Victor. Another important point is to introduce this feature in
>> a non-disruptive way. Those that have systems already running will get a
>> hint (in the boot log for example) to move to the new way of tenant
>> configuration and if you start Fineract fresh (first time) properties
>> approach could be default (pending vote of community).
>> In the comment to Victor I've mentioned also that we can't just dump
>> credentials in files or logs... made a proposal with a secured REST
>> endpoint that admins can use to download any migration properties (in
>> production you can turn this feature off). Pretty sure there will be more
>> input from the community on that point.
>> In any case: documentation will be included.
>>
>> On Mon, Dec 19, 2022 at 6:12 AM James Dailey 
>> wrote:
>>
>>> Thanks Aleks
>>>
>>> Back in the day, indeed before this use of a database table for tenants,
>>> we used a property file for all sorts of useful run time configuration.
>>>
>>> My only caution would be to - through clear documentation- make it
>>> obvious what belongs in the application.properties and what does not.
>>>
>>>
>>>
>>> On Sun, Dec 18, 2022 at 8:59 PM Aleksandar Vidakovic 
>>> wrote:
>>>
 Hi everyone,

 ... just wanted to run an idea by you that I think would be a great
 improvement both in terms of security and usability. I've created a Jira
 ticket with all the details (as much as I have them currently on my radar)
 at https://issues.apache.org/jira/browse/FINERACT-1833 and would
 really appreciate your thoughts and additional feedback, things that I
 might have missed, things you miss in the proposal. I'll post the
 description here for convenience.

 At the moment Fineract's multi-tenancy feature is based on a separate
 tenant database with a single table; each row contains the database
 connection details and timezone settings for each tenant. I am proposing to
 make this feature an official Fineract extension point and to provide an
 alternative implementation based on application.properties instead of the
 database approach.

 Using application.properties is - for a Spring Boot - the best place to
 put any kind of application configuration. Since Fineract's inception a lot
 has happened in the Spring/Boot eco-system. Reloadable configurations are
 nothing strange anymore and a solved problem. In fact, they are especially
 useful when applications are deployed in a Kubernetes environment and
 ensure that Fineract's application context is always in a correct state. A
 recent example where this was applied was in the fix for a file traversal
 vulnerability related to ContentRepository (see FINERACT-1794). Instead of
 using the JDBC based ConfigurationService we moved the configuration for
 file system and S3 based file storage to application.properties. This makes
 life immediately easier for everyone, we removed another point of failure
 (the database) and we laid the ground to make this a true extensible
 feature (watch this space, we have a proposal to add Azure Storage) without
 having to deal with database schemas and Liquibase migrations. It is so
 much easier just to deal with the properties files and to adapt them if
 needed.

 To ensure that configuration information is separated by tenant we
 would not store everything in the default application.properties file.
 Obviously we don't know yet which tenants users want to add; and if we
 stored the tenant information in that file we would need to constantly
 (well, every time we add a tenant) overwrite that file. This would be at
 the least very annoying, because this file is under Git control, means:
 when the next release upgrade needs to be applied then there is a potential
 

Re: [ANNOUNCE] Welcome Bharath Gowda as New Apache Fineract Committer

[Bharath Gowda]

Thank you all for the wishes, Happy to be a part of the Fineract Community
:)

Thank you James and Ed for all the support over the years.

Regards,
Bharath
Lead Implementation Analyst | Mifos Initiative
Skype: live:cbharath4| Mobile: +91.7019635592
http://mifos.org  



On Mon, Dec 19, 2022 at 11:03 AM Aleksandar Vidakovic <
chee...@monkeysintown.com> wrote:

> Congratulations Bharath!
>
> On Mon, Dec 19, 2022 at 5:06 AM  wrote:
>
>> Congratulations Bharat..
>>
>>
>>
>> *From:* Luis Alberto Alegría de los Santos 
>> *Sent:* 19 December 2022 03:50
>> *To:* dev@fineract.apache.org
>> *Subject:* Re: [ANNOUNCE] Welcome Bharath Gowda as New Apache Fineract
>> Committer
>>
>>
>>
>> Congrats Bharath!!
>>
>>
>>
>> On Sun, Dec 18, 2022 at 2:19 PM Anu Omotayo 
>> wrote:
>>
>> Congratulations Bharath, wishing you success all the way.
>>
>>
>>
>> Regards
>>
>>
>> Anu Omotayo
>>
>>
>>
>>
>>
>> On Sunday, December 18, 2022 at 09:51:34 AM GMT+1, Ed Cable <
>> edca...@mifos.org> wrote:
>>
>>
>>
>>
>>
>> Hello all,
>>
>>
>>
>> I am happy to announce Bharath Gowda as a new committer. Bharath has
>> played a valuable role over the years as one of the foremost functional
>> experts of the platform. He is an active presence across the mailing list
>> and throughout Jira helping to shape requirements and triage new issues as
>> well as on board new contributors to the community.
>>
>>
>>
>> Please join us in welcoming Bharath as a committer.
>>
>>
>>
>> Ed
>>
>>
>>
>> --
>>
>> Luis Alegría
>>
>>
>>
>>
>>
>> *La información contenida en este correo electrónico y anexos es
>> confidencial. Ésta dirigida únicamente para el uso del individuo o entidad
>> a la que fue dirigida y puede contener información propietaria que no es
>> del dominio público. Si has recibido este correo por error o no eres el
>> destinatario, por favor notificar al remitente de inmediato y borra este
>> mensaje de la computadora o dispositivo. Cualquier uso, distribución o
>> reproducción de este correo que no sea por el destinatario de intención
>> queda prohibido.*
>>
>

Re: Proposal: easier tenant configuration based on application.properties

[Manoj VM]

Thanks Alekx,

 One feature that currently we do not have is to set up a new tenant
dynamically on a running system. The configurations usually are loaded in
the startup and that may also inherit the same issue. While most of the
implementations do not require dynamic loading of a new tenant, I feel this
is a good-to-have and usefull feature.

you have already addressed the "sharing credentials in the property files"
concern.


Thanks and Regards,
 Manoj Mohanan



On Mon, Dec 19, 2022 at 11:02 AM Aleksandar Vidakovic <
chee...@monkeysintown.com> wrote:

> ... definitely James... just left a comment on the Jira ticket in response
> to Victor. Another important point is to introduce this feature in a
> non-disruptive way. Those that have systems already running will get a hint
> (in the boot log for example) to move to the new way of tenant
> configuration and if you start Fineract fresh (first time) properties
> approach could be default (pending vote of community).
> In the comment to Victor I've mentioned also that we can't just dump
> credentials in files or logs... made a proposal with a secured REST
> endpoint that admins can use to download any migration properties (in
> production you can turn this feature off). Pretty sure there will be more
> input from the community on that point.
> In any case: documentation will be included.
>
> On Mon, Dec 19, 2022 at 6:12 AM James Dailey 
> wrote:
>
>> Thanks Aleks
>>
>> Back in the day, indeed before this use of a database table for tenants,
>> we used a property file for all sorts of useful run time configuration.
>>
>> My only caution would be to - through clear documentation- make it
>> obvious what belongs in the application.properties and what does not.
>>
>>
>>
>> On Sun, Dec 18, 2022 at 8:59 PM Aleksandar Vidakovic 
>> wrote:
>>
>>> Hi everyone,
>>>
>>> ... just wanted to run an idea by you that I think would be a great
>>> improvement both in terms of security and usability. I've created a Jira
>>> ticket with all the details (as much as I have them currently on my radar)
>>> at https://issues.apache.org/jira/browse/FINERACT-1833 and would really
>>> appreciate your thoughts and additional feedback, things that I might have
>>> missed, things you miss in the proposal. I'll post the description here for
>>> convenience.
>>>
>>> At the moment Fineract's multi-tenancy feature is based on a separate
>>> tenant database with a single table; each row contains the database
>>> connection details and timezone settings for each tenant. I am proposing to
>>> make this feature an official Fineract extension point and to provide an
>>> alternative implementation based on application.properties instead of the
>>> database approach.
>>>
>>> Using application.properties is - for a Spring Boot - the best place to
>>> put any kind of application configuration. Since Fineract's inception a lot
>>> has happened in the Spring/Boot eco-system. Reloadable configurations are
>>> nothing strange anymore and a solved problem. In fact, they are especially
>>> useful when applications are deployed in a Kubernetes environment and
>>> ensure that Fineract's application context is always in a correct state. A
>>> recent example where this was applied was in the fix for a file traversal
>>> vulnerability related to ContentRepository (see FINERACT-1794). Instead of
>>> using the JDBC based ConfigurationService we moved the configuration for
>>> file system and S3 based file storage to application.properties. This makes
>>> life immediately easier for everyone, we removed another point of failure
>>> (the database) and we laid the ground to make this a true extensible
>>> feature (watch this space, we have a proposal to add Azure Storage) without
>>> having to deal with database schemas and Liquibase migrations. It is so
>>> much easier just to deal with the properties files and to adapt them if
>>> needed.
>>>
>>> To ensure that configuration information is separated by tenant we would
>>> not store everything in the default application.properties file. Obviously
>>> we don't know yet which tenants users want to add; and if we stored the
>>> tenant information in that file we would need to constantly (well, every
>>> time we add a tenant) overwrite that file. This would be at the least very
>>> annoying, because this file is under Git control, means: when the next
>>> release upgrade needs to be applied then there is a potential for dropping
>>> the ball and someone overwrites your tenant configuration. Instead, each
>>> tenant's configuration would be provided in a separate Spring Boot profile
>>> configuration, e. g. the default tenant's configuration would be provided
>>> in a file named "application-tenant-default.properties". The prefix
>>> "application-tenant-" is a convention that everyone should follow. We might
>>> have later other features that could use profile configurations and/or
>>> custom modules might use these (profile) mechanics too. Just to avoid any
>>> 

Re: [ANNOUNCE] Welcome Bharath Gowda as New Apache Fineract Committer

[Aleksandar Vidakovic]

Congratulations Bharath!

On Mon, Dec 19, 2022 at 5:06 AM  wrote:

> Congratulations Bharat..
>
>
>
> *From:* Luis Alberto Alegría de los Santos 
> *Sent:* 19 December 2022 03:50
> *To:* dev@fineract.apache.org
> *Subject:* Re: [ANNOUNCE] Welcome Bharath Gowda as New Apache Fineract
> Committer
>
>
>
> Congrats Bharath!!
>
>
>
> On Sun, Dec 18, 2022 at 2:19 PM Anu Omotayo 
> wrote:
>
> Congratulations Bharath, wishing you success all the way.
>
>
>
> Regards
>
>
> Anu Omotayo
>
>
>
>
>
> On Sunday, December 18, 2022 at 09:51:34 AM GMT+1, Ed Cable <
> edca...@mifos.org> wrote:
>
>
>
>
>
> Hello all,
>
>
>
> I am happy to announce Bharath Gowda as a new committer. Bharath has
> played a valuable role over the years as one of the foremost functional
> experts of the platform. He is an active presence across the mailing list
> and throughout Jira helping to shape requirements and triage new issues as
> well as on board new contributors to the community.
>
>
>
> Please join us in welcoming Bharath as a committer.
>
>
>
> Ed
>
>
>
> --
>
> Luis Alegría
>
>
>
>
>
> *La información contenida en este correo electrónico y anexos es
> confidencial. Ésta dirigida únicamente para el uso del individuo o entidad
> a la que fue dirigida y puede contener información propietaria que no es
> del dominio público. Si has recibido este correo por error o no eres el
> destinatario, por favor notificar al remitente de inmediato y borra este
> mensaje de la computadora o dispositivo. Cualquier uso, distribución o
> reproducción de este correo que no sea por el destinatario de intención
> queda prohibido.*
>

Re: Proposal: easier tenant configuration based on application.properties

[Aleksandar Vidakovic]

... definitely James... just left a comment on the Jira ticket in response
to Victor. Another important point is to introduce this feature in a
non-disruptive way. Those that have systems already running will get a hint
(in the boot log for example) to move to the new way of tenant
configuration and if you start Fineract fresh (first time) properties
approach could be default (pending vote of community).
In the comment to Victor I've mentioned also that we can't just dump
credentials in files or logs... made a proposal with a secured REST
endpoint that admins can use to download any migration properties (in
production you can turn this feature off). Pretty sure there will be more
input from the community on that point.
In any case: documentation will be included.

On Mon, Dec 19, 2022 at 6:12 AM James Dailey  wrote:

> Thanks Aleks
>
> Back in the day, indeed before this use of a database table for tenants,
> we used a property file for all sorts of useful run time configuration.
>
> My only caution would be to - through clear documentation- make it obvious
> what belongs in the application.properties and what does not.
>
>
>
> On Sun, Dec 18, 2022 at 8:59 PM Aleksandar Vidakovic 
> wrote:
>
>> Hi everyone,
>>
>> ... just wanted to run an idea by you that I think would be a great
>> improvement both in terms of security and usability. I've created a Jira
>> ticket with all the details (as much as I have them currently on my radar)
>> at https://issues.apache.org/jira/browse/FINERACT-1833 and would really
>> appreciate your thoughts and additional feedback, things that I might have
>> missed, things you miss in the proposal. I'll post the description here for
>> convenience.
>>
>> At the moment Fineract's multi-tenancy feature is based on a separate
>> tenant database with a single table; each row contains the database
>> connection details and timezone settings for each tenant. I am proposing to
>> make this feature an official Fineract extension point and to provide an
>> alternative implementation based on application.properties instead of the
>> database approach.
>>
>> Using application.properties is - for a Spring Boot - the best place to
>> put any kind of application configuration. Since Fineract's inception a lot
>> has happened in the Spring/Boot eco-system. Reloadable configurations are
>> nothing strange anymore and a solved problem. In fact, they are especially
>> useful when applications are deployed in a Kubernetes environment and
>> ensure that Fineract's application context is always in a correct state. A
>> recent example where this was applied was in the fix for a file traversal
>> vulnerability related to ContentRepository (see FINERACT-1794). Instead of
>> using the JDBC based ConfigurationService we moved the configuration for
>> file system and S3 based file storage to application.properties. This makes
>> life immediately easier for everyone, we removed another point of failure
>> (the database) and we laid the ground to make this a true extensible
>> feature (watch this space, we have a proposal to add Azure Storage) without
>> having to deal with database schemas and Liquibase migrations. It is so
>> much easier just to deal with the properties files and to adapt them if
>> needed.
>>
>> To ensure that configuration information is separated by tenant we would
>> not store everything in the default application.properties file. Obviously
>> we don't know yet which tenants users want to add; and if we stored the
>> tenant information in that file we would need to constantly (well, every
>> time we add a tenant) overwrite that file. This would be at the least very
>> annoying, because this file is under Git control, means: when the next
>> release upgrade needs to be applied then there is a potential for dropping
>> the ball and someone overwrites your tenant configuration. Instead, each
>> tenant's configuration would be provided in a separate Spring Boot profile
>> configuration, e. g. the default tenant's configuration would be provided
>> in a file named "application-tenant-default.properties". The prefix
>> "application-tenant-" is a convention that everyone should follow. We might
>> have later other features that could use profile configurations and/or
>> custom modules might use these (profile) mechanics too. Just to avoid any
>> collisions. This file based tenant configuration approach would allow you
>> to easily add and remove (e. g. via Docker volume mount for the files and a
>> simple command line parameter for Fineract's startup command via
>> "-Dspring.profiles.active=default,tenant-default,tenant-abc,...")
>> additional tenants in a way that is very likely more "natural" for your
>> DevOps people, having to deal with configuration in a database is a bit of
>> a distracting context switch.
>>
>> And finally: the current approach has also some security related issues.
>> The credentials for the tenants' database connections are stored in plain
>> text which is pretty 

Re: Proposal: easier tenant configuration based on application.properties

[James Dailey]

Thanks Aleks

Back in the day, indeed before this use of a database table for tenants, we
used a property file for all sorts of useful run time configuration.

My only caution would be to - through clear documentation- make it obvious
what belongs in the application.properties and what does not.



On Sun, Dec 18, 2022 at 8:59 PM Aleksandar Vidakovic 
wrote:

> Hi everyone,
>
> ... just wanted to run an idea by you that I think would be a great
> improvement both in terms of security and usability. I've created a Jira
> ticket with all the details (as much as I have them currently on my radar)
> at https://issues.apache.org/jira/browse/FINERACT-1833 and would really
> appreciate your thoughts and additional feedback, things that I might have
> missed, things you miss in the proposal. I'll post the description here for
> convenience.
>
> At the moment Fineract's multi-tenancy feature is based on a separate
> tenant database with a single table; each row contains the database
> connection details and timezone settings for each tenant. I am proposing to
> make this feature an official Fineract extension point and to provide an
> alternative implementation based on application.properties instead of the
> database approach.
>
> Using application.properties is - for a Spring Boot - the best place to
> put any kind of application configuration. Since Fineract's inception a lot
> has happened in the Spring/Boot eco-system. Reloadable configurations are
> nothing strange anymore and a solved problem. In fact, they are especially
> useful when applications are deployed in a Kubernetes environment and
> ensure that Fineract's application context is always in a correct state. A
> recent example where this was applied was in the fix for a file traversal
> vulnerability related to ContentRepository (see FINERACT-1794). Instead of
> using the JDBC based ConfigurationService we moved the configuration for
> file system and S3 based file storage to application.properties. This makes
> life immediately easier for everyone, we removed another point of failure
> (the database) and we laid the ground to make this a true extensible
> feature (watch this space, we have a proposal to add Azure Storage) without
> having to deal with database schemas and Liquibase migrations. It is so
> much easier just to deal with the properties files and to adapt them if
> needed.
>
> To ensure that configuration information is separated by tenant we would
> not store everything in the default application.properties file. Obviously
> we don't know yet which tenants users want to add; and if we stored the
> tenant information in that file we would need to constantly (well, every
> time we add a tenant) overwrite that file. This would be at the least very
> annoying, because this file is under Git control, means: when the next
> release upgrade needs to be applied then there is a potential for dropping
> the ball and someone overwrites your tenant configuration. Instead, each
> tenant's configuration would be provided in a separate Spring Boot profile
> configuration, e. g. the default tenant's configuration would be provided
> in a file named "application-tenant-default.properties". The prefix
> "application-tenant-" is a convention that everyone should follow. We might
> have later other features that could use profile configurations and/or
> custom modules might use these (profile) mechanics too. Just to avoid any
> collisions. This file based tenant configuration approach would allow you
> to easily add and remove (e. g. via Docker volume mount for the files and a
> simple command line parameter for Fineract's startup command via
> "-Dspring.profiles.active=default,tenant-default,tenant-abc,...")
> additional tenants in a way that is very likely more "natural" for your
> DevOps people, having to deal with configuration in a database is a bit of
> a distracting context switch.
>
> And finally: the current approach has also some security related issues.
> The credentials for the tenants' database connections are stored in plain
> text which is pretty much a no-go (and we've already received requests from
> community members to address this issue). If we move this to the properties
> files then you can use pretty much any sensible strategy that is available
> today to safely store credentials like vaults (Hashicorp Vault, Kubernetes
> Secrets) or environment variables for example. These approaches are also
> first class citizens supported by Spring Cloud (Kubernetes Secrets, vaults
> etc.). The current database configuration also doesn't allow to properly
> separate concerns between DevOps and developers (the database migration is
> maintained in Git which means under the developers' control). Usually you
> would want to keep this apart from each other.
>
> And no worries, there are no plans to remove the current way how tenants
> are configured, but I think it would be a good idea to default to the
> easier and more secure approach (properties) 

Proposal: easier tenant configuration based on application.properties

[Aleksandar Vidakovic]

Hi everyone,

... just wanted to run an idea by you that I think would be a great
improvement both in terms of security and usability. I've created a Jira
ticket with all the details (as much as I have them currently on my radar)
at https://issues.apache.org/jira/browse/FINERACT-1833 and would really
appreciate your thoughts and additional feedback, things that I might have
missed, things you miss in the proposal. I'll post the description here for
convenience.

At the moment Fineract's multi-tenancy feature is based on a separate
tenant database with a single table; each row contains the database
connection details and timezone settings for each tenant. I am proposing to
make this feature an official Fineract extension point and to provide an
alternative implementation based on application.properties instead of the
database approach.

Using application.properties is - for a Spring Boot - the best place to put
any kind of application configuration. Since Fineract's inception a lot has
happened in the Spring/Boot eco-system. Reloadable configurations are
nothing strange anymore and a solved problem. In fact, they are especially
useful when applications are deployed in a Kubernetes environment and
ensure that Fineract's application context is always in a correct state. A
recent example where this was applied was in the fix for a file traversal
vulnerability related to ContentRepository (see FINERACT-1794). Instead of
using the JDBC based ConfigurationService we moved the configuration for
file system and S3 based file storage to application.properties. This makes
life immediately easier for everyone, we removed another point of failure
(the database) and we laid the ground to make this a true extensible
feature (watch this space, we have a proposal to add Azure Storage) without
having to deal with database schemas and Liquibase migrations. It is so
much easier just to deal with the properties files and to adapt them if
needed.

To ensure that configuration information is separated by tenant we would
not store everything in the default application.properties file. Obviously
we don't know yet which tenants users want to add; and if we stored the
tenant information in that file we would need to constantly (well, every
time we add a tenant) overwrite that file. This would be at the least very
annoying, because this file is under Git control, means: when the next
release upgrade needs to be applied then there is a potential for dropping
the ball and someone overwrites your tenant configuration. Instead, each
tenant's configuration would be provided in a separate Spring Boot profile
configuration, e. g. the default tenant's configuration would be provided
in a file named "application-tenant-default.properties". The prefix
"application-tenant-" is a convention that everyone should follow. We might
have later other features that could use profile configurations and/or
custom modules might use these (profile) mechanics too. Just to avoid any
collisions. This file based tenant configuration approach would allow you
to easily add and remove (e. g. via Docker volume mount for the files and a
simple command line parameter for Fineract's startup command via
"-Dspring.profiles.active=default,tenant-default,tenant-abc,...")
additional tenants in a way that is very likely more "natural" for your
DevOps people, having to deal with configuration in a database is a bit of
a distracting context switch.

And finally: the current approach has also some security related issues.
The credentials for the tenants' database connections are stored in plain
text which is pretty much a no-go (and we've already received requests from
community members to address this issue). If we move this to the properties
files then you can use pretty much any sensible strategy that is available
today to safely store credentials like vaults (Hashicorp Vault, Kubernetes
Secrets) or environment variables for example. These approaches are also
first class citizens supported by Spring Cloud (Kubernetes Secrets, vaults
etc.). The current database configuration also doesn't allow to properly
separate concerns between DevOps and developers (the database migration is
maintained in Git which means under the developers' control). Usually you
would want to keep this apart from each other.

And no worries, there are no plans to remove the current way how tenants
are configured, but I think it would be a good idea to default to the
easier and more secure approach (properties) and still leave an option for
those who can't or don't want to switch. The idea is also to provide some
help with migrating your existing tenants to properties files. There could
be some migration component that can help creating the necessary files
(details to be defined), e. g. when the application boots up in the log
messages (similar how Spring Boot does it if there are e. g. configuration
properties changes etc.).

Please let me know what you think.

Cheers,

Aleks

[FINERACT] [PROPOSAL]  New release 1.8.3

[Aleksandar Vidakovic]

Hello everyone,

... based on our "How to Release Apache Fineract" process documented at
https://cwiki.apache.org/confluence/x/DRwIB:

I will create a 1.8.3 branch off develop in our git repository at
https://github.com/apache/fineract on Thursday, December 15, 2022.

The release tracking umbrella issue for tracking all activity in JIRA is
FINERACT-1836 (https://issues.apache.org/jira/browse/FINERACT-1836) for
this Fineract 1.8.3.

If you have any work in progress that you would like to see included in
this release, please add "blocking" links to the release JIRA issue.

I am the release manager for this release.

Cheers,

Aleksandar Vidakovic

RE: [ANNOUNCE] Welcome Bharath Gowda as New Apache Fineract Committer

[prashantr]

Congratulations Bharat..

 

From: Luis Alberto Alegría de los Santos  
Sent: 19 December 2022 03:50
To: dev@fineract.apache.org
Subject: Re: [ANNOUNCE] Welcome Bharath Gowda as New Apache Fineract Committer

 

Congrats Bharath!!

 

On Sun, Dec 18, 2022 at 2:19 PM Anu Omotayo mailto:anmot...@yahoo.com.invalid> > wrote:

Congratulations Bharath, wishing you success all the way. 

 

Regards


Anu Omotayo

 

 

On Sunday, December 18, 2022 at 09:51:34 AM GMT+1, Ed Cable mailto:edca...@mifos.org> > wrote: 

 

 

Hello all,

 

I am happy to announce Bharath Gowda as a new committer. Bharath has played a 
valuable role over the years as one of the foremost functional experts of the 
platform. He is an active presence across the mailing list and throughout Jira 
helping to shape requirements and triage new issues as well as on board new 
contributors to the community. 

 

Please join us in welcoming Bharath as a committer.

 

Ed

 

-- 

Luis Alegría

  

 

 

 

La información contenida en este correo electrónico y anexos es confidencial. 
Ésta dirigida únicamente para el uso del individuo o entidad a la que fue 
dirigida y puede contener información propietaria que no es del dominio 
público. Si has recibido este correo por error o no eres el destinatario, por 
favor notificar al remitente de inmediato y borra este mensaje de la 
computadora o dispositivo. Cualquier uso, distribución o reproducción de este 
correo que no sea por el destinatario de intención queda prohibido.

Please repost your email if not seen

[James Dailey]

All

Between Sunday Dec 11th and Saturday Dec 17th (inclusive ) we had an
undetected outage on our dev list.  Messages sent in that time period may
have failed silently.

Please resend your email if you posted during that specific timeframe.

https://lists.apache.org/list.html?dev@fineract.apache.org

- To view those that were posted.

Thank you
-- 
Sent from Gmail Mobile

Re: [ANNOUNCE] Welcome Bharath Gowda as New Apache Fineract Committer

[Luis Alberto Alegría de los Santos]

Congrats Bharath!!

On Sun, Dec 18, 2022 at 2:19 PM Anu Omotayo 
wrote:

> Congratulations Bharath, wishing you success all the way.
>
> Regards
>
> Anu Omotayo
>
>
>
> On Sunday, December 18, 2022 at 09:51:34 AM GMT+1, Ed Cable <
> edca...@mifos.org> wrote:
>
>
> Hello all,
>
> I am happy to announce Bharath Gowda as a new committer. Bharath has
> played a valuable role over the years as one of the foremost functional
> experts of the platform. He is an active presence across the mailing list
> and throughout Jira helping to shape requirements and triage new issues as
> well as on board new contributors to the community.
>
> Please join us in welcoming Bharath as a committer.
>
> Ed
>
> --
Luis Alegría



*La información contenida en este correo electrónico y anexos es
confidencial. Ésta dirigida únicamente para el uso del individuo o entidad
a la que fue dirigida y puede contener información propietaria que no es
del dominio público. Si has recibido este correo por error o no eres el
destinatario, por favor notificar al remitente de inmediato y borra este
mensaje de la computadora o dispositivo. Cualquier uso, distribución o
reproducción de este correo que no sea por el destinatario de intención
queda prohibido.*

Re: [ANNOUNCE] Welcome Bharath Gowda as New Apache Fineract Committer

[Anu Omotayo]

Congratulations Bharath, wishing you success all the way. 
Regards
Anu Omotayo

 

On Sunday, December 18, 2022 at 09:51:34 AM GMT+1, Ed Cable 
 wrote:  
 
 Hello all,
I am happy to announce Bharath Gowda as a new committer. Bharath has played a 
valuable role over the years as one of the foremost functional experts of the 
platform. He is an active presence across the mailing list and throughout Jira 
helping to shape requirements and triage new issues as well as on board new 
contributors to the community. 
Please join us in welcoming Bharath as a committer.
Ed

  

Re: [ANNOUNCE] Welcome Bharath Gowda as New Apache Fineract Committer

[Sanyam Goel]

Congrats Bharath!!



On Sun, Dec 18, 2022 at 11:16 PM Kigred Developer <
kigred.develo...@gmail.com> wrote:

> Well done and Congrats Bharath.
>
> On Sun, 18 Dec 2022, 11:51 Ed Cable,  wrote:
>
>> Hello all,
>>
>> I am happy to announce Bharath Gowda as a new committer. Bharath has
>> played a valuable role over the years as one of the foremost functional
>> experts of the platform. He is an active presence across the mailing list
>> and throughout Jira helping to shape requirements and triage new issues as
>> well as on board new contributors to the community.
>>
>> Please join us in welcoming Bharath as a committer.
>>
>> Ed
>>
>>

Re: [ANNOUNCE] Welcome Bharath Gowda as New Apache Fineract Committer

[Kigred Developer]

Well done and Congrats Bharath.

On Sun, 18 Dec 2022, 11:51 Ed Cable,  wrote:

> Hello all,
>
> I am happy to announce Bharath Gowda as a new committer. Bharath has
> played a valuable role over the years as one of the foremost functional
> experts of the platform. He is an active presence across the mailing list
> and throughout Jira helping to shape requirements and triage new issues as
> well as on board new contributors to the community.
>
> Please join us in welcoming Bharath as a committer.
>
> Ed
>
>

If you want to unsubscribe

[James Dailey]

Sending a blank email to   dev-unsubscr...@fineract.apache.org
 should work.

-- 
Sent from Gmail Mobile

Re: [ANNOUNCE] Welcome Bharath Gowda as New Apache Fineract Committer

[Bernard MUNYANDAMUTSA]

Dear dev team,

can disable my membership to finaract so that i will no longer again
receive your emails?

Thank you

Regards
Bermard

On Sun, Dec 18, 2022 at 10:51 AM Ed Cable  wrote:

> Hello all,
>
> I am happy to announce Bharath Gowda as a new committer. Bharath has
> played a valuable role over the years as one of the foremost functional
> experts of the platform. He is an active presence across the mailing list
> and throughout Jira helping to shape requirements and triage new issues as
> well as on board new contributors to the community.
>
> Please join us in welcoming Bharath as a committer.
>
> Ed
>
>

Re: [ANNOUNCE] Welcome Bharath Gowda as New Apache Fineract Committer

[Bruce]

Great news. Congrats Bharath.

On Sun, Dec 18, 2022, 12:43 PM Chirag Gupta 
wrote:

> Congrats Bharath Gowda!
>
> On Sun, Dec 18, 2022 at 2:21 PM Ed Cable  wrote:
>
>> Hello all,
>>
>> I am happy to announce Bharath Gowda as a new committer. Bharath has
>> played a valuable role over the years as one of the foremost functional
>> experts of the platform. He is an active presence across the mailing list
>> and throughout Jira helping to shape requirements and triage new issues as
>> well as on board new contributors to the community.
>>
>> Please join us in welcoming Bharath as a committer.
>>
>> Ed
>>
>>

Re: [ANNOUNCE] Welcome Bharath Gowda as New Apache Fineract Committer

[Chirag Gupta]

Congrats Bharath Gowda!

On Sun, Dec 18, 2022 at 2:21 PM Ed Cable  wrote:

> Hello all,
>
> I am happy to announce Bharath Gowda as a new committer. Bharath has
> played a valuable role over the years as one of the foremost functional
> experts of the platform. He is an active presence across the mailing list
> and throughout Jira helping to shape requirements and triage new issues as
> well as on board new contributors to the community.
>
> Please join us in welcoming Bharath as a committer.
>
> Ed
>
>

Re: Slack channel

[Peter Bean]

Can someone send me an invite to the Slack workspace too?

Le dim. 18 déc. 2022, 15:30, Petri Tuomola  a
écrit :

> I tried to log in (both with my private email as well as using my @
> apache.org) account, but it did not work… says my email is not part of
> the ASF workspace.
>
> Looking at this https://infra.apache.org/slack.html I think someone needs
> to invite me?
>
> Regards
> Petri
>
>
> On 18 Dec 2022, at 3:35 PM, James Dailey  wrote:
>
> Apache infra runs a slack channel.  To keep things at Apache, please join
> the #fineract channel on
> the-asf.slack.com
>
> Apache Software Foundation (asf)
>
> --
> Sent from Gmail Mobile
>
>
>

[ANNOUNCE] Welcome Bharath Gowda as New Apache Fineract Committer

[Ed Cable]

Hello all,

I am happy to announce Bharath Gowda as a new committer. Bharath has played
a valuable role over the years as one of the foremost functional experts of
the platform. He is an active presence across the mailing list and
throughout Jira helping to shape requirements and triage new issues as well
as on board new contributors to the community.

Please join us in welcoming Bharath as a committer.

Ed

Re: Slack channel

[Petri Tuomola]

I tried to log in (both with my private email as well as using my @apache.org) 
account, but it did not work… says my email is not part of the ASF workspace. 

Looking at this https://infra.apache.org/slack.html I think someone needs to 
invite me? 

Regards
Petri


> On 18 Dec 2022, at 3:35 PM, James Dailey  wrote:
> 
> Apache infra runs a slack channel.  To keep things at Apache, please join the 
> #fineract channel on 
> the-asf.slack.com  
> 
> Apache Software Foundation (asf) 
> 
> -- 
> Sent from Gmail Mobile

Slack channel

[James Dailey]

Apache infra runs a slack channel.  To keep things at Apache, please join
the #fineract channel on
the-asf.slack.com

Apache Software Foundation (asf)

-- 
Sent from Gmail Mobile