How to add attribute or tag from lua to a task

Lua
1

I would like to add an attribute or tag to an object like task/paragraph from lua.

My usecase is to add a shorter visual form using emojis instead of [attribute: value].

E.g., To indicate waiting for Joe, I prefer,

  • Get design approval :pause_button: Joe

Instead of,

  • Get design approval [waiting: Joe]

I can now query all waiting tasks and the names.

When to run that piece of lua? while indexing? How to achieve this?

1 Like
2

We had AttributeExtractors in v1, which was dropped in v2. I had a question along similar lines: AtrributeExtractors in V2

For the time being, there seems to be no real equivalent as far as I know

1 Like
3

${query [[from index.tag("task") where done == false and wait and priority<3]]}

sb-task
sb-task995×229 40.1 KB

index.queryLuaObjects and index.indexObjects documented in API/index produces the desired effect.

space-lua 
-- Parses a task string to determine its priority based on emojis
local function parsePriority(taskText)
  local priority = string.match(taskText, "❗") and 1 
      or string.match(taskText, "🔺") and 2
      or string.match(taskText, "🔼") and 3
  -- If none are found, 'priority' will be nil by default
  return priority
end

-- Parse the name beside pause emoji
local function parseWait(taskText)
  local name = string.match(taskText, "⏸️(.*) ") 
  return name
end

-- Get all task objects
local tasks = index.queryLuaObjects("task", {})
-- Walk through each taks and set attribute
for _, task in ipairs(tasks) do
  if not task.done then

    priority = parsePriority(task.name)
    if priority then
      -- Set priority attribute
      task.priority = priority
    end

    waitingFor = parseWait(task.name)
    if waitingFor then
      -- Set wait attribute
      task.wait = waitingFor
    end

    -- index the task with the updated attributes
    index.indexObjects(task.page, {task})
  end
end
1 Like
4

But would this automatically index the additional attributes ? I mean if I add a new task with custom emoji attributes, it would not index it until this lua script runs - am I right ? Is there a hook we can attach to?

5

Turns out Zef’s metatable trick from the previous post does indeed work. Somehow I couldn’t get it to work last time..!!!

local mt = { 
  __index = function(self, attr) 
    if attr == "extraAttrs" then 
      return { extraName = self.name .. "-extra-" } 
    end 
  end 
}
index.defineTag { name = "task", metatable = mt }

and try

${query [[from index.tag "task" select {name=name, extra=_.extraAttrs.extraName}]]}

Does indeed inject the extra attribute into the task object - this might just be what we need…!!!

6

Yes and No. It works when I tried in a space with few tasks and pages. Query fails with Lua error: Maximum call stack size exceeded in a space with ~2k tasks, even if I filter with where or limit clause.

If I do not use the metatable trick all queries work, not sure if the metatable trick exposes a bug or that’s a limitation.

Now I started thinking :thinking: are we using or mis-using? are we thinking or over-thinking? :smiley:

I need custom attributes only for tasks. @deepkn I understood, you needed it for a different purpose.

What if we had a plugin which parses the object and sets attributes/tags based on user configuration? I am suspecting there will be a problem based on the order of plugins that run while indexing - e.g. upon page:index, the 3rd party plugin will add attributes and tags, will it be overwritten by the built-in task plugin?

Summary so far,

  1. Set attribute in space lua using index.indexObjects works but needs to be hooked to page:index to properly work, I guess.
  2. metatable trick works but not in large space with many objects

@zef Need directions.

7

@LogeshG5 Seems to work just fine for me, just tested with around 2.5k tasks - similar to yours, parsing out multiple attributes out of the task text. All of them queried just fine, even without any limits. My suspicion would be this is something specific to your __index function - it is probably introducing a recursive call somewhere, by calling back into __index - from a quick look at the SB code itself, I do not see it ending up making a recursive call. If you still think there is a valid case - this might be worth filing a GitHub issue.

That said, I’m also curious to get @zef 's inputs here - probably also on the efficiency part of the metamethod trick. I’m guessing this is evaluating the function in __index every time the new field is accessed and everywhere it is done? I mean if I have a query like above in multiple pages, it is indeed invoking the __index method for each instantiation of the query and for each task in the query result?

2 Likes