Zanara Zenovka

Can't see need to rename inworld objects/folders - SL won't let you use any of the problem characters in inworld object names anyway, so if you can use it in the object name it would be fine to use anywhere. It's additional characters used in your product listing titles on the webpage that you have to worry about, because DD (retardedly) tries to rename the folder delivered with the title used on the webpage, and because a restricted character set is used inworld, the transaction falls over.

It was implemented, briefly, for about a day, then removed because it buggered something else up. No word since.

I've been getting those regularly for about a year - 2 (copy, no trans) items being bought at once in the same cart. For a while there, they'd slowed down, but i've noticed more this last week (still using magic boxes). UPDATE: I've just noticed one from today, that's 2 transactions 12 minutes apart - that's different. Commission is still 5% tho. You can refund the 2nd for total price, then put in a ticket for refund of the 2nd commission - just send the transaction info in ticket

From http://community.secondlife.com/t5/Merchants/Marketplace-and-Direct-Delivery-Update/td-p/1462915 _________________ [uPDATE: April 5, 2012] We’ve identified two issues contributing to WEB-4587. The first issue concerns mismatched data appearing on Marketplace listings. This impacts a very limited number of Merchants and has been occurring since the original migration from Xstreet to the Second Life Marketplace in September 2010. We continue to actively work on a resolution. The second issue concerns incorrect listings appearing in search results. We have identified the issue and are actively working on a fix. _________________ So, yet another ballsup from the original migration (which, incidentally, for those who don't remember, was much worse than this).

Everyone with a one word name has always had the last name "Resident", whether displayed or not.

Czari Zenovka wrote: I keep an alphabatized list of customers in wordpad with the purchase date, item/s purchased, and whether it was from the MP or in-world. Even with a very small shop, this list is now quite lengthy and becoming a bit unwieldy. Using this "paper & pencil" method works...but I am sure there is a more efficient way of doing this, hopefully one that does not necessitate learning spreadsheet software. Oh gosh - seriously Czari - use Excel or open office spreadsheet or whatever. Even if you do nothing more than download your monthly transactions and open them in excel to view you will save yourself so much work. Then it's only one more step to copy each month's sales + your SLM sales to a single file (use a separate tab for each cos the fields are different) and you have all your records in the one place and can do what you want with them.

Rya Nitely wrote: Only problem with Contents Tab is that if you have an item set as COPY MOD and you have a script or animation that is no mod (to the seller) then the item in the contents list will appear as COPY only, and customers might think the item is no mod. It would be great if we had the ability to override this. We did before, when you could just specify perms in your own words. Displaying perms of non-rezzed objects that have contents is pointless, and just one of the things about this design that has much greater cost than benefit.

Pamela Galli wrote: This was a known issue before DD, only exacerbated by DD migration or somethng, as I understand it. Was it? I'd never heard of it until after the last MP update around Thursday, when a lot of people started suddenly reporting it. Is there an existing jira/forum post about it?

Random Sixpence wrote: The only thing that seems to happen, or happened, as it is not happened in a couple of days, is a customer bought an item, got it delivered and then got the exact same item delivered again and was charged again in the same minute. I had that happening quite a bit in the past year with magic box sales - i think it happens at the shopping cart level when things somehow get added twice and people don't notice. It's decreased since they put in that number warning.

RE: and have you *fixed* the unicode issue? CTL, please just use the original folder name. I can see that it might have seemed like a neat idea to deliver the exact name of the item listing, but the problems are too great for minimal gain. Think of it this way: - Listing name = display name - easily changed, does not necessarily give exact detail about the items delivered, sometimes just used as a dumping ground for search terms - Upload folder name = user name - Name of the actual boxed item/folder that is delivered. May contain version numbers and other specific info that is important for inventory organisation and subsequent customer support If you force remove the unicode from listing names you mangle people's listing titles, deliver folders with names that possibly don't make sense and damage important search terms. And how would you be communicating this change to non-English language users, esp frequent users of Unicode? -

Josh Susanto wrote: ...aaand another problem solved. Please note that the inability to load pictures prevents them from showing up on the wrong listings. lol OP: which graphics format are you trying to upload?

haha *groan* Maybe we should tell Josh that Malefactor (?sp) Linden needs to be renamed to Hal This explains everything - even Josh's... *cough* creative... theories! The database itself really does hate us.

