When editing a group offer, articles are marked red or yellow, when there are missing orders to complete the package and green when it is completed.
Articles, which I did not yet order, but for which there are free tolerance items from other groups, are unfortunately unmarked. I want to have them marked. The idea is to encourage groups, that order whole packages, to offer parts of the package to others. (I.e. to order less items and add tolerance instead). But unfortunately the others won't see this in the list. I have made a fork, where such articles are marked in a light blue: https://github.com/max-kubierschky/foodsoft/tree/mark-available-articles I am going to do a merge request, but I have some questions beforehand: * Should this be standard or should it be activated by a configuration-option? * Do we need a fourth color, or should such articles just be marked green? Yours, Max |
Administrator
|
I have experimented with the situation you describe, and I agree that the UI can be improved here.
I would like to avoid adding a configuration option. Let us try to find an improved solution that covers all needs. Choosing your "green" option just makes the current behavior more consistent. I think there is a bug concerning initial background color (after page load) vs. dynamically updated background color (after changing the amounts by clicking +/-): In the situation you describe, the initial background color is white. However, after clicking "+" and "-" once, the background color is green. Note: I am not describing the behavior of your modifications, but the current behavior of the demo. I can observe the same inconsistency with only one ordergroup: After filling the package, the background color is green. After saving and re-opening the ordering form, the background color is white. Clicking "+" and "-" once, the background color is back to green. I think that four colors (white, green, red, yellow) are enough. I would like to avoid additional complexity (for developers and users). |
> I would like to avoid adding a configuration option. Let us try to > find an improved solution that covers all needs. > [...] > Choosing your "green" option just makes the current behavior more > consistent. I think there is a bug concerning initial background color > (after page load) vs. dynamically updated background color (after > changing the amounts by clicking +/-): In the situation you describe, > the initial background color is white. However, after clicking "+" and > "-" once, the background color is green. Note: I am not describing the > behavior of your modifications, but the current behavior of the demo. > > I can observe the same inconsistency with only one ordergroup: After > filling the package, the background color is green. After saving and > re-opening the ordering form, the background color is white. Clicking > "+" and "-" once, the background color is back to green. > > I think that four colors (white, green, red, yellow) are enough. I > would like to avoid additional complexity (for developers and users). > *yellow*: somebody (possibly including you) has ordered this article, but there is one item missing to complete enough packages to fulfill all orders. *red*: As yellow, but more than one item is missing* * *green*: You have ordered this article and the order can be fulfilled *OR* there is tolerance left for this article. *white*: Nobody has ordered this article or all orders can be fulfilled and there is no tolerance left. Ok like that? backend code and frontend javascript code needs to be adjusted. |
Administrator
|
I feel like you are on the right track. There are some details about the colors that we could puzzle out, but I should not waste our time with the details: Code review and merging is usually done by @wvengen and/or @paroga.
Just a thought: Can we simplify the code by moving all "color logic" to the browser (ordering.js)? The server will send all rows with an empty css classname (i.e., white background), and javascript will assign all colors once the data are fetched. This way we can remove duplicate code, and we avoid inconsistency bugs such as the current one. I am not sure if that is a good approach, but I wanted to share that idea. If that idea does not simplify your current task then feel free to ignore it. |
I have made a pull request now:
https://github.com/foodcoops/foodsoft/pull/870 I opted for marking articles yellow, that free tolerance and are not yet ordered by this group. The color for this specific case can be easily adjusted in list.missing.css, see comment there. Yellow fits well with the semantics "You get it, if you order one more item". However, yellow does not necessarily imply "If you order one more, one more package will be completed" anymore. Am 02.05.21 um 23:28 schrieb Julius [via foodsoft]: > I feel like you are on the right track. There are some details about > the colors that we could puzzle out, but I should not waste our time > with the details: Code review and merging is usually done by @wvengen > and/or @paroga. > > > maxky wrote > backend code and frontend javascript code needs to be adjusted. > > Just a thought: Can we simplify the code by moving all "color logic" > to the browser (ordering.js)? The server will send all rows with an > empty css classname (i.e., white background), and javascript will > assign all colors once the data are fetched. This way we can remove > duplicate code, and we avoid inconsistency bugs such as the current > one. I am not sure if that is a good approach, but I wanted to share > that idea. If that idea does not simplify your current task then feel > free to ignore it. > > ------------------------------------------------------------------------ > If you reply to this email, your message will be added to the > discussion below: > http://foodsoft.51229.x6.nabble.com/Marking-articles-with-free-tolerance-tp7460p7469.html > <http://foodsoft.51229.x6.nabble.com/Marking-articles-with-free-tolerance-tp7460p7469.html> > > To start a new topic under foodsoft-discuss, email > [hidden email] > To unsubscribe from foodsoft-discuss, click here > < > NAML > <http://foodsoft.51229.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > |
Free forum by Nabble | Edit this page |