| Age | Commit message (Collapse) | Author |
|---|
|
greyed out
when you have the ability to manage the ban list
|
|
but the Viewer claims that it is retrieving the member list
|
|
|
|
banning group owners. Viewer gives message that you ejected group owner.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
removed from a group's Owners role
|
|
|
|
|
|
|
|
- Added clear() after DeletePointer() call to hopfully fix this...
|
|
removed from a group's Owners role
|
|
|
|
them from the group
- Banning a resident from the "Banned Agents" tab should not properly eject them from the group.
- Renamed "Banned Agents" to "Banned Residents". Updated tool tip as well.
- You should now receive an eject notification when banning an agent from the "Banned Residents" tab.
|
|
|
|
requisite abilities
- Viewer side implementation for MAINT-3467 complete
|
|
Reviewer: Richard Linden
- Minor fixes from code review
- Continue stubbing out ban_reason, or implement it (depending on how quickly
I can do it, though stubbing out ban_reason will be sufficient, which it is now)
- Fixed an issue where a ban list string in the actions tab wasn't showing up
properly
|
|
|
|
|
|
- Code cleanup
|
|
- Added refresh button to ban list panel
- Added an additional signal to LLNameListCtrl to indicate when the entire name
cache is complete.
|
|
- Changed PUT and DEL to POST which accepts an enum for a create or delete
|
|
- Lots of crap isn't working as intended yet.
|
|
replace llinfos, lldebugs, etc with new LL_INFOS(), LL_DEBUGS(), etc.
|
|
|
|
|
|
dependencies
|
|
|
|
|
|
changes to common libraries from the server codebase:
* Additional error checking in http handlers.
* Uniform log spam for http errors.
* Switch to using constants for http heads and status codes.
* Fixed bugs in incorrectly checking if parsing LLSD xml resulted in an error.
* Reduced spam regarding LLSD parsing errors in the default completedRaw http handler. It should not longer be necessary to short-circuit completedRaw to avoid spam.
* Ported over a few bug fixes from the server code.
* Switch mode http status codes to use S32 instead of U32.
* Ported LLSD::asStringRef from server code; avoids copying strings all over the place.
* Ported server change to LLSD::asBinary; this always returns a reference now instead of copying the entire binary blob.
* Ported server pretty notation format (and pretty binary format) to llsd serialization.
* The new LLCurl::Responder API no longer has two error handlers to choose from. Overriding the following methods have been deprecated:
** error - use httpFailure
** errorWithContent - use httpFailure
** result - use httpSuccess
** completed - use httpCompleted
** completedHeader - no longer necessary; call getResponseHeaders() from a completion method to obtain these headers.
* In order to 'catch' a completed http request, override one of these methods:
** httpSuccess - Called for any 2xx status code.
** httpFailure - Called for any non-2xx status code.
** httpComplete - Called for all status codes. Default implementation is to call either httpSuccess or httpFailure.
* It is recommended to keep these methods protected/private in order to avoid triggering of these methods without using a 'push' method (see below).
* Uniform error handling should followed whenever possible by calling a variant of this during httpFailure:
** llwarns << dumpResponse() << llendl;
* Be sure to include LOG_CLASS(your_class_name) in your class in order for the log entry to give more context.
* In order to 'push' a result into the responder, you should no longer call error, errorWithContent, result, or completed.
* Nor should you directly call httpSuccess/Failure/Completed (unless passing a message up to a parent class).
* Instead, you can set the internal content of a responder and trigger a corresponding method using the following methods:
** successResult - Sets results and calls httpSuccess
** failureResult - Sets results and calls httpFailure
** completedResult - Sets results and calls httpCompleted
* To obtain information about a the response from a reponder method, use the following getters:
** getStatus - HTTP status code
** getReason - Reason string
** getContent - Content (Parsed body LLSD)
** getResponseHeaders - Response Headers (LLSD map)
** getHTTPMethod - HTTP method of the request
** getURL - URL of the request
* It is still possible to override completeRaw if you want to manipulate data directly out of LLPumpIO.
* See indra/llmessage/llcurl.h for more information.
|
|
http error handlers to understand LLSD error responses. Fleshing out most http error handler message spam.
|
|
loading group members
* Fix one race condition that could dereference a dangling pointer.
reviewed with Simon and Baker.
|
|
doesn't support the new GroupMemberData capabaility
- Fixed a potential null pointer crash.
Thanks to Ansariel from Firestorm for these!
Reviewer: Myself
|
|
|
|
|
|
- Reduced the timeout to 5 minutes, down from 10 minutes.
- Provided output for GroupMemberResponder error
- Removed commented calls to sendGroupMembersRequest
- Reordered calls to sendCapGroupMembersRequest so it's called last
|
|
|
|
- Changed level of output logs
- Cleaned up comments
|
|
|
|
|
|
* increased max groups to 20
* changed cache to LRU instead of 'delete half when overfull'
reviewed with Baker
|
|
This change is not guaranteed to fix this issue as the issue
is difficult to repro, but there was a sketchy case
group member responses come back from the simulator in message
packets. For very large numbers of members, there may be a
large number of packets received. The member data is placed
in a structure of type LLGroupMgrGroupData, based on the group
id.
The problem is, if the user refreshes the group before the entire
contents of the previous request comes back, response packets from
the previous request will be intermingled with the responses from
the refresh.
Both the request call and the response handler would create the
group data structure, if the structure wasn't already there. There
may be a case where a response from the previous request causes
creation of the group data, populating it with the contents of the
response, and the responses from the second request would use that
group data structure.
Also, cleaned up some comments and variable names to be consistent
|
|
|
|
|
|
|
