Error: Macro BackLinksMenu(None) failed

compressed data is corrupt

Error: Macro TicketQuery(summary=APP_CONNECTIVITY_REDESIGN_R0, format=table, col=summary|owner|status|type|component|priority|effort|importance, rows=description|analysis_owners|analysis_reviewers|analysis_score|design_owners|design_reviewers|design_score|implementation_owners|implementation_reviewers|implementation_score|test_owners|test_reviewers|test_score|) failed

current transaction is aborted, commands ignored until end of transaction block

Analysis

Overview

This task is about redesigning the current connectivity model according to the new resource model and improving it so it reaches a stable beta phase.

Since there are too many tasks about server and connectivity,they first need to be categorized, analyzed and scheduled. A clear vision for further procedure is needed - this task is about doing so.

Task requirements

Analyze the current status and what needs to be done for the following:

• The whole connectivity design must be revised (in this task) - what does is consist of, how does the client use the connectivity module, etc.
• Facade - since the resources are being redesigned, the facade needs to be changed. Real time collaboration support should be provided (sync methods).
• Connection list - the connection list in the client needs to be persisted, should provide manipulation ability, connections need to have clear statuses defined.
• Server resource listing - the client needs to have a clear way of getting server resource lists (keeping in mind the security permissions). Also, needs to have filtering, searching, open/close support. This issue affects the server, too.
• Client U.I. - there is currently a tab for the server stuff in the left flap, it must be re-designed and synchronized with our analysis men.
• Security - there is already some user/group model, but no logic is using it. Analyze / design the base security model.

Task result

• In the design - design documentation for every connectivity aspect discussed above. Design diagrams are needed, auto tests are obligatory.
• In the implementation - Achievable schedule of what will be accomplished in what time, considering connectivity. The common design must be implemented as a basis for the next tasks. The tasks which will be implemented should be grouped and (optionally) analyzed.

Implementation idea

• The base.connectivity module currently does not maintain the list of the available connections - they are kept in the corresponding palette. Consider this behavior.
• There is a design draft for the new resource facade after the resource redesign - ​http://pastebin.asteasolutions.net/f444cc8f1. Another idea is that the client implementation of the facade is used by the server resource accesses, and the server-side implementation uses the server resource accesses.
• Connection listing should mainly use the server resource access, so it must be synchronized with other teams' work.

Related

GROUP_RESOURCE_MODEL_REDESIGN_R0

How to demo

Explain the complete model to the teams. Show the working prototypical code.

Design

• The facade will be changed with the one from the draft (see implementation idea) and it will need sync methods (probably syntToMaster and syncFromSlave). The majority of its methods will return objects of type Response - they contain a result object, response status and eventually status message. This way, if the server cannot serve the client request, it can give some information about the type of the problem.
• ServerConnection should not be part of the model, but the model should know about pairs (server, user). So, we introduce a new class - Account. It consists of String serverUrl, String userName, String password, String accountName, Boolean autoConnect and Boolean savePassword - the most probable candidates for persisting before client shutdown. Accounts must not know about connections, but every connection should know the account is has come from. So, the new ServerConnection class has ConnectionStatus status, String sessionId, Account account and a private instance of a facade. Furthermore, the ServerConnection has all the methods that the facade interface has, but with one difference: The facade methods return object of type Response<T> and need sessionId, the connection methods return object of type T and do not need sessionId(since the connection has its own id). This way, the connection can read the contents of a response and eventually react to their status(throw error messages, etc).
• There will be an AccountManager which maintains list of available server accounts. For every acocunt, it will create a corresponding server connection. The connection will not be active before calling its "connect" method. Note that connect is not the same as login - connect just finds an appropriate facade implementation, instantiates it and gets a sessionId from the server. The login then can authorize the user, but some functionalities do not require the user to be authorized. Communicating with the server without logging in will be treated as annonymous connection.

• ServerConnection:
  • Represents a connection to a server, instantiated from a given Account.
  • Every connection has 1:1 relation with a client-side facade.
  • Has the methods that the facade has, which delegate to the facade's ones.
  • The main difference between a connection and a facade is that the facade needs Session ID for its methods.
  • The facade's methods always return objects of type Response, the connection's ones handle the responses and 'unwrap' them.
  • The facade is not visible to others, only to the connection.
  • The methods in the ServerConnection that the facade doesn't have are login(String username, String password), logout(), connect() and disconnect(). The third one is responsible for getting a session ID from the server and instantiating the private facade, the last one is responsible for destroying the facade in the connection and setting sessionId to null.

Implementation

^{(Describe and link the implementation results here (from the wiki or the repository).)}

Testing

^{(Place the testing results here.)}

Comments

^{(Write comments for this or later revisions here.)}