This allows the categorization of suppliers. For a better reporting
it is necessary to split the expenses of the invoices.
E.g. we want to be able to generate independent sums of general cost
like the rent or electricity and the cost of the bought articles.
This can be used to link to external services related to the foodcoop.
With the indirect mode it is possible to implement a secure login to other
services. In that case Foodsoft will send a HTTP GET request and redirect
the user to the returned Location header. This allows the generation of
a one-time login URL.
A typical use-case would be that a workgroup, which is responsible for
the email account, does not need to share the login credentials and can
use a link within the Foodsoft instead.
This change introduces two new data types to group the financial
transactions. Now every transaction has a "type", which itself belongs
to a "class".
Types should be used add structured information to an transaction, instead
of writing it into the notice textfield. E.g. this could be used to have
different types depending on the source of money (cash vs. bank transfer).
Classes are shown as different columns in the tables and will be uses to
group transactions of specific types. They should be used if not the whole
amount of ordergroup should be used to order food. E.g. if there is a
deposit or membership fee, which is independent of the normal credit.
This will allow us to implement additional features based on classes in
the future. E.g. the sum of transactions in the "membership fee" class
must be positive to allow food orders or show a big warning if it is bellow
a certain value.
This allows us to add additional items to an order, which do not belong
a specific user, but will be put into stock. The benefit of this change
is that we use the same order for ordergroups and stock.
In some foodcoops it is possible that ordergroups make a break. During that
they e.g. pay reduced or no membership fees and do not need to do work for
the foodcoop. This new fields make this visible to all members.
If the reply_email_domain configuration is set the messages plugin will
use unique Reply-To addresses for every email. They contain enough
information to reconstruct the message context and a hash to avoid
user forgery and spam.
A mail transfer agent must be configured to call the new rake task
foodsoft:parse_reply_email for incoming mails. The rake task requires
the receipt of the mail in the RECIPIENT variable and the raw message
via standard input. An example invocation would look like:
rake foodsoft:parse_reply_email RECIPIENT=f.1.1.HASH < test.eml
