Attribute Issues

[jekkos]

Currently left to finish

• [x] Test reports to see if all are working
• [x] Fix item bulk edit, might be best to omit attributes (except category) as not all items will have the same?
• [x] Test text and date type fields. Date type fields might be for later
• [x] Check if item update is working as it should

[odiea]

I am creating a new database to work with.

1. No detailed reports work.
2. Supplier name does not show in items. 3 I created 3 attributes. Only 1 attribute shows on any Category selection. I guess I need some more info on how this is suppose to work. 4 I created a new item selected a Cat went to update. Error adding updating. I refresh items and the newly created item shows just fine.

[odiea]

Just wondering if it would be easier to store the attribute link for items in items? Reinstate the Category column and put the link into there then have it do a lookup or join.

[daN4cat]

@jekkos @odiea I force commit to private/master the latest from master and then rebased mailchimp branch and submitted the code to master merging the database upgrade scripts. It's now cleaner although some duplicate history went in from standard ospos master.

@jekkos you will probably need to rebase your attribute branch with the latest master to remove any conflict due to Steve's work. Be careful about the fact that I force pushed master so you may want to check again and maybe a rebase would be cleaner.

[jekkos]

@daN4cat attributes branch should be in sync again with public and private master repository.

[jekkos]

Currently I see what could cause duplicate history now. My private branch contains a rebased version of master. If I merge into master now I guess mailchimp stuff will be duplicated. This is something I'd rather avoid

[jekkos]

Unless I force push attributes to master but that is not really recommended practice.. think getting rid of the rebased commits and then merging master is the better solution here

[jekkos]

Merging private master into my branch yields duplicate commits as well. Think we should first sync master here with public master and then go from there.

