Details

    • Testing Instructions:
      Hide

      Run the unit tests.
      OR :

      Create 2 users : u1 and u2.

      For Message-Sent area :
      Login as u1 . Send message to u2 and read it as u2

      Execute the indexing cycle. After the indexing cycle,
      Search for the message content using the globalsearch box on the header.

      Expection : u1 should get access to the message. ( The sent message must be displayed in the result)

      Login as u2, admin or guest.
      Search for the same message.
      Expectation : The message must not be displayed in the search results.

      delete u2 and search again.
      Expectation : The message must not be displayed in the search results for u1 ( sender ).

      For Message-Recieved area :
      Login as u1 . Send message to u2 and

      Login as u2 now.

      Execute the indexing cycle.

      After the indexing cycle ,
      Search for the message content using the globalsearch box on the header.

      Expection : u2 should get access to the message. ( The sent message must be displayed in the result)

      Login as u1, admin or guest.
      Search for the same message.
      Expectation : The message must not be displayed in the search results.

      delete u1 and search again.
      Expectation : The message must not be displayed in the search results for u2 ( reciever ).

      Show
      Run the unit tests. OR : Create 2 users : u1 and u2. For Message-Sent area : Login as u1 . Send message to u2 and read it as u2 Execute the indexing cycle. After the indexing cycle, Search for the message content using the globalsearch box on the header. Expection : u1 should get access to the message. ( The sent message must be displayed in the result) Login as u2, admin or guest. Search for the same message. Expectation : The message must not be displayed in the search results. delete u2 and search again. Expectation : The message must not be displayed in the search results for u1 ( sender ). For Message-Recieved area : Login as u1 . Send message to u2 and Login as u2 now. Execute the indexing cycle. After the indexing cycle , Search for the message content using the globalsearch box on the header. Expection : u2 should get access to the message. ( The sent message must be displayed in the result) Login as u1, admin or guest. Search for the same message. Expectation : The message must not be displayed in the search results. delete u1 and search again. Expectation : The message must not be displayed in the search results for u2 ( reciever ).
    • Affected Branches:
      MOODLE_32_STABLE
    • Fixed Branches:
      MOODLE_32_STABLE
    • Pull from Repository:
    • Pull Master Branch:
      MDL-54973_master

      Description

      This issue is about adding messages to global search. This is part of Devang Gaur GSOC 2016 project proposal.

      This seems quite straight forward but it is not, I propose to add two search areas, one for sent messages and another one for received messages. I need to explain it a bit, keep messaging case in mind:

      1. Each document have an id, unique across all moodle's contents and an itemid that is unique only inside the search area. The global one is created from the document itemid + the search area.
      2. Each document have a context field and a owneruserid field, documents with a owneruserid field can only be accesed by the owner, so the difference between setting a document in context user and setting the userid in the owneruserid field is that if owneruserid is set not even admins can access that document, only the owner. Admins though can access all documents contexts, including other user's contexts.
      3. The current api does not allow us to set an array of values for a given field, this was designed this way because we want to support all kind of search engines people can think of, would be pretty easy for some of them like solr, but for some of them would be hard, imagine the moodle database search engine, would need to re-parse the document objects that is receiving from the search api to split them in two, would also require multiple context ids as search areas like messaging works at context user, mapping between them... This search area would be suitable for messaging as it would be the only way we have to avoid redundant messaging contents in the search engine
      4. Each searchable document should have a unique URL. I mean that we should not have a mycourses search area document pointing to course/view.php?id=X and a potentialcourses document pointing to course/view.php?id=X, the later one should point to the enrol page, this would not be a problem for messaging because the URL changes between users.

      To skip this search API limitation I suggest to have two different search areas because:

      1. The amount of redundant data would not be huge (no files support)
      2. I don't even know now what kind of dirty engineering tricks we would need to do to adapt the search api to support an array of users with access to a document
      3. Having two different search areas will only be noticeable by the user when filtering by search area, thanks to the nice autocomplete thing this will not be a problem, as we can easily see the potential choices and we can select multiple search areas

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Fix Release Date:
                  5/Dec/16