nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Expose other fields to Task interface

limcheekin

Hi,

By looking at H2 database schema of Activiti, the ACT_RU_TASK table has following columns:
CREATE_TIME_
START_DEADLINE_
COMPLETION_DEADLINE_
SKIPPABLE_ (Not sure purpose of this field)

Why not expose these columns to Task interface? If CREATE_TIME_ column is expose, it should solve the problem of sorting I mentioned at http://forums.activiti.org/en/viewtopic.php?f=3&t=323

Please advice.

Regards,
Chee Kin

Find more posts tagged with

Comments

jbarrez

In beta 2, you can retrieve the start time of a task through the historicActivityInstance object.

But I agree it makes sense to expose the create time in the Task interface and in the query API. (the other properties were removed in beta2).
Here's the Jira: http://jira.codehaus.org/browse/ACT-209

limcheekin

Hi Joram,

Thanks for creating the Jira to expose create time column.

I had double checked and saw those columns in beta2. The schema.version = 5.0.beta2 in ACT_GE_PROPERTY table. The way I start the H2 database is:
ant h2.start
ant db.drop
ant db create

Regards,
Chee Kin

jbarrez

Then I will need to double check that. Thanks!

fbarbon

Why have START_DEADLINE_ and COMPLETION_DEADLINE_ properties been removed?

In beta 2, you can retrieve the start time of a task through the historicActivityInstance object.

But I agree it makes sense to expose the create time in the Task interface and in the query API. (the other properties were removed in beta2).
Here's the Jira: http://jira.codehaus.org/browse/ACT-209

jbarrez

Because it was not able to set those properties programmatically. They were remnants of the old implementation we did when we worked on tasks.

What we will add in the near future, is a dudate for the task (== completion deadline).

fbarbon

Thanks Joram.

What kind of semantics will task's duedate property have? I mean, what happens to the process when a task becomes "late"?
Some (standard) process event is triggered? The task state is changed by the system?

Because it was not able to set those properties programmatically. They were remnants of the old implementation we did when we worked on tasks.

What we will add in the near future, is a dudate for the task (== completion deadline).

jbarrez

By default, I believe we shouldnt do nothing with (in the engine).
However, it must be usable in for example a timer event, such that you can model what needs to happen when the duedate is passed.