Write new models

[fishbacon]

New models will be needed.

[HenrikOssipoff]

tl;dr; there is no tl;dr;.

Following up on a mail thread between Mark and myself.

Products What is the different between listing and catalogue? What is represented in each?

Transactions This is a fun one. There is technically one more option that your suggestion, which would be to simply have one model called Transaction. The idea being that a transaction can be either a debit or a credit denoted by whether or not the amount is negative or positive. This also allows for 0,- transactions, which would be neither debit or credit -- granted, I can't find a real-life use case for this just now :) It has another benefit, in that you can get the balance by doing a SUM on one single table in the end.

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.

[HenrikOssipoff]

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 :)

[fishbacon]

A listing is a product listing, as in listing.price would contain the price of a product at some point in time, it would be the thing "sold". A catalogue is a set of listings. Transactions is a good way of doing it. News was a scrolling thing at the bottom of the main page, I think some people would like it to return since it creates an opportunity to advertise upcoming events.

[HenrikOssipoff]

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. This is done to have a snapshot available of vital information; such as price at a point in time, addresses, item names etc.

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!)

[fishbacon]

Marque is great and we should reimplement it in jquery animation, just saying.

[fishbacon]

Catalogue is like the numbers in the current system. stregsystem.fklub.dk/1/ is the "default" system which sells things sold in the default system. Then there is /2/ which I believe is "vector rummet" and /3/ which is foobar. A catalogue would be associated with a number and make it so that we can control what listings are being sold where, maybe foobar should start only listing things which foobar actually sells (no more accidentally buying bottles when draft is being sold).

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).

[mchro]

Yay for denormalizing to store historical data. News is no longer essential, I believe. I would suggest not to have different catalogues: the added complexity is not worth it. The room is currently/historically only used to record the physical point of sale.

[jones-g]

@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.

[HenrikOssipoff]

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?

[jones-g]

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 :)

[HenrikOssipoff]

+1 to PointOfSale over Room, with an M2M relation to Products.

[mchro]

@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.

[fishbacon]

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.

[HenrikOssipoff]

@mchro But don't we currently use this functionality for Foobar? Or am I living in the past?

[HenrikOssipoff]

-1 for News from me btw, I honestly don't think we need it.

[jones-g]

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?

[mchro]

@HenrikOssipoff: For FooBar there is a Room to track sales happening in FooBar, but the view is no different. There is currently some body else trying to use the TV's in Jægerstuen for news/advertisement. So News is not essential.

[fishbacon]

News is out then.

[HenrikOssipoff]

@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.

[fishbacon]

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.

[mchro]

@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.

[HenrikOssipoff]

Gotcha, no feature creep.

Can we come up with different implementations to something that would solve the problem, but is less architecturally complex?

[jones-g]

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.

[HenrikOssipoff]

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.

[fishbacon]

I am working on this over here. Should we do a pull request with this initial design and write issues against it?

[HenrikOssipoff]

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.

[fishbacon]

+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.

[fishbacon]

I am unsure what messages get passed around by github. I opened pull request #20 based on this issue.

[HenrikOssipoff]

We receive a notification for each PR that's opened.

[fishbacon]

I'll stop pinging people about stuff then.