I first synced public master (that wasn't aligned with master here) with my private branch which yields duplicate history now. I might want to revert that in this case

[daN4cat]

In my case I went back to the last commit in my private branch and then force commit to my branch. After that I rebased my branch and then submitted to private and master. So I cleaned things. About what's old it's old. Touching it messes up stuff elsewhere.

[jekkos]

MIghtt be a better idea to keep these features rebased with the master of the public repo until we choose to push those changes upstream. Mailchimp stuff will get snowed in now as we have to keep merging upstream into this master which will pollute the history and prevent me from integrating my branche's history in a clean way

[jekkos]

Actually the only master branch I'd like to rebase with is public master and not this one

[jekkos]

As long as those features are on top of what is public there is no issue. History will be polluted and eventually duplicated otherwise

[daN4cat]

Mhhh, not sure I follow.

I considered Mailchimp good enough for the time being so merged into the private master. Or your preference was to leave it out? I did that to reduce the merging story.

To be honest you can even commit attribute to the private master and we keep going only on master merging the public master when needed. So we reduce the branching as it's an expensive exercise.

[daN4cat]

So you can keep going on private master with the attribute only and I focus on consolidating the public master to 3.1.0

[daN4cat]

If you keep going with private master you may want to merge the database scripts to the 3.0.2 to 3.1.0 upgrade one. But I leave it to you.

[odiea]

Testing the current branch with a new db. Much improvement in attributes. I think now it will work out well No receipts work No Detailed Reports work Item Kits modal does nothing. No Items show in Items table. I will test more after these bugs are fixed.

[jekkos]

One more commit for attributes, still some stuff to test + fix

[jekkos]

Thanks for feedback already I need to do a sanity check myself first

[daN4cat]

@jekkos any plan to get this work to a conclusion?

[jekkos]

actually I'd like to finish for 3.1 but first need to pick up again where I left before new year. Just give it another week so I can try to make some progress.

[daN4cat]

Yep no problem, I just wanted to understand where you are. I keep working on public master.

[jekkos]

I guess it's mostly stabilizing and regression testing.. a couple of features I'd like to have like date attribute fields aren't yet completely done and I might postpone that til the end

[jekkos]

problem for dates is that in the data model currently things are foreseen to store just text.. I might also need to support decimals and datetime in that case

[daN4cat]

I would postpone the date time thing to after the rest works through all the layers. Unless you feel it would be too much work to leave it outside on the first pass?

[jekkos]

Ok just did a new force push on item attributes most stuff working again still need to do more testing

[daN4cat]

I force pushed master-private to be again a mirror of the public master and rebased mailchimp branch and kept it in a separate branch.

I understand the preference is to keep going this way but I assume at certain point we need to agree how to merge everything (if you want to do that?).

Also we need to discuss what we want to do with private / public master copies. 3.1.0 looks mainly driven by the community this time, which is very good and finally what we wanted. However we need to decide if we add Steve to the private or not as he seems quite active now and willing to move things forward. Also I see jc, ram and i92 willing to add more, and if we start getting a good group of people to work on larger topics or let say start to assign areas of code then we need to agree if in the end part of the private moves to public. I'm fine from my side to now push Mailchimp work to public as it might be that other people can add something more. But that would be a personal decision.

With regards to people in the shadow just hoovering code to resell it, well I can see from GA that there is still a number of people that attempt, and some manage to work around the current limits. But if the community work starts to take off I prefer that common effort to prevail and drop any constraint and worry. In this way I hope people like jc can feel free to contribute a mobile app to connect to OSPOS instead of mane it a private thing... but we would need to discuss it.

Alternative is to move to private that group but we need to waive copyright restrictions to make sure the contributors are free to reuse for any commercial reason in a mutual exchange way the code.

Thoughts?

[jekkos]

I'm quite happy to see more community involvement lately. This is indeed what I envisioned when I took over the project at the time.

The option of adding Steve to this repository seems most appealing for now as I'd like to see how things go from here. Other people did have the intention to contribute in the past but without actually bringing anything to the table in the end. So I'm still a bit reluctant there.

If you're fine integrating Mailchimp to public then go ahead I'd say so then we have one thing less to maintain. It would be nice to have the work refined / tested by community as always.

For the attribute story I guess I need to round up first and will then decide what I do. Maybe we should already go for 3.1 without it as things in public master are more or less stable now and I like the idea of doing smaller feature packed releases more often.

If Steve proves to be contributing more on the longer term then I'd certainly add him to the collaborators list and if he's interested then he can be in this private repository as well.

[jekkos]

Once we have more active contributors then I'd also like to consider to move the project to a common organization name on github as it's certainly not only me doing all the work. I think it could also be better for the project's visbiilty in the end.

[daN4cat]

It's ok, makes sense.

WRT Mailchimp being made public, I need to think about it a bit more. In the end a lot was done to ramp up the software to a new level so it's time to get something back in exchange of that work. More contributions later.

[odiea]

Getting closer. After the Sale receipts are showing a myriad of php errors. Below is that Item Kits modal now looks like. Still issues with Items not showing Company or Category.

[jekkos]

Ok found that I disabled php errors for some reason, can now reproduce most of these

[jekkos]

Ok did another rebase with latest master + fixed bugs regarding receipt completion, item modal error and item row update (category + company_name)

[jekkos]

I'll probably be squashing all of this into one commit as well. Makes it easier to rebase with other functionalities

[odiea]

Let me know when it is ready to test some more.

[jekkos]

Beside the git history I think this is ready to go

[odiea]

Items not showing in Items Table. I got the following error after completing a Sale. Also the following issue with Attribs Modal.

[jekkos]

Ok Items should show again, also this string is updated, but sale error I can't reproduce. Did you use a specific mode or something? I went to this line in the code but it seems to pass correctly. Or maybe I need to enable display_errors again.

[odiea]

After doing 10 more sales that error quit showing. Returns not working. It displays the pos number select the pos number . Nothing shows in register. I tried again and the first 4 sales do not return but the 5th sale on returns ok. Quotes work ok. Invoice gives the following error. Attributes language now showing on modal. Adding new items - hit and miss as far as cat or supplier showing after adding a new item. Updating the item works 50% of the time to show cat or supplier. When that happens I do a refresh and it appears.

[odiea]

I got the following error trying to generate barcodes.

[odiea]

2 more issues in Items

[jekkos]

OK thanks for testing, needs some more review for sure

[daN4cat]

@jekkos any plan to get to an end or are you waiting for Steve to submit the tax rework before resuming this?

[jekkos]

Not really waiting for him to finish in any way. I stopped progressing on this one but was about to have another look now. Actually I'd like to add it to a separate release, otherwise scope for 3.1 will be too big.

[daN4cat]

Yes, separate release it's fine.

I'm just waiting for this tax module rework as we will need to test it a bit and then release 3.1.0 with probably some other bug fix and similar stuff.

[jekkos]

Ok did a couple of extra fixes

• inventory + stock modals should be fine
• item kits modal $print_option error was fixed
• invoice template got fixed
• sale return should work ok
• might still be some issues with selecting categories in items (need to look into that)

[daN4cat]

@jekkos OK, cool. I'll try to test since @odiea is enjoying his life in a sunny location.

Did you publish the branch in public on purpose? It's now a branch to your public repository.

[daN4cat]

Also I'm not sure whether you rebased with the latest master or not. But I'll check the branching this evening.

[jekkos]

Ok I did not mean to publish it in public yet. We'll set something up for a next release (at least that's my idea).

Currently known bugs to me are

• Category field might not be reselected correctly after reopening the modal. Although it seems to be saved in db correctly.
• Changing a parent attribute's type might cause some issues with items.. Need to think how to handle this kind of situation

[jekkos]

Ok rebase is done with latest public master. Seems to init the db well. Haven't really tested further

[jekkos]

Most of functionality seemed ok although it needs more testing.

[jekkos]

Did another push of rebase with latest master. All seems to work fine