Write new models #10
Comments
|
tl;dr; there is no tl;dr;. Following up on a mail thread between Mark and myself. Products Transactions This was actually the model we went for, the last time we started re-making the Stregsystem, but I'm not really fussed about which road we choose to go down. I would likely put Room into the the Products app. I don't remember News being used since I started at Cassiopeia - I don't think we need to consider that :) On a different note, whichever transaction model we go by, I fully support us doing an administrative TREO interface so they don't have to mock about the Django admin. In my humble opinion, only FIT should have access to that part of the system. |
|
Actually, there are use cases for 0,- transactions -- signup for free events where we want to keep track of people. That transaction would be neither a debit or a credit. It would, of course, be a valid Sale if we went with the Sale/Payment route. Terminology :) |
|
A listing is a product listing, as in |
|
I see the logic - still not sure what a catalogue is though, in relation to a product having n listings. Is a catalogue then n products? Having dealt with a few eCommerce things by now, I'll offer a bit of insight on what most do (as far as I'm aware). Instead of keeping the old prices as objects or rows, most simply do an actual copy of sales price and item name (in case it changes later) -- that is, denormalize whatever needs to be denormalized. The same could be the case for an e-mail address, which could change later even though it's available on the customer object also associated with the sales order. It's something I'd urge to consider, but once again, not something I'm overly fussed about. We would, however, end up with a lot of listings in the long run, if we do not run with something similar. The News thing make sense. We should likely do something that isn't scroll, in that case, since most browsers (luckily) won't show marquee :) (Sorry if I overdo this, but designing new systems from scratch is one of my favourite things to do -- engineering is fun!) |
|
Marque is great and we should reimplement it in jquery animation, just saying. |
|
Catalogue is like the numbers in the current system. If a listing is never sold, e.g. it relates to no transaction, then we do not care if it changed price or name, it is data which we do not need. If a listing has been sold, e.g. has a transaction with a relation to it, we snapshot the name and catalogue it was in at the time (if we want to be anal the meta too, but I imagine the meta will never be used for serious data). |
|
Yay for denormalizing to store historical data. |
|
@mchro so no need to specifically register if a sale was done in Jægerstuen, Vektorrummet or F-ytteturen? Would it still be relevant to have different views for use? E.g. as it is now the normal Jægerstue interface does not show Fadøl but the Foobar interface does. |
|
I think we definitely need some way to organize different views, at least for Foobar vs. everything else. I like the idea of Rooms - perhaps we could find a more suitable name though? |
|
How about naming it some like Point of Sale (PoS for short)? A Point of Sale would then have a list of products associated and these productions would be shown on the interface. It is almost identical to the current solution but with a new name :) |
|
+1 to PointOfSale over Room, with an M2M relation to Products. |
|
@jones-g: the opposite: keep a Room or PointOfSale or whatever relation to record where a sale happened. But don't bother with having different views for differents Rooms. It will add complexity to the code, complexity for the administration, and give very little (if any) benefit. |
|
So catalogue == PoS. I can live with that. I think news is a good thing to have, at the very least so that if some day someone wants to do some sort of PA system (e.g. the screen in Jægerstuen) they have something to base it on. |
|
@mchro But don't we currently use this functionality for Foobar? Or am I living in the past? |
|
-1 for News from me btw, I honestly don't think we need it. |
|
News could be handled differently (read aside from the Stregsystem) it does not need to be an integrated component. If we would go with one view for all rooms we would need some mechanism to easily toggle if Fadøl and stuff like that is enabled or not. IMO it would be easier to make the different views. But perhaps just one view per PoS? |
|
@HenrikOssipoff: For FooBar there is a Room to track sales happening in FooBar, but the view is no different. |
|
News is out then. |
|
@mchro So today we simply enable Fadøl whenever Foobar starts, and when done, we disable it again? Seems like a hassle to me, if we could do it instead using a PointOfSale system. Obviously I do not care much, since I'm not the one having to enable/disable all the time - but I do think it's a nifty feature. |
|
I just talked to one of the volunteers, from Foobar, and he expressed some positivity towards the idea of PoS. I imagine most of the people who deal with adding Fadøl every week (that's me) would love for them to just be there. |
|
@HenrikOssipoff: Yes, with the added benefit that the product auto-disables at the set time. I'm just arguing that the complexity is not worth it. If you really want to limit which products can be bought by the PoS then you also need to think of access control and all sorts of other crap. Whatever is decided: make sure it is done well, and that the added complexity is worth it. |
|
Gotcha, no feature creep. Can we come up with different implementations to something that would solve the problem, but is less architecturally complex? |
|
Could something like a feature that allows to "toggle" set of products with a button push be used instead? I'm think that making a "FooBar" button that enables relevant products for FooBar (and disables others if needed) and pushing again reverts this. Might need a few tables to handle but could be pretty simple. |
|
I thought of the same, but behind the scenes we would have created something like a view again (sort of), to handle what those products are that we can toggle on and off. It is, however, a simpler form of views, so it might be shallow enough to not become too complex. |
|
I am working on this over here. |
|
Thank you for reminding me that I'm behind (no sarcasm). I have some questions regarding the design, but it would indeed be easier against a PR so I can comment lines. +1 for an initial PR for the initial design. You should likely rebase against the upstream and squash before though. |
I will. But am tired now. |
This also adds three new apps. The added models are discussed in issue f-klubben#10. String representations, and example fixtures were added to make it simpler to see what the different models are intended to do.
The three new apps, fembers, products, and transactions were added in this commit. Introducing the initial design and a fixture for populating some example data. The models should be straight forward.
|
I am unsure what messages get passed around by github. |
|
We receive a notification for each PR that's opened. |
|
I'll stop pinging people about stuff then. |
The three new apps, fembers, products, and transactions were added in this commit. Introducing the initial design and a fixture for populating some example data. The models should be straight forward.
To comply with f-klubben#10 and to make me feel all fuzzy.
New models will be needed.
The text was updated successfully, but these errors were encountered: