|
|
|
I marked this as "Misfiled" due to the nature of many issues present here. As you see from the general stance this issue has acquired votes. I suggest to create new jira issues with very specific feature request – one jira entry for each item you listed above. You can then link these together as related. This will help the business of getting these features implemented to be more optimal.
I have to disagree Dzonatas. The numbered items are (non-exhaustive) alternatives. I think we'll leave it to Linden Labs employees to mark this as resolved when something is in place.
You're welcome to create your own new feature requests, but please don't go closing other's without asking. On a related note, the login system has since been restored, though we're still in need of a better mechanism - hence I don't think that qualifies as a resolution for this request either. I agree with you Cenji, while many potential solutions are presented, it's still one fundamental problem, that transactions have no verification. This is a huge issue.
that's indeed a good idea. I am in favour of the following two fucntions:
a) a way to get a transaction confirmation. for instance, something similar to llHTTPRequest. It could for instance be something like: money_request_id = llGiveMoney(...); money_response(key request_id, integer status) } b) a way to get transaction log from LSL. This would definitely resquire proper privacy/permission thinking. I don't want to be given such an object which would send all my transactions to anyone else without my consent ! Kind regards Kristy I agree with Kristy's proposal that an id key should be returned by llGiveMoney() that is generated immediately by the sim at call regardless of if the payment ultimately succeeds or not. Since llGiveMoney currently returns void a new function isn't even needed.
Even if the event wasn't initially implemented, carrying that id key through to the XML SL logs would be enormously helpful for us in matching up transactions, which currently is a complex and computationally expensive process involving a dedicated server. If the giver has insufficient funds for a money() event, a window pops up that shows how much they need and offers to let them purchase L$. It voids the payment if they decline.
Why can't this be done on llGiveMoney()? Perhaps the Permission request needs to include the L$amount information if lack of this is causing the problem. I don't really care how it is done but neglecting this essential security is a travesty. AnnMarie, note that llGiveMoney() can be executed by a script when the object owner isn't logged in - so there would be nowhere to pop-up a window in that case. Such pop-ups should be throttled too, since llGiveMoney() can be executed quickly. We have multiple objects that execute it several times a minute, for example.
A good suggestion, though a different feature - it wouldn't solve our notification problem. You might consider opening a new feature request so it doesn't get lost buried in these comments As for notification, perhaps LL could adopt the Automated Notification System (ANS) that is now in use by Apez, SLX and hippoTech While we'd prefer a direct HTTP notification, a money_response() event would still be desirable for consistency with the existing LSL scheme. I disagree that this was misfiled because the root of the problem is only one issue: llGiveMoney() does not verify success or failure. This issue was logged on the JIRA over a year ago and LL has done nothing to correct this situation. First of all, it is ridiculous to use a function with a return value for an operation that performs like a subroutine. Second of all, without the ability to confirm the status of an llGiveMoney request you are severely limiting the ability for users to create advanced services for SL. Right now there are only two ways for an object to handle money transactions, either paying the object directly (which only pays the owner of the object) or requesting permissions to use llGiveMoney.
I have read in a few places that Lindens have stated it is impossible for llGiveMoney to return a value because the data is not in the right place at the right time. I also must disagree with this statement for one reason: when llGiveMoney fails it shows a blue dialog on the avatars screen stating 'insufficient funds'. That means the data IS in the right place at the right time for llGiveMoney to return a 1 or a 0 based on the success of the function. Verifying the state of a transaction is a very important part of any system dealing with money. It is even more important for catalog or content creation HUDs who's only method of paying the correct person is llGiveMoney. Leaving llGiveMoney() as it is not only limits our ability to create advanced products but destroys our ability to mitigate fraud and prevent abuse of our products. It is shameful to see the basic necessities for proper transaction processing left out of the production cycle for over a year while LL allocates so much time to other things that don't affect the bottom line. Dazzle, Windlight, Voice, SpaceNavigator and all the other neat things you have added during the past year are monumental tasks in comparison to fixing the llGiveMoney function (subroutine?). If the data is not in the right place at the right time MAKE it be in the right place at the right time. It is not possible for residents to fix this issue, it must be fixed by LL because we do not have access to the server source code. Why am I so adamant about getting this fixed? Well I worked for more than 7 months on a content creation HUD and saved the add credit and purchase buttons for last, only to find that when the system was finally finished a user with 0 L$ could add an infinite amount of credit to the HUD simply because llGiveMoney does not tell my scripts the payment has failed. I must ask LL to take a serious look at llGiveMoney and find a solution to this issue. Nulflix - generally agreed. Just a couple comments:
SVC-2224 proposes one solution to a generalization of this problem (transactions for llGive*() )
Due to the new dashboard SL site, logins are now broken - which given that LL told us to use the web interface as the means to obtain transactions logs, implies that it is an API compatibility breakage.
Obviously, we'll have to re-write code to work around this for the new site, but meanwhile our business is suffering and our customers complaining thanks to LL's failure to maintain API stability, again. Update: While I still had to interrupt my vacation to write code to keep my customers happy, the differences were minimal. The page URLs changed slightly, there is an additional "CSRFToken" form field that needs to be POSTed, but otherwise the forms fields didn't change. How can we get this issue assigned? Not only that, there was no warning or even a test version we could use.
If the website is to form part of the transaction processing for in-world it bloody well better be tested in the same way as the beta grid with warnings and time. --->> Brody upset A simple suggestion here.
Let us read the transaction page from in-world with the login automatic for the owner of the object that is making the call to the page. Send the results back in some kind of comma delimited format with as much data as you can pack into the 2k result. I have a PHP script that already does this by acting as a translator between the LSL and the http webpage. Like everyone else I have to have it altered every time LL change the website. If we had a dedicated interface then we would have a standard interface that will be maintained by the web developers. Right now the web developers make changes with no regard to in-world transaction validation because no one told them that they need to. It would be simple enough to do and then you can play around with your silly http logins and mess with the webpage format as long as you like without disrupting hundreds of thousands of business in world. Linden Labs should remember if we cant make a sale, they cant collect their fees either! Although I feel that SVC-595 is a higher priority, this would at least allow users to catch fraud in a scripted and automatic way, rather than having to manually download transactions and pore through them. Implementation of this would be a superb help to second life businesses.
MISC-3088 is probably more important at the moment. We need to prevent people from being able to use exploits to open the vending machine scripts and just delete the llGiveMoney function from them!
Darling, they aren't mutually exclusive, MISC-3088 is important but giving attention to this wouldn't necessarily slow down or detract from from fixing that.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Reopened
Critical
Automated access to SL transaction logs or notification of transactions
It is imperative to many Second Life businesses that an interface to access the transaction log programmatically be provided before the captcha login requirement is implemented. Developers were instructed by Linden Lab to access it programmatically, and as expected many of us built services which rely on it completely.