viewing the link storm/timetrackings/ it doesn't use the label defined in admin/content/types/stormtimetracking.

Also viewing a timetracking node, it doesn't use the correct Description label either.

I haven't checked all the other content types yet but I assume it will be the same for the others too.

Members fund testing for the Drupal project. Drupal Association Learn more


Francewhoa’s picture

Status: Active » Closed (works as designed)

tchurch, I'm assuming that by "label" you mean "Name". Changing the "Name" of a Content Type at /admin/content/node-type/stormtimetracking will not change the "label" at /storm/timetrackings/ this is by design.

One way that might work to change the label is with the module

Francewhoa’s picture

65.48 KB
88.06 KB

tests screenshots

tchurch’s picture

Status: Closed (works as designed) » Active
72.63 KB
50.76 KB

How can you use String Overrides module? It will replace EVERY instance of the word "Title" with whatever you replace it on ALL pages.

This is not good enough.

See /storm/tasks, /storm/projects etc...

It is also not the identification details but the Submission form settings.

Even if you view a timetracking node, it doesn't show the correct Title and body/description names.

See attached.

This isn't just a problem on timetracking but all node types.

Francewhoa’s picture

Status: Active » Closed (fixed)
38.9 KB
48.11 KB
62.78 KB
74.81 KB

tchurch, thanks for clarifying :) I re-tested and this bug has been fix a while ago. Confirming it was fix in:
Drupal 6.27 and Storm 6.x-1.37
Drupal 6.28 and Storm 6.x-2.1

tchurch’s picture

Version: 6.x-1.31 » 6.x-1.37
Status: Closed (fixed) » Active

I hate to say it, but it's not fixed in 1.37 or 2.1.

When editing a node, it shows the correct title and body names but not when you view the node.

I've had a quick look through the 2.1 code and found where it's hardcoded to 't('Description')' and 't('Title')'.
E.g., for time tracking, in files (function stormtimetracking_list) and (function theme_stormtimetracking_view).

I would help to fix it and offer a patch but I'm in the process of moving and my PC is packed.

Please note that this issue will be with all other node types too, not just timetracking.

juliangb’s picture

Thanks both for bringing this issue back to the surface.

It would definitely be good to sort this out.

@tchurch: Two questions...

1) Are you still on 6.x-1.37, and if so, is there anything stopping you from moving to 6.x-2.1? It would be ideal if as many people as possible upgraded to 2.x, which will be a step before moving to Drupal 7 anyway. (That said, we will support fixing bugs in 1.37 for now)

2) What names are you wanting to use? If there is a better name, we should consider whether there is a better default.

Hope your move goes well!

tchurch’s picture

Some answers:

1) I tested this in 1.37 and 2.1 and get the same result (I have 2 testing sites for them although I might decommission the 1.37 site).
Incidently the same issue also exists for other Storm nodes and other columns too. I would be better to remove as many hardcoded t() statements as possible and use the data from the database.
It might be better to treat this as a "feature" change to make it better (see 2).

2) If this was changed to a new feature, it could be added to 2.x only.
I suggest that all t() columns refer to database information.
i.e. instead of using t('Title'), it should get the defined title name for that content type from the database (i.e. from the node_type table, columns title_label and body_label).
This should also be extended so that if the title field of an organisation is used on a view or list, that would also come from the database.
That would give Storm (or PM for Drupal 7) the flexibility to use the existing data names.
This idea could also be extended into the dashboard itself, using the name of the content type from instead of hardcoded.

This would have been useful for an old customer I had but instead we had to write a new "dashboard" as the names of some items needed to be changed.

If this feature/idea is considered a good one, we should also raise an issue against the PM project for Drupal 7.

Sorry for the long reply.

Francewhoa’s picture

tchurch, hope your moving goes well. Confirming this issue with both 6.x-1.37 and 6.x-2.x-dev on view node.

juliangb’s picture

Status: Active » Closed (won't fix)

In Project Management for Drupal 7, we use Views for all lists such as this, meaning that the lists are customisable via the user interface.

Therefore, I'm marking this won't fix so that we can focus on the migration to Project Management.