Skip to content

Commit

Permalink
Save also code of event
Browse files Browse the repository at this point in the history
  • Loading branch information
@FHenry
FHenry committed Sep 2, 2014
1 parent 0dd9558 commit 832d1b3
Show file tree
Hide file tree
Showing 2 changed files with 2 additions and 0 deletions.
1 change: 1 addition & 0 deletions ChangeLog
View file
Expand Up @@ -12,6 +12,7 @@ For users:
- Fix: Unsubscribe emailing not working
- Fix: Trigger on create category call failed because user is not passed on card
- Fix: list event view lost type event filter
- Fix: Save also code event

***** ChangeLog for 3.6 compared to 3.5.* *****
For users:
Expand Down
1 change: 1 addition & 0 deletions htdocs/comm/action/class/actioncomm.class.php
View file
Expand Up @@ -140,6 +140,7 @@ function add($user,$notrigger=0)
if ($result > 0)
{
$this->type_id=$cactioncomm->id;
$this->code=$cactioncomm->code;
}
else if ($result == 0)
{
Expand Down

6 comments on commit 832d1b3

@fmarcet
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the reason for this change? When an action is created manually, "type_id" and "code" are already filled. So the only way that code is run is when an automatic event is created through a trigger. In that case the field "code" contains the action of event launched (AC_PROPAL_VALIDATE, AC_PROPAL_SENTBYMAIL...). With the change, we lose that information, since the field "code" will always contain AC_OTH_AUTO

@FHenry
Copy link
Member Author

@FHenry FHenry commented on 832d1b3 Oct 13, 2014

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I understand, there is two fields to save the same information into llx_actioncomm. -llx_actioncomm.fk_action=>llx_c_actioncomm.id
-llx_actioncomm.code=>llx_c_actioncomm.code
It seems logical to save the same relevent information in both column, if not what appens on agenda with filter on event type (when you activate the event type option) ?
Even if the event is created by trigger, it seems logical that it appears is the same way as manually, it depends on dictionnay table, not method of creation. If event is created by trigger, you should add an entry into dictionnary to says it. For exemple on dictionnay entry with "Event Entry", and another with "Event entry auto" and code it into your module.
The problem is more : "why have two column to save the same foreign key information ?"
@eldy want to remove, a year ago, from dolibarr the event calendar type feature, but now ? I think that the problem is more complex. Task and Event is not the same things, mix models=>mix result.

@fmarcet
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think 'fk_action' is a foreign key to the table llx_c_actioncomm but no 'code'. Since in the database there is no foreign key defined, we can not be sure. No point having two columns to store the same information, so I think that 'code' is not a foreign key and can store other extra information.

The 'code' column was created in Dolibarr 3.4 and stores the extra information. And it makes no sense to create a column to store the same information as another.

When filter by action type on agenda, the field used to filter is 'fk_action'. Thus, we can take advantage and use the 'code' to store other information. With the field 'fk_action' we know that the event has been automatically created and you can filter on the agenda, being the 'code' field to store extra information.

I don't think that is functional to create an event type for each possible trigger.

I think that although manual and automatic actions are not exactly the same, can coexist in the same agenda as before.

@eldy
Copy link
Member

@eldy eldy commented on 832d1b3 Oct 15, 2014 via email

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@FHenry
Copy link
Member Author

@FHenry FHenry commented on 832d1b3 Oct 24, 2014

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So in this case why use code as option name to select type event into agenda (select_type_actions into fromaction). If it is fk_action relevant in the case of use event type, we should change all select event type to only manage id and not code.

@eldy
Copy link
Member

@eldy eldy commented on 832d1b3 Oct 25, 2014 via email

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please sign in to comment.