"Open" is test, in progress, open, re-open, etc. - anything that is not done/closed.
IMPORTANT:
First-time users, please read Key to reporting before posting any content to this table.
Database query testing by non-IT staff on hold pending official release by IT.e"
# | Reporter | Submit Date | Category | Summary- | Image Sample / Issue to Description | Browser Version | Section where issue found (Shop, Cart, etc.) | Priority | Assigned to | Status |
---|---|---|---|---|---|---|---|---|---|---|
264 | Janice | 6/4/14 | W | Results Available date not refreshing when quantity changed | (1) search for furniture bags & then change qty on item 3205 to 10, available should change from 6/5/2014 to 6/7/2014 (manufactured item) (2) search for saddle pack deli bags & then change qty on item 6700 to 1000, available should change from 6/5/2014 to 9/3/2014 (purchased item) | Firefox | Shop Results | 2 | Sal | Open |
263 | Susan | 6/4/14 | W | Saved item product detail tooltip/hover | Quantity, s/b: "Quantiy 8.4 Thou"; missing "Count/Case 450" on far right. Labels listed vertically should be bold gray.See Steve's revised spec below. (I would refer to the original spec but I felt the fake data in it would confuse matters...) Staging
Steve's revised spec | FF | Saved Items | 2 | Cathy | Open |
262 | Susan | 6/4/14 | W | Godzilla, hover over exact match data | Get a spinner when I hover over 'Yes" under exact match. In firebug the error is "item is not defined" ?; within the pop-up I can hover elsewhere and hovers work fine, but when I close out of popup, site has frozen up. Need to close tab and reopen. (This doesn't seem to happen when item is not an exact match.) | FF | Shop, Godzilla | 2 | Sal | Open |
261 | Susan | 6/14/14 | W | Cart save message Field 53 of the contact record stores which pop-ups they do not want to see. These codes are found in SYSTBL SUPPMSG.LAD. UI needs too call RPC$CONTACT_SUPPRESSMSG. Pass in FLAG = ASC. | Specs have a "don't show me this again" checkbox; this is not showing in the staging version.
| FF | Cart | 2 | Chuck | Open |
260 | Judy | 6/3/14 | D | SHOPPINGCART.USR fields 44 and 45 are being updated with "True" instead of "1" | Change True = 1; False=0 before writing to database (or have UI send you 1/0) | FF | Checkout | 1 | Wayne | Test |
259 | Judy | 6/3/14 | W/D | Some of the DEFAULT.VALUE back-end widget programs aren't working correctly because they no longer have the default value of all previous fields. Note: Bug #240 has been canceled. This takes its place. | UI Side - when calling RPC$SEARCHFIELD_GETDEFAULTVALUES, need to pass to the back end a delimited list of the shop widget field names for any field that has 'changed'. DB Side - Modify RPC$SEARCHFIELD_GETDEFAULTVALUES (again) to update the SHOP. named params with the default value for each field. Only update the SHOP. name if the field has NOT changed (if it exists in the delimited list sent by the UI, do not change the contents of the SHOP. param). *** This is logic that you already coded awhile back (without the list of changed fields), and since setting some of the defaults was causing major problems with the widget because default.value was null (overlaying dimension fields such as Width, Length, Gauge), we removed the code. Unfortunately, the code was not preserved (sorry). Also, please remove the special logic in FCT.BTWNHOLES.DEFAULT.VALUE, FCT.COLOR.DEFAULT.VALUE and FCT.OPACITY.DEFAULT.VALUE where it's executing FCT functions to try to determine the default value of previous fields. Once this new logic is in place, you should just be able to use the SHOP. variable (ie, replace DMATERIAL with SHOP.MATERIAL) To test, try Layflat Bag, In Materials check 'VCI'. The FCT.COLOR.DEFAULT.VALUE program should immediately change Color = Std Blue VCI and FCT.OPACITY.DEFAULT.VALUE should immediately change Opacity = Tint. 2nd test: Layflat Bag, 12x24x2mil, Venting, Normal, Random Venting, One Side, 3 Holes per item: defaults s/b: 4" from side, 5" from bottom, 5" between holes | FF | Shop Widget | 1 | Chuck/Wayne | Open |
258 | Steve | 6/3/14 | W | Design adjustments for Share Shadowbox (part 2 - Share with Customer)
| FF | Shop/Share | 2 | Sal | Open | |
257 | Susan | 6/3/14 | W | A couple of bugs with validation errors and behavior when going between both aminefree choices and and incompatible color selections.
Hold off until bug 259 is done | Select layflat; then color/opacity (leaf green/tint); then expand materials menu; then select anti static - aminefree pink. BUG-1:Do not get error message (should see 033: ERR.MSG = "Color must be Pink for AmineFree Pink" (and “do you wish to continue?”, and color being changed to pink only after saying Yes). Instead, no msg, and color menu automatically changed to pink, tint. After selecting milspec type, color menu disabled. (Good?) Next, click amine free clear/color - get 'pink cannot be selected for aminefree clear/color; continue yes/no, click yes. Color menu reenables, changes to clear (Good.) Open color menu - select leaf green/tint. Reopen materials menu. Aminefree clear/color still selected (Good); all other anti-stat parameters still intact. Switch to aminefree pink; BUG-1 (again): no error message; color menu automatically chagnes to pink/tint... BUG-2: color menu is still enabled ... Reopen color menu; pink/tint selected; change color to med blue; get error msg: 'color must be pink for amine free pink; click ok; top menu selection changes to pink, tint, but medium blue radio button still selected onscreen - remains this way even after collapsing color menu, expanding materials (don't make changes), then reexpanding color menu. | FF | Shop, materials & color menus | 2 | Wayne | Open |
256 | Judy | 6/2/14 | D | Availability Date in Results for a Purchased Stock Item is incorrect when there are no purchase orders
6/4/14 JC: issue involved the REQUEST.QTY not being initialized. Changed code to set REQUEST.QTY to 1 if REQUEST.QTY = "" | Created new deli bags items in DEV. These are purchased items, and they have no p/o's established yet. They have no inventory in INVWHS yet (except for one of the items). When I do a search for Saddle Pack Deli Bags, I see the 6 items 6700, 6703, 6705, 6707, 6710, 6713. All have a date of tomorrow (it's late in the day). Only item 6700 has inventory. The other 5 items have no inventory and no purchase orders but are also showing tomorrow's date. The purchasing lead time is 90 days, so it should be showing DATE()+90 as a date for these 5 items. Please check logic in WEB.AVAILABILITY.OPTIONS. Also, LD.INCLUDES WEBPRODUCTITEM.READ has a hardcoded qty of 1 with a note saying this should be replaced with REQUESTED.QTY at some point. Please investigate what is needed from the UI to make this program work with REQUESTED.QTY instead of a hardcoded 1.
| FF | Shop Widget/Results | 1 | Janice | Test |
255 | Susan | 6/2/14 | W | Product description shows in results but not in cart | When I click the purple product name/dimensions for this particular item in the cart, it does not expand to show full product description. However, it does expand when it is in the results list. | FF | Cart | 3 | Ed | Open |
254 | Steve | 6/2/14 | W | Design adjustments for Share Shadowbox
| FF | Results/Share Shadowbox | 2 | Sal | Open | |
253 | Susan | 5/29/14 | W | M&A menu - additives - are they resetting or not when material is changed? | On the heels of the task below in 252 (returning MOD 1362 to widget), reopened M&A menu; changed material from 'non scratch' - to 'standard' additives appearing to re-set after changing material (boxes all now unchecked) - but seem to be retained in the M&A hover tooltip - before (1) and (2) after clicking find. Before clicking 'Find' After clicking Find | FF | Shop, M&A menu | 1 | Sal | Open |
252 | Susan | 5/29/14 | W | Godzilla issues | I returned a MOD I had just saved to the widget (MOD 1362). I notice the following issues with the way the Godzilla results are shown:
| FF | Shop, Godzilla | 1 | Chuck | In Progress |
251 | Janice | 5/29/14 | W | Cart Name not clearing between users (potential problem for CE) SP, 5/29 - see also issue 228. | Login as contact 17278, place item in an unnamed cart, logout; do not close browser; login as contact 17264 who does not have an active cart; go to cart, cart name is now the prior bill-to number (33224). | Firefox | Cart | 1 | Ed | Open |
250 | Susan | 5/29/14 | W | Additives not being disabled when polypro chosen as material. | All additives are selectable and should not be; and am able to run search.
| FF | Shop, M&A menu | 2 | Sal | Open |
249 | Janice | 5/29/14 | D | Customer creation using contact number for contact (attribute 26), should be null Janice 5/30/14: the drop ship flag is not being set properly. This needs to be fixed on the UI side as well as the backend. UI needs to send the proper flag via SHIP.MODE and the backend needs to set the drop ship flag on the customer accordingly. | In checkout, entered new customer information & when the order was created, it created a new customer but the contact is the contact number, this should be null. Also, the drop ship flag (attribute 17 in CUSTMST.USR) is not being set. Janice 5/30/14: the SB user (CUSTMST.USR <2>) needs to be modified as well: IF OPERATOR # '' THEN set to SB user ELSE "WEB" & inactive flag (CUSTMST.USR <75>) can be null - doesn't need to be 0. | Firefox | Cart Checkout | 3 | Wayne | Open |
248 | Susan | 5/29/14 | W | M&A menu, Metallocene - line wrapping
Chuck 06/02/2014 Test after next deployment sp, 6/4/14, fixed | Can we squeeze "storage" onto the same line? Would prefer that this does not wrap; if it does, would prefer storage to align under "Metallocene" Staging: Specs: | FF | Shop, M&A menu | 3 | Chuck | Done |
247 | Susan | 5/29/14 | W | MODs given price breaks, then saved, not making into saved items? | Ran search using stock number (1485); results included some YMAC MODs. Set custom price breaks for one of the MODs, saved breaks, then saved the item. Did not get save item pop-up, but did get the fleeting green success message. Item not included in saved items list. Re-ran same search, selected one of the other MODs. Did not give it price breaks, just clicked save.Got dialog box; clicked save; got fleeting green success message (noticed it did include a MOD#); saw item in saved items list (MOD1361). | FF | Shop, results, price breaks, saving | 2 | Sal | Open |
246 | Susan | 5/29/14 | W | Heading for count/unit for continuous tubing should be "Feet/Roll" - not "Count/Roll" | See image below. | FF | Shop resutls | 3 | Sal | Open |
245 | Susan | 5/29/14 | D | Widget forcing full gauge as soon as Tubing & Sleeves > Layflat Tubing and > Gusseted Tubing categories are selected. | I ran a tubing search with widget settings that I thought would return a stock match (1885) but it only returned MODs; I finally figured out that it was setting gauge to full as soon as I selected "layflat tubing" (not easy to notice if you're not expecting it). I tested all the other categories under tubing & sleeves and it is happening for gusseted tubing; not happening for any of the others in that group. Since we make these products at nominal gauge it should not be forcing full gauge, correct?
Searching using the item number produces the exact stock match, plus two less expensive, nominal gauge MOD results:
| FF | Shop results | 2 | Sal | Open |
244 | Susan | 5/29/14 | W | Cannot add to cart. SP, 5/29 - 11:30 am. Worked with Sal; it seems to be working. Could be a latency issue. Will keep an eye on it. Marking "hold." Will close if it doesn't happen again today. | I cannot add fresh or saved MODs to cart (again - this was issue 194 which we closed yesterday). I can add stock. Symptom: Get a spinner briefly, then nothing seems to happen. Will give it more time next time. | FF | Shop results | 1 | Sal | Done |
243 | Susan | 5/28/14 | W | Getting YMAC that is identical to exact MOD match in every way (sleeves). | Reversing width/length produces correct YMAC result? | FF | Shop, results | 2 | Sal | Open |
242 | Susan | 5/28/14 | W | 2-part issue with zip code Zip code not clearing between unique users; an unlikely scenario for real customers, but a potential problem for CE. (Clicking reset and clearing cache do not resolve; zip persists.) Regardless, zip code not passing from saved item back to widget.
| Log in as Joan (customer 002180). Joan's starting widget - populated with zip code last used by Sally (and NOT by Joan; Sally works for customer 2916):
Joan's active cart (upon login - no searches or additions since login): Joan's saved items:
Result after pulling MOD 1343 into widget - widget not back-populating with the original zip code for the saved item. Started from scratch. Cleared active cart; started with empty cart and no zip in it. Reset widget (had to clear zip field manually). Returned Saved MOD 1329 to widget. Got prompt for empty zip code. This should not happen; item should back populate with its original zip code and is not.
| FF | Shop, saved items, Cart | 1 | Ed | Open |
241 | Susan | 5/28/14 | W | (Discovered while testing issue 194.) Something funky going on with MOD pricing when going from results to cart.
Ed - please work with Wayne on this for DB information. | 1-Fresh MOD result, after clicking "Add" (with min quantity; data correct) 2-View upon moving to Cart tab (price is correct, but there is a spacing issue) 3-After rounding quantity up to nearest K (Price plummets.. incorrect data?.) | FF | Shop to cart | 1 | Ed | Open |
240 | Judy | 5/28/14 | W | Back End DEFAULT.VALUE programs need to know what fields have been changed 6/4/14 (Judy) - I canceled this bug. It was re-entered as bug #259 above and assigned to Chuck and Wayne. | DEFAULT.VALUE programs need the SHOP. variables to contain the default values from previous fields. If we know which fields have been manually changed (meaning the UI won't use the default value), we can change the SEARCHFIELDS program to reset the SHOP. variable to the default value. Once this is complete, Judy will revisist all DEFAULT.VALUE program to remove un-needed logic. All programs should the be able to use the SHOP. variables. | FF | Shop Widget | 1 | John | Done |
239 | Susan | 5/28/14 | W | Typing cart name, get cryptic pop-up msg. Doesn't like spaces. | I think this is happening when spaces are typed - 2 variations below.
| FF | Cart | 3 | Ed | Open |
238 | Susan | 5/28/14 | W | Save item dialog originating from cart is missing heading, locations, and entire 'add item numbers...' section | Save item from result (RIGHT)
Vs. Save item from cart (WRONG)
| FF | Save item pop-up, Shop v. Cart | 2 | Sal | Open |
237 | Susan | 5/28/14 | W | Availability date and pricing are off for this stock select search 6/2/14 (Judy):
| FF | Shop results | 3 | Sal | Open | |
236 | Susan | 5/28/14 | W | Now product detail headings/labels are showing even though no non-standard parameters are chosen in widget. | Related to issue 30 & 102?
| FF | Shop results | 2 | Sal | Open |
235 | Susan | 5/28/14 | W | Cannot access anything having to do with saved items. SP, 5/29, seems to be resolved. Closing. | Get the 'oops!' error - this was before and after recent deployments, clearing cache, logging out logging back in etc. | FF | Saved items | 1 | Sal | Done |
234 | Susan | 5/28/14 | W | Strange things happen (inconsistently) with MOD availability date when I toggle freight for results. Different packaging should not change the availibility date of an item.
| Search 1: 1 MOD exact, 1 MOD YMAC, both have 6/20 avail. date. Toggle freight for first result to not included; date changes to 6/11. Toggle freight for YMAC result to not included, date changes to 6/11. Toggle freight back to included for each - date remains at 6/11. Search 2: 1 MOD exact, 1 MOD YMAC. Both have 6/20 avail. date. Toggle freight for first to not included, date changes to 6/11. Toggle freight for YMAC, date stays at 6/20. Toggle freight back to included for each, date remains at 6/11 for both. | FF | Shop results | 2 | Janice | Open |
233 | Susan | 5/28/14 | W | Sharing items bypasses save process | When you click "Send" when sharing a MOD item, system should give you save item pop-up. Not happening. | FF | Share item (originating from search result) | 2 | Sal | Open |
231 | Wayne | 5/27/14 | D | Incorrect GAUGE Sorting | WEBPRODUCTITEM_GETBYFILTER is sorting by GAUGE. This dictionary is correctly setup as a N’umeric Right-Justified field, but because the data in this ITMMST field has the decimal point stored, it doesn’t sort correctly. Right justified it sees 1.25 as being higher than 1.5. Left justified fixes this problem, but once we get to 10+ the sorting will be wrong again. | n/a | Shop | 2 | Wayne | Done |
230 | Susan | 5/27/14 | W | Getting Godzilla result when I shouldn't. | Specs say: "To get a Godzilla result you need to enter all required dimensions including gauge; but gauge matches in Godzilla will still include items with different gauges. "
See also issue # 165 - this is another 'no results when there should be' set of results. I believe I should be getting the "We can make gussetted bags - enter full dimensions bla bla bla"(and close stock matches?)
| FF | Shop, results, Godzilla | 2 | Sal | Open |
229 | Susan | 5/27/14 | W | Editorial/formatting issues with Godzilla Chuck (06/04/2014): Please test after next deployment. Not sure what CSRL is either. It's coming from the database. Maybe 'Case/Roll' count. SP, 6/4/14 - reopening, but most orig issues have been fixed (thanks) We should strip out CSRL; I suspect it is a prefix to "Count"; it's not intuitive - "count" should be sufficient. Most issues fixed, see comments in cell to the right, and issues noted below which I did not see first time around: | Under Exact Match column head:
Product comparison tooltip box:
| FF | Shop, results, Godzilla popup | 3 | Chuck | In Process |
228 | Susan | 5/27/14 | W | Sharing carts - when I click the button for sharing the full cart, system hangs with spinner. | Tried this as two different users, 2 different bill to organizations. Update (3:25 pm): Here is another wrinkle - these 2 different users from 2 different organizations seem to have the same active cart - though the contents are different. I am pretty sure I had saved Joan's cart under that name before creating Sally's cart from scratch. I am pretty sure I never named Sally's cart "joan's humonguous cart"; I will attempt to recreate from scratch. Update 3:33 pm - logged sally out and logged back in. Cleared cart. Started new cart w/same 2 stock items. Saved as "Sallys petite cart"; logged sally out, logged back in as Joan. Widget was populated with zip code used for Sallys petite cart. Searched for some new items. Put in cart, clicked to cart, cart already named as sally's petite cart. The "joan's humonguous" and "sallys petite" appear in both users saved carts lists. Here is Joan's
| FF | Cart | 2 | Ed | Open |
227 | Susan | 5/27/14 | W | Sharing items | 1-I get partial red error message, in spite of apparent success sharing the item. 2-There is no sharing history showing in saved items list for the item being shared (mod 1266, customer 2916, contact 17279) - am guessing it just hasn't been programmed yet, reporting just in case. | FF | Sharing saved item (from results) | 2 | Sal | Open |
226 | Susan | 5/27/14 | W | Godzilla issues SP, 6/4/14 - confirmed w/Judy that if an item exists in both a cart and the saved items list, there should be one entry in the list per location. | To test Godzilla, I ran a search for something similar to but different from one of my saved items:
I got the Godzilla result verbiage and link (good); clicked link to open pop-up; expected to see "saved items" as one of the locations (and MOD1266 under names/tags column). Instead, only saw saved cart (4/22) as location. Based on hover details, I had clearly returned MOD1266 as the similar item. I clicked the saved cart link and was brought to saved cart tab with empty list, but the cart name field was populated. (Not sure what happened to all the saved carts, I am pretty sure there were some recently.) Saved item that fresh search was based on: My fresh result My Godzilla pop-up Differences between saved and fresh highlighted appropriately.
This is what I saw when I clicked Saved Cart link:
| FF | Shop, results, Godzilla | 2 | Chuck | In Progress |
225 | Judy | 5/27/14 | W | MOD YMAC result now showing 'cases' instead of 'cradlepacked' | In Results, the alternate MOD YMAC is showing 'cases' instead of 'cradlepacked' as it was before. The first MOD choice s/b Cases or Rolls, Boxed and the second s/b Cradlepacked. | FF | Shop Widget/Results | 1 | Sal | Open |
224 | Susan | 5/27/14 | W | I am not getting the prompts I should be getting when returning Saved MOD to widget and changing freight terms or zip code. 5/28 (Judy) - this has not been programmed yet | The design specs state:
I am not getting that prompt. | FF | Saved items to widget | 1 | Judy | Open |
223 | Susan | 5/27/14 | W | Find button not being disabled when I return unexpired or expired quotes. | Design specs state Find button should be disabled for unexpired MODs until the user changes something that re-enables it; ambiguous on expired MODs but I assume it should also be disabled for those as well. | FF | Saved items to widget | 1 | Judy | Open |
222 | Susan | 5/27/14 | W | Not seeing pricing history when I expected to. Either Wiki specs are wrong (or I am misunderstanding them) or this is a bug. Please advise. 5/27 (Judy) - Per John, this has not been programmed yet. Will be taken care of when we add the 'changing existing price' question. I will leave this bug open so that it can be tested when programming is complete. | Logged in as customer 2916, contact 17279. Retrieve MOD 1294 saved on 5/8. Widget seems to back populate appropriately and shows 1294 as an exact match (presumably with current resin prices). RE what should happen next (when all the user has done is retrieve the item), the Wiki states:
When I return to Saved Items, I do not see any pricing history icon (see design series 4 within Saved Item design specs):
| FF | Saved items to widget | 1 | Judy | Open |
219 | Steve | 5/23/2014 | W | The entry fields (active and disabled) need some adjustment.
Leave in focus entry field as is. looks great. Leave drop down as is. | FF | Widget | 2 | Cathy | Open | |
218 | Steve | 5/23/2014 | W | Under Materials and Additives, selecting "Anti Static" displays a default for number 2 Select a Resin Type" There should be no default here. This is a stepped process and the user must make a choice for #1 first. | FF | Widget/results | 1 | Judy/John | Open | |
217 | Steve | 5/22/2014 | W | Related to Susan's discovered issue #165. I tried to do a broad search and it just froze. No results would show. Wayne - please test this to see if it is still an issue. If it does not happen, please make sure to check with Steve on his steps to try and recreate. We think ths may be fixed. sp, 6/5/14 - I don't think it "froze" for Steve; I think he thought it froze b/c he got nothing. please be sure to look at #165. To this day, I continue to get no results for certain searches when I should - incomplete dimensions for products that we should be able to make (and quote, with complete dimensions given). I don't log them b/c we have this issue and #165 already open and assigned. Please let me know if you'd like to see additional examples.
| FF | Widget | 1 | Wayne | Open | |
216 | Steve | 5/22/2014 | W | Find button adjustments
Ed: Adjusted accordingly. Please specify a color in the future, no guessing here! Deployed to staging Friday, 23 May @ 4:30pm | FF | Widget | 3 | Ed | Test | |
214 | Susan | 5/22/14 | W | Venting menu: Please check all validations for all permutations of venting selections. | Issue I: Selected micro-perf; all other fields appeared disabled, but I could not proceed with that selection due to validation error. Tested in production and there are no further inputs when micro-perf is selected. Issue II Changed venting selections from micro-perf to normal, random, both sides - entered 3 in number of holes...
...and got this error: These settings are allowed in production with a bag of this type/dimensions: I was able to proceed without getting error with normal, random, one side, 3 holes and normal, user specified, 3 holes, 2" side, 2" bottom, 6" between. Was able to click Find, widget scrunched up,but then nothing happened - didn't get a spinner. After 3 minute wait, abandoned all hope. | FF | Shop, venting | 2 | Judy | Open |
213 | Janice | 5/22/14 | D | Charity code moved from SOHDR.USR<74> to MSTRORDHDR.USR<3> | Charity code not written to the correct file. The charity code has been moved from SOHDR.USR attribute 74 to MSTRORDHDR.USR attribute 3. The order creation routine needs to ensure that it now gets written to the MSTRORDHDR.USR file. | Firefox | Avante | 2 | Wayne | Test |
212 | Janice | 5/21/14 | W | Unable to test CPU orders because the wrong screen displays | Unable to test CPU orders because the wrong screens pop up: (1) login with an empty cart (bill-to 002180, contact 17264; (2) go to Cart & click ship-to & select Pick up - Sterling (01564) (correctly displays as a pick up); (3) quick add item 3190 qty 20 & receive message cart updated successfully; (4) click on checkout; (5) Ship-to Address screen comes up with message order will be picked up in STERLING, MA. Where do you plan to deliver this order? Enter delivery zip code 01824 & click find, get a list of what looks like " ". Other times do same first 4 steps but get the Ship-to Address screen for a ship-to zip - We have located 64 matches for this zip code (01564). | Firefox | Cart Checkout | 1 | John | Open |
210 | Susan | 5/21/14 | W | Timing of stock number validation in Quick Add feature. | It would be better to get the "### not a valid item number" message before entering quantity and before being prompted to fill in an empty zip code field. | FF | Shop | 3 | John | Open |
209 | Susan | 5/21/14 | W | Gauge not fully resetting with product class/category change. Chuck (06/03/2014) The full gauge is coming back from the database for all sheeting. This I by design. | Run search for furniture bags, 1 mil - gauge automatically changes to full (good). Do nothing with results. Go back to widget, change product class to film & sheeting. Whole widget seems to reset (good). Then select category (gusseted). Gauge returns to full (field empty as it should be). | FF | Shop | 2 | Chuck | Closed |
208 | Susan | 5/21/14 | W | Edits/formatting in zip code conflict pop-up Chuck (06/03/2014): Test after next deployment Sp, 6/4/14 - fixed | Spaces in the name are underscores in the first instance and missing in the second instances. Please align the parenthetical statement as indicated by red vertical line. | FF | Shop | 3 | Chuck | Done |
207 | Steve | 5/21/14 | W | Made on Demand text wraps below the "Made on Demand" header. Put a line break at the start of the 2nd sentence and center both lines vertically. Ed: No line breaks needed, adjusted css accordingly. Hyphen is a data issue from back end messaging, write up bug as separate issue. Deployed to staging Friday, 23 May @ 4:30pm | FF | Shop/results | 3 | Ed | Test | |
206 | Steve | 5/21/14 | W | Please make enabled "All" text in widget black (#000). Right now it uses #666 gray and looks disabled. Please keep gray/disabled version of "All" text for disabled entry fields. | FF | Shop/results | 2 | Phase 1.a | Open | |
205 | Susan | 5/20/14 | DB | Not getting market place results.
Janice - test this on Avante and see Judy | Did not do exhaustive testing, but we are not getting marketplace results when we should be (according to Judy). Dimensions showing in widget should produce an exact MOD match.
| FF | Shop/results | 1 | Janice | Open |
204 | Janice | 5/20/14 | D | Split Ship Bundles creating two sales orders instead of one | When there is a split ship instance in the bundles (two bundles for the same item on the same date from two different warehouses), the sales order creation should only create one order for the two bundles instead of two separate orders. Two orders should be created for ship & backorder instances (two bundles for same item from the same warehouse but for two different dates). | Firefox | Checkout Sales Creation | 1 | Wayne | Open |
202 | Steve | 5/20/14 | W | Saved Item/Tagging layer has text issues.
Chuck: 06/03/2014: Please test after next push to staging | FF | Saved Item Tagging screen | 2 | Chuck | Test | |
195 | John | 5/19/14 | D | Reverse order of validations in RPC$MODITEM_VALIDATETOCART | Do the 'is this MOD Item in the active cart' test first, and if that passes, do the next test to see if the Quote# is in any other cart. | N/A | Add to Cart | 2 | Wayne | Test |
189 | Susan | 5/15/14 | W | Fresh MOD availability link date does not match what's in pop-up Sal 5/15/14 17:28 - Per Jim : Guys – let’s not do any more work on the Availability Popup bugs at this time. We need to regroup and get straight on what we really need to happen. | Date of 5/29 in pop-up does not match link date of 5/22. I did not change anything with the result quantity or anything else before opening pop-up. Same thing with saved/numbered MOD a few moments later: | FF | Shop/results | 1 | Chuck | HOLD |
188 | Susan | 5/15/14 | W | Stock availability date/link not updating with change in quantity Sal 5/15/14 17:28 - Per Jim : Guys – let’s not do any more work on the Availability Popup bugs at this time. We need to regroup and get straight on what we really need to happen. | I increased stock quantity to trigger an availability pop-up with split shipment options and noticed that the availability date itself is not matching the plus-72 hr. date in the popup.
| FF | Shop/results | 1 | Chuck | HOLD |
181 | Judy | 5/14/14 | D | WEB.MODITEM.GETPRICE is calling printer ink qty calculations when job isn't printed | Printer Ink Item# (around line 4342) is correctly doing logic only when SHOP.PRINTED. But the next section (starting around line 4355) is happening all the time. These CASE statements should only occur when SHOP.PRINTED. Please check all random repeat print-specific logic to make sure it is only occurring when SHOP.PRINTED. | Firefox | Shop Widget/Results | 2 | Wayne | Test |
172 | Janice | 5/12/14 | D | Sales Order Creation records missing data Wayne - 5/19/14 : On WEB orders, the hold code (SOHDR<76>) automatically gets set to "1". Also, related to this, available to pick quantity (SODET<33>) will get set to null. | Sales order creation from web is missing information or contradicts data on the following sales order files (vs. what is created thru Avante) - see Avante order 109172A & web order 109171A: SOHDR is missing the following information: city, state, zip (<7>), domestic cost of sales (<11>), customer PO date (<13>), ship via code (<29>), term code (<51>), fob code (<52>), acknowledgement contact (<57>), current cost of sales (<127>). Hold code (<76>) differs between Avante & web SOHDR.USR: credit card date (<8>) has / as value on web, c/s request packslip hold (<71>) set on web, c/s request lock (<73>) filled in on web SODET is missing the following information: domestic cost (<6>), description (<12>), domestic extension cost (<22>), pick quantity (33), current cost (<63>), current extension cost (<64>). UOM (<2>) differs between Avante & web Janice 5/20/2014: order header & detail still have incorrect tax information (seems to be related to when bill-to customer is a different state (GA) than ship-to customer (MA) - see WEB order 109227A); order header missing contact <8>, customer PO date <13>, & fob code <52>; header user has invalid code for label source (1); detail sales posting code <49> differs | Firefox | Sales Order Creation | 1 | Wayne | Test |
166 | Susan | 5/8/14 | W | Web discount in cart 5/12 (Judy) - UI s/b calling RPC$UTILITY_GETSESSIONINFO when contact logs in. This has not been scheduled for programming yet. Should be done soon. | Not showing 1% web discount. | FF | Cart | 3 | Ed | Open |
165 | Susan | 5/8/14 | W | Search - I got nothin Sal 5/12/14 12:02 - This issue seems to be fixed, I couldn't reproduce. Please re-test. SP, 5/13/14 - (~3:25pm?) I was able to repeat with the same parameters on the right (category, zip, dimensions, color). SP, 5/15/14 9:31 - It continues to happen -this time with gusseted 11 or 13' W/all-D/all-L, 4 guage - I get nothing. And with 11W/all-D/all-L, 2 gauge, I get this: I should not get an exact MOD Match with incomplete dimensions, but I should be getting someting like this, right? (Taken from specs so of course search details don't match): SP, 5/27 - cleaned out outdated reports above. Issue still happening with certain searches that I am able to execute on production site (albeit with complete dimensions). | Should validation error have prevented me from getting this far - or should search have yielded something else like "we can make that, enter complete dimensions"?
| FF | Shop widget | 1 | Open | |
163 | Susan | 5/8/14 | W | Availability pop-up, stock, full quantity not available at primary warehouse SP, 5/27 change status to hold due to open questions RE availability pop-up functionality (see 188+189) | Please see edits below.
| FF | Shop, results | 2 | Chuck | HOLD |
162 | Susan | 5/8/14 | W | Availability pop-up, stock, full quantity not available at alternate or primary warehouse SP, 5/27 change status to hold due to open questions RE availability pop-up functionality (see 188+189) | Please see edits below.
| FF | Shop, results | 2 | Chuck | HOLD |
151 | Sal | 5/7/14 | W | Additives validation error showing late. Sal 5/12/14 12:56 - Per John (email): "I will discuss it with Judy about improving the validation programs." | Choose Layflat -> Materials -> Check Metallocene -> Choose Anti Static -> AmineFree Pink Metallocene gets disabled but its still checked and didn't get any validation errors and we should get a validation error here. If we click on UVI/UVA we now get the validation error but it's too late. | Firefox | Shop Widget - Materials & Additives | 1 | John/Judy | Open |
150 | Susan | 5/7/14 | W | product name missing from MOD YMACs Sal 5/12/14 14:52 - Judy will be taking care of this. "these have to be setup in CATALOG.CD.USR". Judy 5/13/14 - Will speak with Owen to see how he wants MOD generic name codes assigned. Stock generic names are not as detailed as the category. For example, if entering a 'Gusseted' bag (category 102), the exact stock match would show BAGS as the description, not GUSSETED BAGS. | "Bags" missing after comma in the 2 ymac results. Is this an Owen/Cliff/Tom issue?
| FF | Shop widget, results | 2 | Open | |
144 | Judy | 4/30/14 | D-Avante | Validation issues in Comments Maintenance (SYS9012)
Janice 5/2/14 9:25am: changes have been made & ready for testing Judy 5/12/14 - 1-5 tested and look good. Added #6 and re-opened. |
| N/A | Avante | 2 | Janice | Re-Open |
136 | Jim | 4.24.14 | W | MADE ON DEMAND Box needs fine tuning. Sal 4/29/2014 18:34 - This banner will show or hide based on whether we got something on the message back from the database. Will work with John to get this message to return the correct text. Sal 5/1/14 11:07 - UI part is done. Wording needs to be changed in database accordingly. Please reassign to a DB programmer. Sal 5/2/14 12:41 - Additional info: "RPC$MODITEM_OPTIONAL" needs to be changed to accommodate requested message. Janice 5/214 14:53 - message changed as requested jbm - 5/15/14 1) The "made on demand" text should be placed to the right of the "box" and centered vetically. 2) The Godzilla message should be BOLDED and the "Show Me" link shuold be the same blue as "save" and "share" links. | 1.) The Box shows up when the Status is "2" which means we cannot make it. Also the Box and Message should show up when the Status is "1". The message format needs to be changed as follows: "We can make CATEGORY on demand. Enter complete dimensions for pricing and availability." or "We can make Gusseted Bags on demand. Enter complete dimensions for pricing and availability." jbm - 5/15/14 | Firefox | Shop Widget | 1 | Chuck | Test |
131 | Judy | 4/22/14 | D | Printing Upcharge calc being called 7 times from WEB.MODITEM.GETPRICE | Why is SOPS9147.5 being called 7 times? It s/b called once for the quote quantity then 3 more times passing each break quantity (custom or standard breaks). The subtotal should include: Non Material$ + Material$ + Price Class Upcharge + Full Gauge Upcharge + Color Upcharge + Venting Upcharge + poly lining upcharge + Rolls,Boxed Upcharge + Folded in Half Upcharge. The first 4 calls look correct except that they are missing the Color Upcharge, which occurs after these 4 are called?? The last 3 calls look strange - no quantity or amount. These are happening after the color upcharge is calculated. Move the color upcharge calculation to before the first SOPS9147.5 call. Calculate it for each of the 3 breaks too. I'm wondering if the last 3 calls are supposed to be for 'custom breaks', which I didn't enter and that's why the qtys/amts are 0. These should only be called when custom qtys are > 0 (they can enter between 1 and 3 custom qtys). | Firefox | Shop Widget/Results | 1 | Wayne | TEST |
121 | Judy | 4/21/14 | D | Creating Orders overrides the named param contents of OPERATOR | I think you are overriding the named param OPERATOR to "WEB". OPERATOR should never be changed and should never be "WEB". The UI side is carrying this around only if ce is logged in on behalf of a customer. Please change the variable in your program so you don't destroy the contents of this named param, and somehow pass the correct operator code to be used on both MOD and Stock Orders along. | Firefox | Checkout | 1 | Wayne | TEST |
117 | Judy | 4/18/14 | D | Some quotes have no operator in QUHDR<82> Joe 4/22/14: Fixed OPERATOR and USR.ID fields on LDLIB RPC$MODITEM_CREATE and BP WEB.CREATE.QUOTE. | QUHDR<82> should contain either the c/e rep's SB User Id (if OPERATOR # "") OR should contain "WEB" (if OPERATOR=''). Not all quotes have this info filled in. I emailed you a snapshot of the code ... I think you are overriding the named param OPERATOR to "WEB". OPERATOR should never be changed and should never be "WEB". The UI side is carrying this around only if ce is logged in on behalf of a customer. Please change the variable in your program so you don't destroy the contents of this named param. | Firefox | Saved Items | 1 | Joe | Test |
102 | Susan | 4/14/14 | W | "Non-standard" product details should show in results and are not.
4/24 - Shop widget has details of the extended description. We need to review with you what is needed. Susan will provide an example. Sal 5/8/14 08:46 - Should be all set, please test after next deployment. SP, 5/13/14 - All "non-standard" details should show, not just full gauge. In this retest, fulll gauge showing, but not color detail . (Also see my 5/13 testing notes on issue 79.) Reopened. Here is spec for reference: Sal 5/14/14 16:31 - Should be all set, please test after next deployment. SP, 5/16/14 - This is a big improvement; however, see issue 30. We're still not showing special packaging choices (slit gusseted/bags folded in half). Also, some small inconsistencies in use of punctuation. Let's discuss next week. Reopening.
| Details like full gauge and color should show in description (along with anything else that's non-standard). This is related to issue 79.
| Firefox | Shop widget | 1 | Sal | Open |
96 | Judy | 4/11/14 | D | Assist Ed with debugging issues related to create order hookup to checkout page | Work with Ed to debug & take care of any needed database fixes related to creating stock and MOD orders from checkout | All | Checkout | 1 | Wayne | Open |
95 | Judy | 4/11/14 | D | Request Hold Flag isn't being set when Orders are Created by CE | When CE is creating an order (OPERATOR isn't null), all stock and MOD orders should be temporarily put on request hold (SOHDR.USR<71>=1 from RECORD<672>) until the requests are written and we know whether the order s/b left on hold or whether it can be released for printing in the whs. RPC$CREATE_STOCKORDER and RPC$CONVERT_QUOTE are missing the logic from SOPP4000.2 when a new order is being saved (ACTION=1 AND PARMS(14)<1>=SOP9116). You don't need to check SOP9116 or ACTION=1. Just check to see if OPERATOR # "". In RPC$CREATE_STOCKORDER, it's missing from the area oflines 417-429 - s/b setting RECORD<672>=1 AND RECORD<674> = SB USER ID so that SOHDR.USR<71> and <73> will be written correctly. | All | Checkout | 1 | Wayne | Test |
94 | John | 4/10/14 | D | Cart quotes need to be accepted before they are converted to orders. | Set the Win/ Loss code to W1, Accept Date to DATE(), DATE.TYPE TO BUDLE.FUTURE.DATE | All | Global | 1 | Wayne | Test |
91 | Susan | 4/3/14 | W | Should be able to undo-anti stat, other pct. Sal 5/8/14 15:57 - Fixed when Chuck was working on bug #43. SP, 5/13/14 - Reopening. I can change material back to standard only if I backspace over my erroneous antistat %. That's an improvement, but don't think that is as intuitive as it should be. Even if my intention is to revert to standard (or some other material where this error is irrelevant), I still either have to backspace, or change the % to something between 1-10 as though I were still interested in antistat. Clicking in standard radio button or even clicking reset still give me this error. If possible, I think the user should be able to click reset or click to another material that renders the error irrelevant. If this is a major programming effort to address, we can learn to live with it for release 1, but we should log it as a future fix. | After getting the validation error for entering antistat % outside of allowed ranges and clicking either X or OK to get out, the only way to get the error to stop reappearing is to enter a % between 1 and 10. That's fine if I am determined to get this antistat, but I cannot select the default "standard" to undo my anti-stat selection. I am barred from doing this, even after clearing the field with the erroneous %. I can only go back to standard material by entering a number in antistat % field between 1 and 10. | firefox | shop widget | 2 |
Chuck | HOLD |
89 | Susan | 4/3/14 | W | Fix to issue 68 caused problem with abbreviated product names Sal 5/2/14 14:41 - Need to apply formatting rules to "Mills" or "Mics" only. | "C&A" is now "C&a"; "LD" is now "Ld" - acronyms/initial cap abbreviations should remain all caps.
| Firefox | Shop widget | 3 | Janice | Open |
87 | Judy | 04/02/14 | D | Wooden Slat comment not working because it's using SHOP.PKG | Please re-work the logic for the Wooden Slat comment in create orders. You are using SHOP.PKG, which is a shop widget variable that isn't available during checkout:
| Firefox | Checkout | 1 | Wayne | Test |
84 | Jay b., via Susan | 3/25/14 | D | Stock price breaks 4/24 - In results area no quantity break pricing is done. It is done in the cart so all items can be considered.
SP, 4/25 I understand your logic (and in hindsight, our specs are not very detailed on this point). However, we think quantity price breaking does need to happen in the results area. Specifically, using the 3/25 example:
If nothing happens, the user will not be "rewarded" for choosing a larger quantity; they may even hesitate to add the item to the cart (to see the hidden reward of lower pricing). Again, we get your logic. Either way, there's some potential confusion about pricing, but we believe this approach is the least confusing, and the most conducive to getting the sale. 5/5 - Meeting with Cathy, John, Judy and Sal. This is not a bug. It was programmed as designed. John will come up with hours to make the change and add to the timeline. It will have to be determined if it will be done in phase one or two.
SP, 5/13 (see also email from 5/7) There is no need to come up with hours etc. "Discounts will be shown in the cart." This extra text should only part of the pop-up when it is accessed from a result, not from the Cart. If this is not possible or requires a lot of effort, we’ll just live with it as it is and consider for phase 2.
| The fake customer we are testing with has stock price breaks... ... but when I change the quantity from 1 to 5 for this item, the total reflects the original unit price x 5, and the unit price on the far right does not change. Tried this with a few stock items, results were consistent. | Firefox | Shop widget | 2 | John | Open |
74 | Judy | 3/19/14 | W/DB | QA/Fix all issues with category stock selections | On the Shop Widget, walk through each of the categories under the top menu: Poly Bags, Reclosable Bags,Tubing& Sleeves, Film &Sheeting, mailers & Access making sure that we are getting stock results for every category. Some of these categories allow dimensions to be entered and some do not (see Wiki Functional Specs/Shop Tab/Shop Widget, Product Selection Groupings for groups 1-5). Make sure that you get some stock items returned in results for every category. If not, check the GETBYFILTER program and the data in ITMMST.USR (loaded from Cliff's spreadsheet) to ensure that we have the proper data for all stock items and that the GETBYFILTER program is handling them correctly. Some problems may be caused by incomplete or erroneous defaulting in the Level 3 area. Note all problems found and fix what you can. | Shop Tab | 2 | Wayne | Test | |
72 | John | 3/17/14 | DB | Customer Numbers as Location Tags Joe 3/20/14: This has been tested and should be complete. | In RPC$ITEMTAG_GETBYFILTER2 we need to change the selections to read from the CUSTMST file instead of ITEMTAGS.USR. There is a select statement that is run on line 115. That can stay the same. However, the statements being run from lines 119 - 125 need to be wrapped in an IF statement and IF STATUS = "L" select customer numbers from CUSTMST instead of TAG IDS from ITMTAGS.USR. | Saved Items | 1 | Joe | Test | |
70 | John | 3/12/14 | DB
| There is code in RPC$MODITEM_CREATE that is causing the setting of the MTO flag to be set to 1 ALL THE TIME. There is a comment that says the issue was related to the repricing. This needs to be brought back in, and fixed so it's not a problem any longer. | Joe 3/28/14: Changed to CALL WEB.GET.STOCK.ITEMS instead of RPC$WEBPRODUCTITEM_GETBYFILTER and based on the results it sets the SHOP.MTO flag. | Cart & Shop Widget. | 1 | Joe | Test | |
62 | Judy | 2/27/14 | W | SHOPPINGCART.USR isn't being updated when CONTINUE from any screen ED: These steps are being updated one by one, Shipping Address is now persisting it's data to the shopping cart. 4/15/14 (Judy) - Data isn't being updated to SHOPPINGCART.USR until a screen later. ie, I click 'save' on the address screen and no shipto customer/address is in the cart record. When I save the bundling screen, I see the shipto customer/address in the cart record, but not the bundling info. When I save the payment info, I see the bundling info and the payment info saved. The label info is written as soon as I save the label screen. Please check why some screens update immediately and some there's a 1 screen lag between save and actual update. | The SHOPPINGCART.USR record isn't being updated with any checkout info with exception of Cart Name/Date Saved/Item Nbrs and Quantities. It's missing all of the updates from the Address Screen forward. This includes billto customer, shipto customer, labeling info, payment info, and bundling info. I do see the code on the back end in RPC$SHOPPINGCART_SAVE to save this info. Is this program being executed from the UI side? | Firefox | Checkout | 1 | Ed | Done |
61 | Judy | 2/26/14 | W | MOD Item Exact Match in Results gets new MOD# when added to cart ECD: Janice completed the back end work, I completed the UI side and tested. This is now resolved. | I entered a 12x24x2mil layflat bag for Butler, which is MOD Item MOD1153. MOD1153 showed correctly in results, but when I clicked 'add to cart', it created new MOD item 1155. If PART.NBR is already assigned with a real MOD Item#, it s/b calling the create order using STATUS 2 (Existing MOD Item/New Quote), not a STATUS 1 (New MOD Item/New Quote). 2/27/14 (judy) - Per John: If PART.NBR="MOD" then set ISSAVED = False. This is only for MOD items. 3/11/14 (judy) - Ed will make sure that PART.NBR is sent back to the database when STATUS=2. Janice will change RPC$MODITEM_CREATE to get the most recent quote# from MOD.ITMMST.USR<7> instead of from CONTACT.ITEM.XRF.USR when QUOTE.NBR = ''. Test plan PMI.CREATE.RP2 does not have a saved item, which is causing the problem with getting the last quote# to determine config.rev#. | Firefox | Shop Widget Results | 1 | Ed | Test |
60 | Judy | 2/26/14 | W | MOD Saved Items with Favorite Flag = 0 showing as Exact Match | In results, an exact match was found with a MOD item (MOD1140) that had a favorite flag (CONTACT.ITEM.XRF.USR<6>) of 0. The MODxxxx item# appeared in results (even though you don't see it in saved items list). When I 'saved' it from results, it assigned a new MOD Item# (MOD1153) to it insead of using the original MOD Item#. How should MOD items not flagged as a favorite be handled? Should it have been assigned as an exact match, and if so, should it have set the active flag on the record when it was 'saved' from results? 2/27/14 (judy) - Research required: Find everywhere that we are updating the CONTACT.ITEM.XREF.USR record (creating/modifying). Note whether we are setting the 'favorite flag' in field 6 or not, and how it determines how to set that flag. John and I will let you know where to go from there. 3/10/14 (judy) - John and I have determined that Favorite Flag is no longer needed. It will be removed from dictionary and RPC$CONTACTITEM-GETBYFILTER, RPC$CONTACTITEM_SAVE, RPC$MODITEM_CREATE, and RPC$ITEMTAG_GETBYFILTER2. -Joe: done 3/10/14. | Firefox | Shop Widget Results | 1 | Joe | Test |
56 | Judy | 2/18/14 | W | Changing quantity in widget results area for a MOD item returns an invalid Available Date
| Do a search for 12x0x24x2mil Layflat Bag from the widget. Returns a date of 2/24. Change the quantity in results. The avail date will change to 12:00:00AM. 02/21/14-I just noticed that new stock selection for Amber Ziptops - all stock items in this search have 12:00:00AM for an avail date. Select 'Reclosables' and 'Amber' then FIND. All 8 stock items are showing this weird date. 04/28/14 (Judy) - I tested and both look fine. 05/13/14 (Janice) - need to verify that the available date in results area matches available date in cart as well as checkout shipping & packaging (bundle) | Firefox | Shop Widget | 2 | Janice | Re-Open
|
54 | Sal | 2/4/14 | W | ProductModItem_GetByFilter / GetById need to return IsSaved value, currently item gets created everytime we open the Save Item popup since IsSaved is always False coming back from the Saved Items tab..
3/13/14 - JJP - Decided to go with changing the MODITEM_CREATE program, to check for the exact MOD item before creating a new item. IF STATUS = 1 and an exact item is found change the STATUS from 1 to 2, set the PART.NBR to the found item, and continue processing. 3/14/14 - Joe: logic added, testplan MIC.EXACT confirms working as expected. | Firefox | Saved Items Tab > click Part Number link > click Save Item link. | 1 | Joe | TEST | |
51 | John | 01/26/14 | W | Return Custom Price Breaks for MOD items 1/27/14 Joe: Quote# was not passed; Ed fixed and confirms now working. SP, 5/15/14 - TESTING ON BEHALF OF JOHN. Customer-entered price breaks are not being preserved. Steps to repeat: Customer contact 17279/cust # 2916. Return saved MOD1301 item to widget. Click price breaks. In pop-up change breaks to 15, 20, 25, click save, get success mgs; open popup again, see the new price breaks on right (good). Click share; share shows old price breaks, not new (in both internal/external views). Go back to results, new price breaks there. Click save, and save button in pop-up, success. Go back to saved items, re-return item to widget. Click price breaks link. New price breaks gone from pop-up. Would test from Cart but cannot at the moment. (Can't add MODs to cart.) | If the customer entered their own quantities for price breaks on MOD items, these price breaks are not being returned from MODPRODUCTITEM.READ. | Firefox | MOD items | 1 | Joe | Open |
48 | Judy | 01/21/14 | W | Printing Direction forcing Vertical when it shouldn't 5/5 - Judy is reviewing. | 12x0x24x2mil bag - choose CP0006 (3x3 image). This should give a choice of Horizontal or Vertical, but it's defaulting to Vertical and disabled so can't be changed. | Firefox | Shop Widget | 2 | Judy | Open |
39 | Judy | 1/3/14 | W | SHOP.LFGUS null for Sheeting/Tubing Sal 3/27/14 15:21 - This value will be obtained and used internally in Avante to avoid littering our objects. Please reassign to a DB programmer. | When I create a quote from results/save for gusseted tubing, SHOP.LFGUS appears to be coming back from UI as blank. I checked CATALOG.CD.USR and it has 'Gusseted' as a default. Please make sure that SHOP.LFGUS is being populated for all sheeting and tubing catalog codes. | Firefox | Widget | 2 | Janice | Open |
35 | Ed | 12/09/13 | C | RPC$SHOPPINGCARTITEM_GETBYFILTER returns incorrect freight option for Stock items. | RPC$SHOPPINGCARTITEM_GETBYFILTER; Items that are of type StockProduct are coming back with their FREIGHT property populated as “Included”, these should be coming back as “Free at $500”. | Firefox | Cart | 1 | Joe | Test |
30 | Judy | 11/25/13 | W | Sheeting Slit/Folded 4/24 - This goes with bug 102. Sal 5/8/14 08:46 - Should be all set, please test after next deployment. Sp, 5/19/14 - issue 102 seems to be addressed, but not this issue; these special packaging details not showing in results. Reopened. Sal 5/23/14 9:58 - John is looking into adding the packaging group to our current business object to address this issue. | When I choose either sheeting slit (gusseted sheeting) or 'Folded Bags' from the packaging menu, neither show as part of the MOD item description when I click on the item in results. Should they?
| Firefox | 3 | Sal | In Progress | |
26 | Judy | 11/25/13 | W | Furn Bags reminder | Furniture Bags – I found this in Wiki and don’t see it on site: Furniture Bags will require a cautionary reminder for users that, while they open along the width (like any bag), those openings will be on the side as you pull the bags from the roll. This should be provided as a popup when the user selects Furniture as a category. Here is the current warning (from today's Laddawn.com) - You should know: For all bags, width is defined as the dimension that runs along the opening of the bag. For furniture bags, unlike standard bags, that opening will be along the side as it is pulled off the roll | Firefox | Shop Widget | 3 | Deane | Open |
16 | Judy | 8/14/2013 | W | Zip Code Validation Sal 5/2/14 10:48 - This seems to be fixed, please test. | It doesn't appear that the zip code validation routine WEB.ZIPCODE.VALIDATE is being executed. Was only validating the format of a zip code, not that the zip code exists in our freight zipcode file. The format validation is now gone and isn't needed. Should use back-end validation only. Format validation doesn't add any value. | IE9 & Firefox (not tested at IE8) | 2 | Judy-Test | Done | |
14 | Judy | 8/14/2013 | W | Sal 5/5/14 12:57 - Please test in IE8 and IE9. | This is only an IE8 and IE9 error. Firefox works. I entered a width and an invalid zip code format, then selected FIND. I received zip code error message and fixed the zip code. When I tried FIND a second time, I received an 'out of range' error message for the Length field. I s/b able to leave this as 'All'. This validation should not have triggered when the field is blank or All. I had to enter a length before I was able to click FIND again. | IE8 & IE9 only | 2 | Sal | Test | |
9 | Judy | 8/14/2013 | W | Can't 'reset' to start over once error box displayed. 'x' out of error box allows you to continue with invalid data. Sal 3/26/14 21:21 - Reset now overrides validation. x out now re-positions focus on calling text box. Please test. Judy 5/9/14 - The 'reset' now works if choose OK on validation error box then click on 'reset'. But if I click on "X" on error box instead of OK, it still leaves bad data and lets me continue. Judy 6/3/14 - re-tested but 'x' on error box still leaves bad data and allows you to continue. |
| IE9 & Firefox (not tested at IE8) | 2 | In Process | ||
6 | Steve | 8/2/2013 | W | Widget - Hovers Design
Sal 3/24/14 - Fixed, please test. Steve 05/19/2014 - initially it works but when you start adding Level 3 options, the shadow gets progressively darker. Chuck 6/2/2014 - test after next deployment | 05/19/2014 screenshot | FF | Shop | 2 | Chuck | Test |
4 | Steve | 7/26/2013 | W | Widget - make disable entry fields stroke (#CCCCCC), they are currently set to (#999999). Please test after next deployment SB (5/19/2014) - The stroke around entry field is still #999999 gray when disabled.
Chuck (06/03/2014) - Sorry, I thought you were referring to the dashed '–' in the textbox. I changed the border to be #CCCCCC as well. Please test after next deployment and let me know if the dashed should go back to #999999. | FF Chrome | Shop | 1 | Chuck | Test |
Attachments:















































































































































































