omar_compucorp (c376eee8) at 23 Feb 09:05
omar_compucorp (aa137e75) at 22 Feb 16:39
Fix editing custom fields on certain CiviCRM versions
omar_compucorp (aa137e75) at 22 Feb 16:37
Fix editing custom fields on certain CiviCRM versions
omar_compucorp (f590db94) at 22 Feb 16:35
On CiviCRM 5.51.3 (haven't tested it on other CiviCRM versions, but it does not seem to affect 5.72.alpha1 version), If you add a custom group and fields set without clearing the site cache, and then you tried to edit any of the cuustom fields, the following error is thrown:
|php|http://localhost/civicrm/contact/view?reset=1&cid=248|1||TypeError: civicrm_api3(): Argument #1 (closed) ($entity) must be of type string, null given, called in /var/www/default/htdocs/httpdocs/sites/all/modules/contrib/civicrm/ext/civirules/CRM/Civirules/Utils/PreData.php on line 115 in civicrm_api3()).
This error goes away if you clear CiviCRM cache, and it seems to happen because Civirules caches the list of custom group, which is later used in getCustomGroupById() method to retrieve any custom group, but any newly added custom field will not be added to the cache yet unless you clear the cache, which results in the above error.
What I did here is just adding a safeguard that tries to retrieve the custom group using API if it is not already available in the cache, thus users can still edit custom fields even if they forgot to clear the cache.
omar_compucorp (c376eee8) at 22 Feb 16:19
Fix editing custom fields on certain CiviCRM versions
omar_compucorp (f78870af) at 22 Feb 16:18
omar_compucorp (9305563f) at 19 Nov 11:42
Add setting to allow tutorials to run on every unique login
If you have a public demo site with a single shared demo account (Say similar to https://dmaster.demo.civicrm.org/), you may want to set tutorials so they run once every time a different person login using the same account. At the moment there is a checkbox called "Auto-Run" which allow running the tutorial once per user account but not per unique login:
With the work done here, site admins can now create a CiviCRM setting with the key tutorial_runOnEveryUniqueLogin
and set its value to 1, which can be done using several ways such as using API v3 or by executing something like this using cv
tool:
Civi::settings()->set('tutorial_runOnEveryUniqueLogin', 1);
this setting combined with the "Auto-Run" flag, will ensure that each tutorial will run per unique login, where if this setting is not set then things will just work same as they usually do at the moment.
If tutorial_runOnEveryUniqueLogin
setting is set to 1, then I check if the tutorial id is stored in the browser cookies, if not then I mark the tutorial as not viewed, and then store the tutorial id with value = "viewed" in cookies to prevent it from running again.
Also given that I don't check the session id (which I don't think is necessary), this means that if the same person logs in then logs out using the same device and browser, then the tutorial won't show up again for that person, but if they use separate browser or incognito mode then the tutorial will show up again.
omar_compucorp (07c7089b) at 19 Nov 11:08
Add setting to allow tutorials to run on every unique login
I see. and fair enough! thanks @jaapjansma for responding and for the work you did so far.
hey guys, so I came across this (so sorry if I am missing some stuff) and I feel like I agree with @cividesk argument which is:
As specified this change carries a lot of risk as many custom code is build to report, import/export, synchronize, compute stats or other operations on the contribution table.
I can also imagine how much destruction adding another Boolean flag like this could be to both core and 3rd party extensions, combined with another flag such as is_test (that is already on the contribution entity), this seems like a recipe for a disaster (also I don't see anyone mentioning updating financial batches which probably will get affected by this, think of how many other stuff will be missed).
Though on the other hand I don't think that I like the other suggested approach which is about adding a serialized field to the recur contribution, serialized fields/data is a room for plenty of issues and they are hard to maintain and to operate and it seems to me more like a hack than an actual solution to the issue.
I wonder, what would be the issue with creating new entity/entities to store the template data? Was a similar solution discussed already?