|Anonymous | Login | Signup for a new account||2017-12-11 13:04 PST|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008214||opensim||[REGION] OpenSim Core||public||2017-07-25 09:22||2017-07-27 18:23|
|Product Version||master (dev code)|
|Target Version||Fixed in Version|
|Summary||0008214: BuyLandPass Design decision on MoneyTransferArgs sent to money module - AgentID vs parcel GloebalID|
|Description||Ubit just implemented the BuyLandPass event in core -- LandManagementModule ClientParcelBuyPass. This design decision is vital to make immediately because once money modules begin implementing this transaction type, it can not be changed without breaking them.|
ClientParcelBuyPass uses TriggerMoneyTransfer to have the money module move the funds. In addition to the calling scene, TriggerMoneyTransfer supplies MoneyTransferArgs which include UUIDs for a receiver and sender, ints for cost and transaction type, and a string for description. The initial implementation supplies the UUID of the payee and payer as the sender and receiver, but we should consider instead supplying the parcel's GlobalID as the receiver. While this means the money module needs to be a little more intelligent with how it handles this event, it would supply additional useful information which the money module would otherwise not have access to. This information can be provided to users in the transaction history.
Off the top of my head, if this provided the GlobalID instead of just the AgentID of the owner, we could retrieve the parcel and from it, the OwnerID (and have the payee as currently supplied). We could also pull the parcel name, description, location, and PassHours to supply to the users in their transaction histories.
|Steps To Reproduce||To enter this flow in OpenSim, open up the Access tab of the land info for a parcel. Uncheck the option to give everyone access and check the option to sell a pass. Set the price and time. As another avatar, right click on that parcel and choose Buy Pass from the context menu.|
No money module has yet implemented this, so it may not properly charge. Gloebit is implementing this using this new flow in 0.9 and has already implemented this in 0.8 by capturing the event itself and manually doing what Ubit has now moved to the core. Gloebit can not fully implement this until this design decision is made. After such, Gloebit will supply a version of the money module with this implementation for early adopters to test this functionality.
|Additional Information||I believe that using the GlobalID would be more in line with existing uses of TriggerMoneyTransfer. It is currently used for the flows when an avatar pays another avatar or pays an object. In the case where the user pays an object, the MoneyTransferArgs supply the object's PartID, not the object's OwnerID as the receiver. This allows the money module to retrieve a lot of additional information about the object. It is also necessary, as it is the money module's responsibility to alert the Object that it has been paid, and the money module wouldn't be able to do that without the id of the object.|
|Tags||No tags attached.|
|Git Revision or version number||8739ceb00f34c618634983b25330a21f60eafe6d|
|Run Mode||Standalone (1 Region)|
this was changed since then. TriggerMoneyTransfer is no longer used.
Money modules (and others) should focus only on their functions, they have no business on reading parcels details, that may change on core without notice.
In this case they only need to know who pays, who gets the money, and why.
It is better design to move code into the systems they belong in. In this case, moving adding someone to parcel access lists into the Land Management Module.
However, regarding the other broad statements:
External modules do sometimes have business reading data from other systems. This is why there are public interfaces to those systems. As long as the interface is used, nothing breaks. In this case, the LandManagementModule didn't have an interface for adding someone to the parcel access list or for validating the land pass sales parameters, though if it did, this could have been done in a money module without future risks to breaking. Regardless, occasionally addon modules will have to integrate updates. That happens in any large system and is reasonable when done right.
Further, that "why" of what the money module needs to know can involve quite a bit of data which is not being passed to the money module directly in almost any flow. Users want to have a record of where they made a purchase and what they purchased. Compiling this info often requires accessing core systems through public interfaces. Every type of transaction has different needs.
just my two cents.
Accessing parcel data and digging into OpenSim's internals isn't the province of the money modules.
HARD -1 on using global parcel ID. it's no business of the money module and the call to MoveMoney, which includes a textual description of the transaction can be made to contain human readable info as to what the money was spent on. Using a parcel ID here violates pretty much any written rule of encapsulation and probably most unwritten ones, too.
|I would love it if all the data about a transaction was supplied so that I didn't need to dig into other systems. The platform isn't there yet, so I make due. In the case of LandPass sales, supplying the LandData object (or a copy of it) would be very nice.|
|we already answer that.|
What's the process that the devs follow here for closing tasks? We're no longer using TriggerMoneyTransfer, so this can be resolved. Do core devs generally handle resolving a task or do owners/creators, or do you not care?
Unless we have a reason, by courtesy reporters should close.
|Switched to a new MoveMoney iMoneyModule interface function. No longer using TriggerMoneyTransfer.|
|2017-07-25 09:22||colosi||New Issue|
|2017-07-26 17:05||UbitUmarov||Note Added: 0032174|
|2017-07-26 17:15||colosi||Note Added: 0032175|
|2017-07-26 17:46||melanie||Note Added: 0032176|
|2017-07-27 17:36||colosi||Note Added: 0032192|
|2017-07-27 17:49||UbitUmarov||Note Added: 0032193|
|2017-07-27 18:06||colosi||Note Added: 0032195|
|2017-07-27 18:13||UbitUmarov||Note Added: 0032196|
|2017-07-27 18:23||colosi||Note Added: 0032197|
|2017-07-27 18:23||colosi||Status||new => resolved|
|2017-07-27 18:23||colosi||Resolution||open => won't fix|
|2017-07-27 18:23||colosi||Assigned To||=> colosi|
|Copyright © 2000 - 2012 MantisBT Group|