hoohaa Anaconda wrote: Ok I have a little update on some thing else I’ve found It appears to me that you can actually have the picture the product name and the creator all different. Yes that’s correct 3 different fields of data from 3 different creators. It’s also clear to me that some creator names that appear are not merchants and never have been. Wow - that's transcended into art... What was the date Skynet achieved sentience?

Used when you want to report an inappropriate review for removal - most commonly used when bad review is given for non-delivery.

Deja Letov wrote:Honestly, I find this odd because even people who use a ton of vendors in their place of business, they still have actual products set out for sale so are people just not tracking these sales? Just to address one assumption here, there's nothing to stop you putting a script (+boxed copy) in an item rezzed for sale to turn it into a vendor to do whatever you want. And if you wanted to use a vendor system like BSM that has a rewards program, you could find ways to use that with rezzed objects. Depending how it's scripted, you could (a) just drag the vendor scripts into your rezzed item, or, if the vendor script does something you don't want, like automatically apply a texture, and you can't find a way to hide that on an insignificant prim, you could (b) rez the vendor, make it invisible and link it (as root) to your rezzed item, to turn the whole thing into a vendor without affecting its outward appearance.

bump

Isis: see http://community.secondlife.com/t5/Merchants/ATTENTION-Listings-on-the-Marketplace-are-borked-Everyone-check/td-p/1457545

TatianaDokuchic Varriale wrote: Dartagan Shepherd wrote: The assumption would be that anything search can be rebuilt as well, which wouldn't need manual merchant care. And it wouldn't need merchant attention unless there's no longer a way to reassociate those wrong records back to their rightful place. Probably best not to call a corruption problem a search problem. Best thing I can think of is selective rollbacks only for the merchants that request them. Otherwise just think of all the changes that have been made since this first happened that will have to be redone. Doing that manually would be painful. Automating it and I don't trust that it will be done correctly. When talking about rollbacks initially, it should just mean rolling back the database operations code, not your actual records, same as when they do an code update (eg same as if you upgrade your version of, say, MS Word, it doesn't change the contents of any Word documents that already exist). That's assuming that the problem is something in their code that is associating Merchant X's picture with Merchant Y's listing, etc. That would be the 'good news'. The bad news would be if it's not just a problem of what is being displayed, but that data has somehow been overwritten (ie Merchant X's picture has been replaced with Merchant Y's), which is what Dart means by "unless there's no longer a way to reassociate those wrong records back to their rightful place". That's less likely (which I hope is the case) but would take us into seriously fubared territory and is something I don't even want to think about.

CommerceTeam Linden wrote: Merchants, We are aware of the issues reported in WEB-4587, where an incorrect image is associated with a Marketplace listing or other listing information is inaccurate. We are working on this issue and will provide an update as soon as possible. In the meantime, merchants experiencing this may do the following: Delete any image(s) that do not belong to the listing. Upload any image(s) you’d like to associate with the listing. Remove any Related Items that should not be associated with the listing. Stay tuned and thanks for your patience. The Commerce Team Clearly the problem is not even understood at your end at present, as this doesn't even cover all the phenomena being experienced. Please just roll back to a working version and then work out what's wrong in your own time. Mixing up the integrity of actual product listings is not tolerable at all.

Josh Susanto wrote: >The point is that these deadlines depend on "success metrics and merchant confidence levels" That was never the point. The point was that the box system, itself, leaves someone personally exposed to some kind of risk that might be more effectively mitigated by shutting down the box system sooner rather than later. Was talking about my original point in posting, not whatever creative notion you've come up with.

Thanks Sassy and Sera and everyone who created jiras and contributed. I'd been thinking of trying to do this myself and balked at the effort involved, so well done. What I'd really like to see is a post from CTL addressing all these and giving us updates on each. If they actually did this it would reduce their ticket load substantially, since people would have some idea how things were going to be resolved.

The point is that these deadlines depend on "success metrics and merchant confidence levels"

Oh good grief - if "click on one product buys another different product" isn't a showstopper for an online marketplace, I don't know what is... some days there aren't enough faces and palms to go around...

BTW, 10 months ago, Brooke posted this, which should still apply Brooke Linden wrote: Will Magic Boxes always be available? Eventually Magic Boxes will be retired, but no firm date has been set. We have identified success metrics and merchant confidence levels that will need to be met before we set dates for this step. Brooke

^