Can we change the return screen after creating an entity?

[Guido1982]

In the system I manage the users would like to be able to return to the newly created entity after creation, in stead of returning to the previous one. For instance, when an invoice is created from an account, they would like to return to the newly created invoice in stead of the account. Do we have something in place for this?

[joebordes]

http://corebos.org/documentation/doku.php?id=en:devel:develtips#i_would_like_to_be_able_to_ret

[Guido1982]

Cool, thanks! Any chance we could convert this to a GV? I'd be happy to donate some time to that. Gives me a chance to work on them.

[joebordes]

Of course! That would be wonderful.

The thing is that this is more complex than it seems, which is why it isn't already there. The limitation we have with GVs is that they only consider one module, but this functionality needs to consider two. For example, we could want to return to the Account when creating an Invoice, but not when creating a Quote, or not return to the account when creating an invoice but return to the contact when creating an invoice. In short, we need to be able to decide where to go depending on what we are creating and where we came from. This cannot be done with a GV.

We could create a GV for an all or nothing setting. We activate the GV so that we always stay on the Invoice, no matter where we are creating from. That would be better than having to code it as we do now, but, with coding, it is very easy to add an "if" condition to apply the logic only on certain "from" modules.

I think I would do something like this:

- create a global variable called: Application_Return_toCreatedFrom_Module: boolean 0 | 1 default 1, which is what the application does now
- that has to be done in DefineGlobalVariables changeset and in the language files en_us.gvdefs.php at least
- change module/Vtiger/Save.php by adding the call to the globalvariable and modifying the input $_REQUEST accordingly

start asking...

[Guido1982]

I understand. Didn't know GV was limited in this way.

Q1: How do we 'create' new GV's? Do you have an example?

Getting the GV and using that in the Save.php file seems pretty straightforward, I've seen them used elsewhere so I can borrow from that. The only thing I noticed is that not all modules use the stock Save.php file, so it wouldn't work there. Nonetheless I think it would be a nice addition.

[joebordes]

GVs are very easy to add. You add the new variable in the continuous changeset, add it to the documentation language file and then use it wherever you need it to do its work.

Here you can see the last one I added:

https://github.com/tsolucio/corebos/commit/541f6ff55924996e160b1cb00806e0b788378f21

Here I add it to the changeset: https://github.com/tsolucio/corebos/commit/541f6ff55924996e160b1cb00806e0b788378f21#diff-812c6f28f745ea333df89c5f0194287bR131

Here to the language file: https://github.com/tsolucio/corebos/commit/541f6ff55924996e160b1cb00806e0b788378f21#diff-48590fdb96f215e9c38678a0b6c946e0R787

The other two files I change is where I use the new variable to substitute a hard coded "6" limit that was there

There are only two Save.php files you have to check:

modules/Contacts/Save.php
modules/cbCalendar/Save.php

cbCalendar has some specific closing action because it can be created in a popup window from the visual calendar. I wouldn't even look at Contacts because that one will change shortly. It is on my list to cleanup and standardize, I just haven't been able to get to it yet, so ignore that one, it will get the functionality when I fix it.



HTH