Maxim,
OK, let's not change the import/export process.
Please note that exported/imported fields of the type string have NULL
values, not "null" string.
So, possible decision could be:
- Do not show "null" string in the text fields in the User details screen
if these fields are actially contain
And how this will affect old backups? (already contain "null" strings in
xml files)?
Also I'm afraid
"Export both empty and null strings in the text fields as empty strings" is
not a good idea since it will affect all code and will have unpredictable
side effects.
The only thing can be fixed is i
Maxim,
I don't know the history of the changes for import/export in all the
details.
For now I've investigated the database on demo.dataved.ru and it seems that:
- There are several records in the address table where email field is a
null string. Saving any update for such records causes "Duplic
Hello Irina,
What do you think is the best way to handle it:
1) replace all String fields which value is "null" with null object
2) process only user emails so "null" email will be null object?
On Mon, Mar 18, 2013 at 5:59 PM, Irina Arkhipets
wrote:
> Hi All,
>
> I believe that https://issues.
Hi All,
I believe that https://issues.apache.org/jira/browse/OPENMEETINGS-572 is a
blocker for the release.
The following problem appears here as a side effect of this issue:
If user had an empty e-mail, after the import-export his e-mail is shown as
'null'.
Now if some user data has been change
done
http://svn.apache.org/repos/asf/openmeetings/branches/2.1/
https://builds.apache.org/view/M-R/view/OpenMeetings/job/Openmeetings%202.1/
On Mon, Mar 18, 2013 at 1:10 PM, seba.wag...@gmail.com <
seba.wag...@gmail.com> wrote:
> That would be great!
> And if you need to branch, just do it.
>
>
That would be great!
And if you need to branch, just do it.
Thanks,
Sebastian
Am 18.03.2013 19:03 schrieb "Maxim Solodovnik" :
> You are right :(
> I'll create the branch and set up the build.
>
> according to the logs demo is up for 10 hours so far (it is being used in
> testing SIP so it is rel
You are right :(
I'll create the branch and set up the build.
according to the logs demo is up for 10 hours so far (it is being used in
testing SIP so it is reloaded from time to time)
I'll ask others if we can deploy the next RC to it for the tests.
On Mon, Mar 18, 2013 at 12:47 PM, seba.wag...
Even if you start the vote by today it takes 72 hours to vote.
And even if that vote passes it will take another day to release.
So the earliest day when its safe to commit new things to trunk will be
Friday or Saturday.
And I still think it would be worth doing some more tests.
I have not been ab
Hello Sebastian,
I was hoping we can release today/tomorrow?
Maybe we can name our current blockers? (currently there is no unresolved
issues for 2.1)
Separate branch means additional build target, double commits, etc.
I would release in nearest couple of days with no additional branch
what do yo
Hi Maxim,
I wonder if the release does lock you from committing improvements to
trunk. For example the red5 update that you mentioned to be already
somewhere in your pipe.
Do you think it makes sense to create a branch for the 2.1 release?
So that you can commit changes to trunk (that would not g
11 matches
Mail list logo
