Is this implemented yet in roastime v4? Settings → roast config → roast batch naming. I have the prefix and batch starting number – but it is not adding it to my roasts. What am I missing? Thanks
Does anyone use automated batch numbering in roastime v4?
Hey @nbeans
This was a partially built feature that was never fully implemented. (I actually thought it was disabled)
There just wasn’t enough demand at the time to continue working on it (there were some complexities involved). I can create a ticket in our queue and we can discuss at our Eng meeting this week.
I used this with artisan back in the day. On the bullet it may be more useful for users with multiple bullets. I usually add the serial number in my total so I can search.
Not going to beat a dead horse, just don’t think it would be too hard to add a prefix that adds up sequentially every batch. I’m a data guy, like having and referencing my data. Have to manually look back then add a number for my current batch (I’m older and forgetful). They have it in the settings, other software has it, there is a use case, just make it work I guess. If they make bigger roasters down the road, they’ll have to do it. Probably should just fix it now. Maybe have an option to show the date and time in roasts, that could work also.
***Solution
Make another field for batch. That’s what is probably messing up the shared roasts online (or programmer thought proccess) . Make a new field for the roast batch instead of adding it in the roast name. Make it a hidden field for the public, but the roast creator can see it. Bang, bet that was the hold up. Problem solved! All I got.
@mcaillio hopefully you can forward this to your engineering meeting.
Hey!
The problem that arose was that we have an auto incrementing field from the firmware (roast number). We were using that, but we found that sometimes it did not increment as expected which resulted in some duplicates.
The solution is we add a new field, correct - but that also means we need to run a migration to auto increment everyone’s existing roasts. While that may not be “complicated”, it does take time and effort for which we have not prioritized based on current demand.
So I guess TLDR; it isn’t about difficulty, it is about resource capacity and prioritization.
If there is in fact a demand for this feature, we can definitely re-prioritize some things around.
Thanks!
1 Like
As we stand you have broken code. You should either fix it or remove it from the settings. Probably just as easy to fix it than to get rid of it. Once you fix it, run your query and go to bed. Even with millions of roasts, it still probably will be done by morning. Sorry, it’s an odd thing to see a feature that is broken. Seems just as simple too fix it.
My apologies for coming off so strong, just constantly deal with this at my company. Usually ends with me asking if we simply can do…
Well I started a poll on Facebook. The poll is only good for 2 days (Facebook defaults). If you think the increment batch numbers should be fixed, please vote!
I agree that it should be hidden (and I actually thought it was behind a feature flag, so that is our mistake).
I hear you on fixing it, but as we both know, in the real world - things aren’t as simple as that.
You are making some assumptions about how we store data. For example - we don’t store data in a SQL database, so we can’t just run a query. All roasts are stored in file storage as raw JSON files. We have an ES index with certain fields that leads us to these files - but we would need to load every single (millions as you said) of files and update those files and re-upload them back to file storage.
So it does involve writing a little script, but we aren’t going to test it on production, so run against a sample on a test environment. Let’s say the above takes a day all in.
After that, we need to run against prod. This will likely take a day or two, but other work can be worked async, so no big deal.
Then we also need to do some minor updates to the actual RT code to use those new fields. We also need to add it to the local indexes. Again, not difficult - but tedious.
After that, we need to add E2E tests to our suite. Let’s add another day for the previous and this task.
We usually do some regression testing after that which also takes other resources.
All of this may just take a few days to release it out - but we have a backlog of 100s of other requests with varying priorities and we are not a large team. If the broken feature is causing too much frustration - we can hide it. We did always plan on coming back to it, but like I said - I actually thought it was already hidden behind a feature flag, so thank you for bringing it to our attention.
I am not on the FB group. Do you mind posting the results here? Thanks again, hope I am not coming off to strong either. Just want to clarify that this may be a bit more resource consuming than one may assume for such a feature.
2 Likes
Haha… Awesome reply. Maybe don’t hide it so you don’t forget about it. 
FWIW - you can do a poll on this platform (Discourse) as well. Create a new discussion, select the cog wheel and select “Build poll” - and you now have a poll. 
1 Like
Facebook results:
1 Like
FYI - I prioritized this ticket for this sprint.
3 Likes
Thank you sir!
1 Like
We have opted to change the core functionality of this feature, so it is going to take a little while until this gets done. The ticket is in the queue.
2 Likes