UMB-CS-682-Team-03 / tracker

0 stars 0 forks source link

searchWith dropdown option (refine) #27

Closed patel-malav closed 4 months ago

patel-malav commented 5 months ago

The current implementation of searchWith is missing the ability to define a field as dropdown

eg.

<roundup-classhelper searchWith="username,phone,roles:<<??>>">
   <a>...</a>
</roundup-classhelper>

Though I can fetch keywords, status, priority but how can I get roles? as they are properties of user

rouilj commented 5 months ago

I'm confused, isn't your classhelper operating on the user class? username and phone are also properties of user.

rouilj commented 5 months ago

This is important for parity with existing classhelper.

rouilj commented 4 months ago

Ah sorry, I was being dense when I wrote my last comment. Yes, roles are a property, but they are not a linked class that you can query. The answer is hinted at by:

https://roundup-tracker.org/docs/rest.html#controlling-access-to-backend-data

by adding a REST endpoint. I am not sure if you can use that method to add:

tracker.../data/user/role

I'll try it. However, you can set up searching on an issue by title (text search) and keyword, status or priority as dropdowns as keyword, status and priority are true classes.

patel-malav commented 4 months ago

The latter suggestion is what is followed up with and is ready to be reviewed.

with syntax being

<roundup-classhelper searchWith="username,phone,roles[]<<sortorder>>">
   <a>...</a>
</roundup-classhelper>

I used [] as an separator to indicate it being a list(dropdown)

searchWith="keyword" (No dropdown) searchWith="keyword[]" (dropdown) instead of searchWith="keyword:dropdown"

at end we can append the sort order too so it would have looked like

searchWith="keyword[]+name" (dropdown) instead of searchWith="keyword:dropdown:+name"

rouilj commented 4 months ago

I can't get '/rest/data/user/role' or '/rest/data/role' to work, but I do have '/rest/role' working.

Create the file interfaces.py in your tracker home directory and add:

from roundup.rest import Routing, RestfulInstance,  _data_decorator

class RestfulInstance:

    @Routing.route("/roles", 'GET')
    @_data_decorator
    def get_roles(self, input):
        """Return all defined roles. The User class property
           roles is a string but simulate it as a MultiLink
           to an actual Roles class.
        """
        return 200, {"collection": [ {"id": rolename, "name": rolename}
                  for rolename in list(self.db.security.role.keys())]}

Restart your tracker and query:

http://localhost:8080/demo/rest/roles

which returns a list of roles like:

{
    "data": {
        "collection": [
            {
                "id": "user",
                "name": "user"
            },
            {
                "id": "admin",
                "name": "admin"
            },
            {
                "id": "anonymous",
                "name": "anonymous"
            }
        ]
    }
}

Note that the id can't be interpreted as an integer because we are faking a real database class. The shape of the data can be made simpler if we want. I chose this shape to match what you see when querying a real class endpoint like /rest/data/status.

rouilj commented 4 months ago

Hi Malav:

roles[]<>

one other thing to consider is that some classes may not have a "name" property that you are using in your fields request. I have written comments on the pull request about using ?@verbose=2 to get the key field included automatically. You can use both @fields and @verbose, they are additive.

I like your syntax here as I think it could help solve the issue. Suppose we allowed:

roles[<>]<>

this might make things easier if identifying the key field from the returned @verbose=2 is difficult.

rouilj commented 4 months ago

Syntax for this is done. It is available on main. Other work on this to be done on separate issues. There is an easy way to determine the new key field that is added.

Mentioned it in standup and commented in review notes on https://github.com/UMB-CS-682-Team-03/tracker/commit/67a3ab4988f2e4b32077aa41a875907613894444

Handling roles is moved to #33.