Roland Häder [Fri, 23 Sep 2022 16:47:32 +0000 (18:47 +0200)]
Please cherry-pick:
- e.g. lockUserAccount() changes userAccountStatus to LOCKED which results in
Objects.equals() to return false even when it is the same user which causes
an exception being thrown.
- checking the userId only won't be enough for an other use-case where a new
user with same data is being created
Roland Häder [Sat, 25 Jun 2022 13:08:07 +0000 (15:08 +0200)]
Please cherry-pick:
- private methods should not have exceptions thrown because these cases cannot
be unit-tested (or very hard)
- normally only public, package-level or protected methods throw exceptions
and have made sure that e.g. null-references won't get through to private
methods
Roland Häder [Sat, 25 Jun 2022 12:57:38 +0000 (14:57 +0200)]
Please cherry-pick:
- country.countryCode and countryI18nKey could be NULL here (independently from
each other) and needs checking BEFORE any method on them is being executed
Roland Häder [Tue, 19 May 2020 23:31:42 +0000 (01:31 +0200)]
Product-only:
- let's use createManaged() where possible to avoid some duplicate code. It may
look a bit to much encapsulation or to fine-granulated, the createManaged()
method contains some validation on the entity instance and that is a good
reason to have it encapsulated away.
Roland Häder [Tue, 19 May 2020 23:28:45 +0000 (01:28 +0200)]
Please cherry-pick:
- let's use createManaged() where possible to avoid some duplicate code. It may
look a bit to much encapsulation or to fine-granulated, the createManaged()
method contains some validation on the entity instance and that is a good
reason to have it encapsulated away.
Roland Häder [Mon, 11 May 2020 00:48:27 +0000 (02:48 +0200)]
Please cherry-pick:
- departments, headquarters and branch offices cannot have a relation to
employees as employess have a relation already to them. So if comparison of
those entities come, this ends up in an endless loop with a stack overflow.
- the fix here is a bit simple and also a bit complex: relate those 3 entities
to contacts (jcontacts-core.jar) and look in all employees related to the
department, headquarter or branch office who have an equal contact record
Roland Häder [Sun, 10 May 2020 04:05:43 +0000 (06:05 +0200)]
Please cherry-pick:
- implemented business method updateDepartment() including mergeDepartmentData()
which does the actual merger and sets entry-updated timestamp
- renamed getDetached() to mergeFooData() as "get" is strictly for getters
- TODO: Rename setFoo() to something else!
- sorted members (automatically by NetBeans IDE)
Roland Häder [Sun, 26 Apr 2020 19:33:56 +0000 (21:33 +0200)]
Don't cherry-pick:
- updated method names
- fetching user's or receipt's receipt items can now be done without any extra
JPQL, simply by invoking fetchAllReceiptItems() and iterating over all and
taking matching elements into list
Roland Häder [Sat, 25 Apr 2020 18:37:02 +0000 (20:37 +0200)]
Product-only:
- removed no longer used business method, should be done in backing bean (web
container)
- renamed method fetchAllProducts() to fetchAllGenericProducts()
- renamed method fetchAllCategories() to fetchAllProductCategories()
Roland Häder [Sat, 25 Apr 2020 16:25:40 +0000 (18:25 +0200)]
Product-only:
- updating an entity doesn't work with a persist() invocation, not at least
what JPA 2.1 says. As here JPA 2.1 is honored and not a specific
implementation like Hibernate is, persist() will lead to a double entry.
You need to use find() + copy all fields + merge() to archive this the proper
way under JPA 2.1
- updated method invocations due to updated jproduct-core.jar
Roland Häder [Fri, 24 Apr 2020 19:49:31 +0000 (21:49 +0200)]
Don't cherry-pick:
- avoided local copy of List instance
- if a receiptItem is updated, no matter if discount or refund, check it. Also
then only rely on the primary key
Roland Häder [Fri, 24 Apr 2020 16:09:40 +0000 (18:09 +0200)]
Don't cherry-pick:
- renamed BaseFinancialsProjectEnterpriseBean to
BaseFinancialsReceiptEnterpriseBean (project-specific)
- introduced BaseFinancialsReceiptItemEnterpriseBean for generalizing some
receipt-item related methods
- implemented business method updateReceiptItem()
Roland Häder [Fri, 24 Apr 2020 15:03:39 +0000 (17:03 +0200)]
Don't cherry-pick:
- ops, don't update itemEntryCreated in update phase, why is that still possible?!
- set itemEntryUpdated when update business method is invoked
Roland Häder [Thu, 16 Apr 2020 20:04:23 +0000 (22:04 +0200)]
Please cherry-pick:
- renamed allFoos() to fetchAllFoos()
- cleanup of deprecated/no longer needed business methods as fetchAllFoos() can
be used instead
- splitted mobile number relevant business methods into separate EJB, this
allows better load-balancing on servers with many CPU cores
- UserLoginSessionBean is now superflous and can be removed
Roland Häder [Tue, 14 Apr 2020 08:03:54 +0000 (10:03 +0200)]
Please cherry-pick:
- updated jphone-core.jar requires now some new getter/setter names like
getMobileEntryUpdated(), setContactEntry<Created|Updated>() and many more
Roland Häder [Tue, 4 Feb 2020 21:51:43 +0000 (22:51 +0100)]
Please cherry-pick:
- having nothing created is best and most secure choice, then accidentally no
data is lost and you have to re-enable this when you want to (re-)create your
database layout.
projects / jfinancials-ejb.git / log