Move default entity tabs to secondary tabs

I believe we are starting to push the limits of how many primary tabs (technically called primary “local tasks”) are being displayed on some of our entity pages. As such, I propose we move the “default” tabs (View, Edit and Revisions) into secondary tabs under a common primary tab for the entity. Let’s use this thread to discuss? I welcome feedback! :smiley:

Note: I originally stumbled upon this idea when thinking about using contextual links for edit/revision/delete actions: Use contextual links for entity edit, revision and delete links

In that thread @mstenta requested to see the code for this so I’ve also just opened a PR that demonstrates this (this PR is compatible with asset, logs and plans, but taxonomy terms would require a bit of additional work): Move default entity tabs to secondary tabs by paul121 · Pull Request #634 · farmOS/farmOS · GitHub

A few motivations for this:

  1. Additional tabs will continue to be out of context with the default tabs that directly relate to viewing + editing fields about the entity. Additional tabs are often used to display information related to the entity (eg: logs referencing an asset). Moving the default tabs under a common primary tab keeps this “entity context” in one place.
  2. We can improve the context of a given page (eg: “What am I looking at?”) by improving the name of this proposed “common primary tab” to be 1) the entity type label (eg: “Asset”) or 2) the entity bundle (eg: “Animal”).
  3. There is a limited amount of space for primary tabs. Moving the default tabs to secondary tabs creates space for more primary tabs.

Right now we only have a few “additional tabs” that we add to entity pages but I foresee more being added overtime to fulfill more specific use-cases (especially on plans!). Here is a quick overview of current tabs I can recall:


  • View, edit, revisions (default)


  • View, edit, revisions (default)
  • Logs (shows logs referencing an asset, visible on all asset types)
  • Assets (shows assets located within an asset, visible on location assets)
  • Locations (shows children locations, visible on location assets that have children)

Taxonomy terms:

  • View, edit, delete (default)
  • Assets (shows assets that have a field referencing this term, eg: plant + plant type)
  • Logs (shows logs that have field a field referencing this term, eg: seeding log + plant type)


  • View, edit, revisions (default)
  • farmOS core does not have any plan types. However, I believe many plan types will use additional tabs to display specialized UIs and relationships.

This means that right now location assets can have up to 3 tabs (logs, assets and locations), taxonomy terms can have 2 tabs (plant types have both asset and logs tabs).

An important aspect of this decision is that the placement on these default tabs is “universal” across all bundles of the entity. For example, we cannot only move these default tabs for land assets, they must be moved for all asset types. I’m currently reaching this conundrum in the Rothamsted experiment plan I’m working on. It currently has 3 additional tabs and I would like to add a couple more. I could move these default tabs for plans in the Rothamsted module… but as soon as they would like to enable additional plan types, they would be affected as well.

We can also decide which entity types to make this change on. At minimum, I’d like to see this implemented for plans. But I think there is value in implementing this for assets and *taxonomy terms, and even logs as well. I think it’s forward thinking to “create the space” for additional primary tabs before other people/modules/use-cases need them and the UI is not well-suited to add them.

1 Like

Here are a few examples of before/after:

Land asset:

Activity log:
Note: see how this change is really quite minimal! This is because the “Primary tabs” are not displayed until there are at least 2 tabs. Right now farmOS core does not provide any additional tabs on logs, so only the “secondary tab” is displayed (this tricked me!)

Screenshot from 2023-02-03 17-03-00
Screenshot from 2023-02-03 17-00-47

Rothamsted experiment plan:

Screenshot from 2023-02-03 16-57-49
Screenshot from 2023-02-03 16-56-58

1 Like

We should also consider how this affects mobile. I think this is also an improvement on mobile where it seems we may be more limited for space & # of primary tabs when they are expanded:

Land asset - before

** Land asset - after**

1 Like

Personally, I think this looks nicer!

What does it look like collapsed on mobile?

1 Like

I really like this!

I haven’t reviewed the PR to understand how it works, but eager to!

@paul121 Do you think it would be worth having some test coverage of the new logic?

There isn’t a way to “collapse” these tabs on mobile (if I understand your question). They get displayed as a vertical list like that already - which takes up a lot of space… that’s just how the Gin theme displays them.

So this change would not fix the existing screen real-estate issue on mobile, but it is an improvement in the way the tabs get organized IMO, which is nice regardless. I’d love to see the mobile UX of those tabs improved too (separate from this change, to keep them isolated for review). I wonder if there are any thoughts around that in the Gin theme queue already.



Oops my bad - it’s the sub-tabs that can’t be collapsed. So this would affect mobile real-estate in that regard, because it would add sub-tabs where there aren’t any currently. And those can’t be collapsed.

Here is an example where that is currently an issue:

1 Like

That seems concerning. Albeit, it would be a bit of a weird UX to have two expanding/collapsing menus at the top also. Surely, there’s a more compact way for both to fit into the page on mobile…

1 Like

Ideally this would be approached upstream in a Gin issue. I did a quick search but couldn’t find anything related (maybe I missed it though). Might be worth opening one to see if there are any thoughts…

1 Like

Yes! I don’t think we need a full functional test for the UI. But we can test that the task definitions are created and come out with correct IDs and don’t change over time. The primary tab IDs are particularly important because that is what you reference when creating secondary tabs.

1 Like

I’ve added some tests for the task IDs to my PR: Move default entity tabs to secondary tabs by paul121 · Pull Request #634 · farmOS/farmOS · GitHub

I also updated this PR so that it supports all the bundle entities we include a “view” UI for: asset, data stream, log, plan and taxonomy terms