ibm-watson-iot / blockchain-samples Goto Github PK

How to have access control at the chaincode level. i.e. If I have 4 users participating in teh use case like Supplier, Transporter, Regulator, End user - How to control the access of these 4 users in chaincode. For example Regulator can see everything. Transporter cannot see data meant for Supplier and End user.

How to have such an access control?

(Ref: I have seen car lease demo another example of IBM blockchain, doing acces control at chaincode level.)

How to introduce blockchain level access control in the minimal contract present in this repository.

Our UI has been using this repository for quite some time now. Switching to composer will mena a lot of changes to the UI code.

Is there a way to introduce blockchain level access control, just the way done in another example of IBM blockchain "car lease demo"?

Appreciate an early response. Thanks.

The use case I am working on, has a transaction history on the right hand side of the screen. The transaction history shows the blockchain blocks in the order of their creation timestamp. The blocks will show "create" or "update" transaction on an asset.

we have already updated the code to have an overtemp alert in place. The overtemp alert is setting the compliant flag to TRUE or FALSE based on the temperature read. This part is ok.

What we now need is, when "OVERTEMP" alert is detected, the OVERTEMP string should be displayed in the payload of the transaction which updated the blockchain(I have tried updating chaincode the dirty way in order to accomplish this but nothing has worked so far).

What is the simplest and correct way of doing it ?

Appreciate the help of readers in this regard. Thanks.

I have to add 2 methods. One is a query method and second is a invoke method. I have created the function bodies and declared the functions inside ctasset.go. I also added "AddRoute" calls for the 2 new methods.

Now when I am testing these functions, the calls are not routed to them. Am I missing something?

The readme perhaps does not show how to add new "query" and/or "invoke" methods to extend the contract(Please correct me If I am not). Any link\document will be of great help.

I was hoping in its first paragraph, the author can tell what is contract before going into technical details. Anyone can help?

As for a contract, I would expect there are at least two parties involved, and then rights and responsibilities are defined for each party. Once the contract is signed, both parties should honour the contract, ie. deliver as contracted, once all responsibilities are delivered, the contract is cleared.

Isn't it? But in its explanation, I did not see any of what I am looking for. Why is so? thanks.

When installing the Monitor UI and Simple UI, I get an error on the dependency 'fsevents'. Reading the 'fsevents' docs, it seems it's platform specific for Mac OS X (darwin). I'm using linux. Here's the terminal output:

The "partial state as event" pattern requires that only those properties that are set be sent to the contract. This allows the contract to differentiate between an empty property and one that was never sent. For example, there is a difference between a location with no values in it and no location. In the latter case, the contract can assert that the device is not sending, which may be an alert condition. By sending empty locations, the contract can no longer assert that condition, even though it is true.

There have been multiple reports of confusion with the JSON tag "incompliance" as it sounds like a negative and is missing the camel case that would have gone some way to clarity. But rather than change the case, the actual JSON tag should be "compliant" since that perfectly denotes the meaning.

Collapsing a payload response section that you are polling switches polling off. Opening it up again does not toggle it back on. This is extremely inconvenient to the user as there may be a half dozen queries being polled.

It would be extremely useful if the monitoring UI somehow showed the existing values in place of the textual hints so that the user could use it to choose the next value. This would make the monitoring UI a very powerful testing tool ...

Depends on: hyperledger/fabric#1217

We need to be able to upgrade a contract, which of course would be the default behavior in all new version of a contract upon execution of Init().

Each new version will have to implement whatever data migration will be necessary, but by storing data as JSON objects, and by maintaining original JSON tags, we can alleviate the vast majority of data migration requirements.

As per the blockchain theory that I have understood so far, The blocks are connected via "Hash" keys. i.e. Two fields "stateHash" and "previousBlockHash" are present on each block. As per my understanding previousBlockHash of the present block should be equal to the stateHash of the previous block.

I have deployed this chaincode via IBM bluemix blockchain service. The stateHash and previousBlockHash are not equal for most of the blocks.

Is this a problem? Please clarify.

Schema and Sample generation to be removed from the simple contract. The contract would still have readAssetSchemas and readAssetSamples and the behavior will not change. But the contract code will no longer have payloadschema.json, or the scripts folder and its contents. The contract developer will not have to run a 'go generate' command before 'go build'. Instead, the schemas.go and samples.go files will be provided as-is and the functions readAssetSchemas and readAssetSamples will read them just as they did before.

The monitoring UI does not support debugging mode for chaincode, which is a shame since it would be that much more useful if it did.

The payload response section is useful, but one only wants to see the response from one invoke at a time, since the response shows only the transaction ID and that can easily be seen in the blockchain itself. The queries section is auto updating and thus lives on well after the queries are set up. It makes sense to reserve a section at the top of the column for the latest invoke and to allow the rest to play out below.

Alternately, a second column for invoke history could be optionally created for those who want to be able to click on a historical invoke and see which block it is in (which would require another feature.)

I would like my use case to have the ability to have PDF documents present in the blockchain payload.
How to achieve this?

Appreciate an early response. Many Thanks.

When a user is watching many queries, a real estate management feature should be offered where only one section is opened at a time. There is precedent in applications with long lists of panels such as Adobe Lightroom and it offers the ability to focus on only one thing at a time and to keep that panel centered on the screen as best as possible.

We need to create a custom event "InvokeError" that will be sent to subscribers when we are about to fail the transaction.

Note: Ideally, this will be built into the fabric at some point, but it is not expected in mid 2016.

I have deployed successfully and triggered "Init" and "Invoke" methods successfully with peer. But i can't get through this "Query" method

I have tried many times and many ways but couldn't able to get results for "Query" method, Please help me to find the bug:

/opt/gopath/src/github.com/hyperledger/blockchain-samples/contracts/industry/LogisticsSplit.0.6# peer chaincode query -n blReg -p github.com/hyperledger/blockchain-samples/contracts/industry/LogisticsSplit.0.6/BillofLading -c '{"function":"getBillOfLadingRegistration", "args":["{\"blno\":\"10203040\"}"]}'
Error: Error querying chaincode: rpc error: code = 2 desc = Error:Failed to launch chaincode spec(Could not get deployment transaction for blReg - LedgerError - ResourceNotFound: ledger: resource not found)

Please help me to fix this issue.

Currently, when looking at state objects returned by readAsset, readAssetHistory, readAllAssets, and readRecentStates, the monitoring UI displays all properties in each asset in alphabetical order. This is a very confusing order, since the order changes depending on which properties happen to be present. It makes it very hard to follow the progression in history, for example.

Ideally, the order would always follow schema order, which would make it easy to follow a progression of states.

The rules engine can be used for more than just simple alert processing. For example, rules should be used for validation as well, so that the main boiler plate of the CRUD interface does not need a lot of tweaking.

Remove the obvious conflation of the rules engine and alerts processing. Return err to the invokes and fail on non-nil as with all other failures. A rule engine err must force invoke failure and roll back of all state deltas.

The monitoring UI could be much more useful for demo and debugging purposes were it to show the response payload with a heading of the contract API (e.g. readRecentStates) that generated it. You can switch on polling and it will execute it again every time there is a new block, which is an amazing feature. But if you close the headings, they all look alike, with an asset name of null with no indication of what the command was in the first place.