wvengen
November 14, 2019, 12:40pm
1
Hi everyone,
Martin would be happy to help in the coming weeks.
What is important to contribute to for Foodsoft? I think especially with regards to getting a new release out.
Kind regards,
Julius
November 16, 2019, 7:49pm
2
Hi Martin,
hi everyone,
Martin would be happy to help in the coming weeks.
That sounds good!
What is important to contribute to for Foodsoft? I think especially with
regards to getting a new release out.
Yes, a release would be a useful thing. If Martin can add some small
fixes before the release then the release is even more useful!
In the long term, it would be awesome if someone (several people?)
continued with the foodsoft API. A good API with a modern React (or
alike) web application would also be a significantly better basis for
further improvements. I strongly suspect that the API project is way too
big given a “few hours a week” (even for a professional Rails developer).
foodcoops:master
← wvengen:feature/rest-for-shop
opened 06:13PM - 23 May 16 UTC
Starting off from #423, this is a first version of an API for Foodsoft. By desig… n, it only supports user-facing resources, so API users can only see and update one's own orders. Perhaps in a later version of the API, we may add admin-functionality as well.
_**note** this PR will be split into smaller PRs, so don't merge this one_
_**note** this feature is finished, but I'd rather wait with merging until [foodsoft-shop](https://github.com/foodcoops/foodsoft-shop) is ready (or someone else wants to use the API asap); before merging we can still change the api, afterwards I'd be more careful_
Pending:
- [x] Fix merge conflict with master
- [x] Make CORS work for multiple scopes (instead of a hardcoded `/f`)
- [x] Make sure relevant errors return json with description
- [x] Use current language in Doorkeeper
- [x] Review security
- [x] CORS settings
- [x] Make sure ransack searches don't leak data (like who ordered what)
- [x] Document endpoints (at least a bit)
- [x] Include tests (see also https://github.com/foodcoops/foodsoft/pull/423#issuecomment-195322128)
- [x] Use model name as root key (instead of `data`)
- [x] and include `order_article` to `group_order_article` update endpoint (and maybe others)
- [x] Allow plugins to register themselves for OAuth2 credentials (use `Doorkeeper::Application`)
- [x] Make Doorkeeper work with multicoops (!)
For later: return all orders, not just open ones (and allow filtering by status)
If we think about small fixes then I remember several users struggling
with article management (upload and synchronization).
opened 08:10PM - 25 Sep 19 UTC
closed 07:45AM - 31 Jan 22 UTC
bug
If you try to upload an article list that contains an overlong note then the foo… dsoft shows an "internal server error".
Below you can find some more info from the console.
> ```
> ActiveRecord::StatementInvalid (Mysql2::Error: Data too long for column 'note'
> ```
> ```
> app/controllers/articles_controller.rb:189:in `block (2 levels) in update_synchronized'
> app/controllers/articles_controller.rb:186:in `each'
> app/controllers/articles_controller.rb:186:in `block in update_synchronized'
> app/controllers/articles_controller.rb:175:in `update_synchronized'
> app/controllers/application_controller.rb:228:in `set_currency'
> app/controllers/application_controller.rb:216:in `set_time_zone'
> ```
opened 07:48PM - 09 Aug 19 UTC
feature
usability
# Status quo
When synchronizing articles with the "external database" (shared… lists), all articles are updated.
# Suggestion
I would like to add a checkbox in the beginning of every article row. By using that checkbox, the user can pick those articles that he would like to include for the update. By default, all checkboxes are checked. A checkbox in the table header allows to toggle all checkboxes at once.
Note that the suggested change is minimally invasive because all checkboxes are checked by default.
Here is how it could look like:

# Note on outlisted articles
From my point of view, outlisted articles do not need this feature: it should be fine to delete all of them if the supplier does not offer them (any more).
Also, if I understood things right, they get 500 errors when they try
viewing old orders, but I have difficulty reproducing that, especially
if the version on the server does not match `master`.
Possibly related to article management, too:
opened 07:24PM - 16 Nov 19 UTC
bug
Steps to reproduce:
* Set `unit_quantity` of some article to zero (bypass vali… dation via shared-article sync and rounding towards zero).
* Create an order including that article. Let's say the id is `78`.
* Visit [the page for ordering](https://app.foodcoops.net/demo/group_orders/new?order_id=78) (yes, you can actually see the error in the demo).
As a quick fix, you can [edit the order](https://app.foodcoops.net/demo/orders/78/edit) and disable the checkbox of the problematic article.
> ```
> ZeroDivisionError (divided by 0):
> app/models/order_article.rb:242:in `%'
> app/models/order_article.rb:242:in `_missing_units'
> app/models/order_article.rb:191:in `missing_units'
> app/models/group_order.rb:47:in `block (2 levels) in load_data'
> app/models/group_order.rb:31:in `each'
> app/models/group_order.rb:31:in `block in load_data'
> app/models/group_order.rb:30:in `each'
> app/models/group_order.rb:30:in `load_data'
> app/controllers/group_orders_controller.rb:17:in `new'
> app/controllers/application_controller.rb:228:in `set_currency'
> app/controllers/application_controller.rb:216:in `set_time_zone'
> ```
Here are some links to relevant lines in v4.6.0:
- [app/models/order_article.rb:242:in `%'](https://github.com/foodcoops/foodsoft/blob/d7420a13d2fafb91a9687c7d09e48c7cc279c3c5/app/models/order_article.rb#L242)
- [app/models/order_article.rb:191:in `missing_units'](https://github.com/foodcoops/foodsoft/blob/d7420a13d2fafb91a9687c7d09e48c7cc279c3c5/app/models/group_order.rb#L47)
- [app/models/group_order.rb:30:in `load_data'](https://github.com/foodcoops/foodsoft/blob/d7420a13d2fafb91a9687c7d09e48c7cc279c3c5/app/models/group_order.rb#L30)
In general, we could find those bugs way more easily if we fixed the
notification setup:
opened 08:16PM - 25 Sep 19 UTC
closed 01:29PM - 27 Dec 21 UTC
bug
You can reproduce the problem by following the "feedback" link (top right corner… ): If you fill some text and submit the form then an "internal server error" is shown. Ironically, that error page claims to report the issue (which fails, of course).
The reason seems to be here:
> ```
> An error occurred when sending a notification using 'email' notifier. ArgumentError: SMTP To address may not be blank: []
> ```
I am looking forward to any improvements. I will not be able to review
and merge anything non-trivial, though.
Best,
Julius